- Tokens
- Access Tokens
- Refresh Tokens
- ID Tokens
- Proof-of-Possession (PoP) Tokens
-
Grant Type
- Scopes
- PKCE (RFC 7636)
- Client Management
- Authorization Requests
- User Authentication
- Error Handling
-
Client Authentication
- Configuring client authentication
- Client authentication using client_secret_jwt method
- Client authentication using private_key_jwt method
- Client authentication using tls_client_auth method
- Strict checking on client authentication parameters
- Introspection
- Userinfo Endpoint
- JARM
- Device Flow (RFC 8628)
Strict checking on client authentication parameters
Overview
Authlete version 2.0 and later strictly check client type and client authentication method settings, and values specified in token requests. Some requests which are valid for Authlete 1.1 may be refused.
Difference between 1.1 and 2.0 (and later)
Authlete 1.1 |
Authlete 2.0 and later |
|
Verification policy |
When client secret is included in a token request, Authlete always verifies its value regardless of configuration i.e. it ignores settings for client type and client authentication method. Authlete accepts a token request with no client_id as it can derive the client identifier from other parameters such as authorization code, refresh token. |
Authlete’s verification behavior varies with configured values of client type and client authentication method.
|
Default settings |
|
|
Notes on migrating from Authlete 1.1 to 2.0 and later
In version 1.1, if you have specified client_secret_basic as client authentication method and some client sends a request with client secret in request body, Authlete verifies the value.
In version 2.0 and later, clients must include client secret in Authorization header if you have specified client_secret_basic as client authentication method. Thus Authlete 2.0 responds error against such request that is valid for Authlete 1.1.
How did we do with this article?