Table of Contents

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. A. Client type is public Client authentication method must be set to NONE . Other values cause an error at runtime. B. Client type is confidential Client authentication method must not be set to NONE . This value causes an error at runtime. If client authentication method is set to client_secret_basic , the client must specify its client secret in Authorization header on sending a token request. If client authentication method is set to client_secret_post , the client must specify its client secret in request body on sending a token request.
Default settings	Client type: public Client authentication method: client_secret_basic	Client type: public Client authentication method: none

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.