Client Authentication

The client secret is a shared symmetric key known only to the client and the authorization server. It is the most common method for confidential clients (e.g., traditional web applications with a secure backend server).

• The client sends its client_id and client_secret in the token request's request body or via HTTP Basic Authentication.
• Security Consideration: The secret must be stored securely on the client side. Exposure leads to full client impersonation. It is unsuitable for public clients (e.g., mobile apps, SPAs) where the secret cannot be protected.

Private Key JWT authentication uses asymmetric cryptography. The client possesses a private key and registers the corresponding public key with the authorization server.

• The client creates a signed JSON Web Token (JWT) using its private key. This JWT includes claims like iss (client ID), sub, aud (authorization server), and jti.
• The client sends this JWT in the client_assertion parameter of the token request.
• The authorization server validates the JWT's signature using the pre-registered public key.
• This method is highly secure for machine-to-machine (M2M) communication and is recommended over client secrets where possible, as it eliminates a shared secret.

Mutual TLS authenticates the client at the transport layer during the TLS handshake, using X.509 certificates.

• Both the client and the authorization server present and validate each other's certificates.
• The client's certificate is bound to its client_id, often via the x5t#S256 thumbprint.
• The client sends its client_id in the request, and the server verifies the presenting certificate matches the bound certificate for that ID.
• This method provides strong authentication and is a core component of high-assurance standards like FAPI 2.0 Security Profile. It is ideal for service-to-service communication in zero-trust architectures.

For public clients that cannot securely store a secret (e.g., single-page applications, mobile apps), the none authentication method is used.

• The client only presents its client_id.
• Security relies entirely on other protocol safeguards:
  • Use of the Authorization Code Flow with PKCE to prevent code interception attacks.
  • Strict redirect URI validation.
  • Short-lived access tokens.
• This method does not authenticate the client itself with high assurance but authenticates the authorization request. The authorization server must implement additional protections for public clients.

Client Secret JWT is a hybrid method where a symmetric client secret is used to sign a JWT, rather than sending the secret directly.

• The client creates a JWT and signs it with the client_secret using the HMAC SHA-256 algorithm.
• This signed JWT is sent as a client_assertion.
• While it still uses a shared secret, it offers advantages over sending the secret in a parameter:
  • The secret itself is never transmitted in the request.
  • The JWT can carry additional metadata and has a natural expiration.
• It is more secure than basic client secret posting but less secure than Private Key JWT, as compromise of the secret still allows forgery.

Choosing the correct client authentication method is a critical security decision.

• Confidential Clients (with a backend): Prefer Private Key JWT or Mutual TLS. Use Client Secret only if necessary, and ensure robust secret management (HSMs, vaults).
• Public Clients (browser/mobile): Use none with PKCE. Never embed static secrets.
• High-Security/Financial (FAPI): Mutual TLS is often mandated.
• General Best Practices:
  • Always use HTTPS.
  • Validate redirect URIs exactly.
  • Implement token revocation.
  • Monitor for anomalous token requests.
• The method is defined during client registration with the authorization server.

A permission mechanism in OAuth 2.0 that limits an application's access to a user's or client's resources. Scopes are requested during client authentication and granted by the authorization server.

• Function: Defines the breadth of access an access token will confer (e.g., read:data, write:files, admin).
• Security Principle: Follows the principle of least privilege. An AI agent should only request and receive scopes necessary for its specific function.
• Example: A document-analysis AI agent might authenticate with scopes files.read and files.metadata but not files.delete, limiting its potential impact if compromised.