Security schemes define how agents authenticate requests and establish trust. Bindu supports multiple authentication methods following the A2A Protocol specification.
HTTPAuthSecurityScheme
Schema:
Use Case 1: Bearer Token with JWT
Use Case 2: Basic Authentication
What it’s for: Token-based authentication using standard HTTP authentication schemes. Most commonly used with Bearer tokens (JWT) for stateless API authentication, but also supports Basic auth for simple username/password scenarios.
APIKeySecurityScheme
Schema:
Use Case 1: Header-based API Key
What it’s for: Simple key-based authentication where a static or rotating API key is passed in requests. Ideal for service-to-service communication, webhook authentication, or public API rate limiting and access control.
OAuth2SecurityScheme
Schema:
Use Case 1: Authorization Code Flow (User Authorization)
What it’s for: Delegated authorization where agents need to access resources on behalf of users or other services. Authorization code flow is used when users need to grant permission, while client credentials flow is used for direct service-to-service authentication without user involvement.
OpenIdConnectSecurityScheme
Schema:
Use Case: Enterprise SSO with OpenID Connect
What it’s for: Identity authentication using OpenID Connect, typically for enterprise single sign-on (SSO) scenarios. The discovery URL automatically configures authentication endpoints, supported scopes, and token formats, making it easier to integrate with identity providers like Keycloak, Azure AD, or Okta.
MutualTLSSecurityScheme
Implementation status (2026-05): schema only, transport not yet deployed.The MutualTLSSecurityScheme TypedDict ships and can be advertised in an agent card, but Bindu does not yet terminate mTLS at the transport layer in production. The supporting code (bindu/extensions/mtls/ — step_ca_client.py, cert_store.py, mtls_agent_extension.py) targets a Smallstep step-ca certificate authority and is gated behind Hydra audience-whitelisting work that hasn’t shipped. See docs/MTLS_DEPLOYMENT_GUIDE.md for the design. Until that lands, treat this scheme as forward-looking — safe to declare, not yet enforced.
Schema:
Use Case: High-Security Service Communication
What it’s for: High-security authentication using client certificates where both parties verify each other’s identity through TLS. Commonly used in zero-trust architectures, financial services, healthcare systems, or any scenario requiring strong cryptographic authentication without relying on passwords or tokens.
SecurityScheme: Union Type
The SecurityScheme type is a discriminated union of all security scheme types:
The type field acts as a discriminator to determine which security scheme is being used. All security schemes use camelCase for field names (e.g., bearerFormat, openIdConnectUrl) following the A2A Protocol specification.
Choosing the Right Security Scheme
Quick Reference:
Decision Guide:
- Need simple token authentication? → Use HTTP Auth with Bearer tokens (JWT)
- Building a public API? → Use API Key for rate limiting and access control
- Users need to authorize agents? → Use OAuth2 Authorization Code flow
- Service-to-service without users? → Use OAuth2 Client Credentials or API Key
- Enterprise SSO integration? → Use OpenID Connect
- Maximum security required? → Mutual TLS is the planned answer (see warning above); until it ships, layer OAuth2 client-credentials over TLS at the network edge
- Legacy system with Basic auth? → Use HTTP Auth with Basic scheme
Security Best Practices:
- Always use HTTPS/TLS for all authentication schemes except Mutual TLS (which provides its own transport security)
- Rotate API keys regularly and never commit them to version control
- Use short-lived tokens (15-60 minutes) with refresh token rotation for OAuth2
- Implement rate limiting regardless of authentication method
- Log authentication attempts and monitor for suspicious patterns
- Use the principle of least privilege - grant only necessary scopes/permissions