Client authentication set to none and with the use of PKCE

Descriptions of ACP client authentication set to **none** and with the use of PKCE

Overview

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 grant 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.

Read more

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

PKCE in a nutshell

PKCE is an OAuth security extension that prevents malicious applications or codes that intercepted authorization code from exchanging it for an access token.

For those reasons, ACP supports using the token endpoint authentication method set to none and enables the use of proof key for code exchange (PKCE).

Prerequisites

  • In ACP the token endpoint client authentication method is set to none.

Process

  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 ACP using the authorize endpoint and provides both t(code_verifier) and the t_m from the previous steps in the request.

  4. ACP 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 ‘token’ endpoint and includes the code_challange and code_challenge_method form parameters.

    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. ACP 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.