Skip to main content

Client Authentication Set to None and With Use of PKCE

Description of client authentication set to none and with the use of PKCE.

None Client Authentication with PKCE

Client authentication set to none and with the use of Proof Key of Code Exchange (PKCE) was created as a secure substitute for the OAuth implicit flow, where the client receives access tokens as the result of authorization.

Security Recommendation

Any public client should use the client authentication method set to none and utilize the proof key of code exchange (PKCE).

Public clients, like mobile applications or JavaScript-based applications, by their design, cannot store client secrets securely. For such clients, even encrypting the client secret inside the application's code is not a reliable way of protecting secrets as the application can be decompiled and the client secret can be extracted while it is decrypted in the memory of the application.

To know more about the implicit grant flow and the threats that come with it, read the following documents:

Prerequisites to Using None Client Authentication and PKCE

The client is configured to use none method as the token authentication method

How None and PKCE Works

  1. The client creates a secret named code_verifier.

    A code_verifier secret is a high-entropy cryptographic random string with a minimum length of 43 characters and a maximum length of 128 characters.

  2. The client transforms code_verifier using its t_m transform method. The t_m method is a method used for transforming code_verifier. It can be S256 or plain according to the PKCE RFC 7636, section 4.2.

    In plain the transformation looks as follows:

    code_challenge = code_verifier

    In S256 the transformation looks as follows:

    code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

    The plain transform method is not recommended and should only be used by clients that are unable to support the S256 method. It is available only for compatibility with existing deployments and for constrained environments.

    The S256 method is Mandatory To Implement (MTI) for clients that are capable of using it.

    Result: t(code_verifier) (also called code_challange) version of code_verifier is created.

    Note

    t(code_verifier) is a transformed version of the code_verifier from the first step of the process. It is sent as a part of the authorization request along with the transformation method.

  3. The client requests authorization from the authorization server using the authorize endpoint and provides both t(code_verifier) and the t_m from the previous steps in the request.

  4. The authorization server responds with requested authorization and records both t(code_verifier) and t_m parameters.

  5. The client makes a request for an access token to the authorization server's token endpoint and includes the code_challange and code_challenge_method form parameters.

    See the following request example (extra line breaks are added for display purposes):

    curl --request
-F "grant_type=client_credentials"
-F "code_challenge=yRm6bQ0TxlBdZXwHzxg.eCT.ik6OL3Ggbf0gIybj6Txz03A4gQtowMrVJ_
oqq62falqYZs6Wqdchl1y5wtUmWwANUqRjtt4qaVrNZe5.~oig2HW0K5FF8KaPdzwk7Xz-"
-F "code_challenge_method=xSc4hLkNSQE053N7KaZUBc6g97t4bKgsYzfOsk3m9e0" POST \
--url <https://localhost:8443/{tid}/{aid}/oauth2/token> \
--header 'accept: application/x-www-form-urlencoded'

  6. The authorization server transforms the provided code_verifier secret using the t_m method provided earlier and checks if the resulting code_challenge is the same as the t(code_verifier) transformed secret from the request to the authorize endpoint.

    Result: The client is authenticated using the client authentication method set to none and with the use of PKCE.

In this section: