Authorization Code with PKCE

Authorization Code with Proof Key for Code Exchange (PKCE) flow is an extension of the Authorization Code grant flow. However, with PKCE, requests do not need to include the client_secret in the /token request. The PKCE flow reduces security risks for desktop and mobile applications because the client_secret does not need to be embedded in source code.

Authorization Code with PKCE was designed for desktop and mobile apps, but it can be also used in web apps.

How It Works

code_verifier and code_challenge are generated.
code_challenge is submitted to /authorize endpoint.
The authorization server returns an authorization code.
code_verifier and authorization code are submitted to /token endpoint.
The server responds with an oauth_code, an id_token, an access_token, and a refresh_token.
The access_token is used to authorize the application.

The following is a diagram that shows the Authorization Code with PKCE flow:

Applications using Authorization Code with PKCE must use Serial PKCE to refresh the access token with Trimble ID. This means that a new (code_verifier, code_challenge) pair must be provided on each token or token refresh request. This creates a request sequence:

Authorization Request (code_challenge1) => Token Request (code_verifier1, code_challenge2) => Token Refresh(code_verifier2, code_challenge3) => …

For more details, check out this OAuth.net resource.

What You Need

You will need the following information from Trimble:

Client ID
Client secret
Callback url

The first step is the generation of a new code verifier and code challenge. This step is repeated for every authorization request.

Code

Verifier

The code verifier string must meet the following requirements:

Include only the following characters: A-Z, a-z, 0-9, punctuation characters ._- or ~ (hyphen, period, underscore, and tilde.)
The verifier string must be between 43 and 128 characters long.

Challenge

The challenge code is a BASE64-URL-encoded string of the SHA256 hash of the code verifier.

Authorization

Request

After generating the challenge code, it must be submitted to the authorization server in a GET request. The code generated is valid for 10 minutes.

GET /oauth/authorize

Parameters

Parameter	Description
State	This field is used to return data (like a return URL) after sign-in with an access code.
client_id	Application ID registered for the application (UUID)
response_type	`code`
scope	`openid` and scope(s) needed to enable intended functionality as documented for each API product to which access is being granted.
redirect_uri	Redirect URL registered with Identity
code_challenge	Code challenge
code_challenge_method	`S256`
ui_locales	String Locale value. This specifies locale language Identity v4 UI will display. This value is optional.
prompt (optional)	How Trimble ID displays the login UI.
login_hint (optional)	Allows an application to specify the email address for use in the sign in or sign up page if you are using prompt=create
account_id (optional)	IAM account ID for this sign-in. Pass it to select that account for the tokens issued by `/token`. Omit it to use the user’s default account.

Prompt Options

Possible values for the optional prompt parameter

Prompt value	Description
none	Trimble ID will not display any UI, if there is no SSO session the /authorize call will redirect to the caller with a error
login	Trimble ID will always display the sign in UI, regardless of whether an SSO session exists
create	Trimble ID will display the sign up page rather than the sign in page

Account context

account_id is optional on GET /oauth/authorize. Pass it when the application must sign the user in under a specific IAM account. This is how an application switches account context programmatically. The access_token and id_token from the following /token call include that value as the account_id claim.

A valid account_id that is associated with the user is returned as the account_id claim in the access_token and id_token.
When account_id is omitted, Trimble ID uses the user’s default account when it mints those tokens.
An invalid account_id, or one that is not associated with the user, redirects to the callback URL with an error.

To switch to a different account, start a new /authorize request with the new account_id, then exchange the new authorization code at /token.

Response

The following is an example of the callback made to your callback endpoint. You will need to parse the code parameter from the callback to use in your token call.

http://localhost:5173/auth/callback?
code=us_9fd5fee3f3c74267910f8ed7c71c85a8&
state=Hn4K-n1m00000CiUUV-vOUNcOJZ8Jh_4shoo

Token

Request

Authorization Server responds with an ID Token and Access Token (and optionally, a Refresh Token).

To later refresh the access token, another (code_verifier, code_challenge) pair needs to be created.

POST /oauth/token

Headers

Header	Description
Accept	application/json
Content-Type	application/x-www-form-urlencoded

Body

Body	Description
grant_type	authorization_code
code	The authorization code returned from the above call
client_id	Application ID registered for the application
redirect_uri	Callback URL registered with Identity
code_verifier	Code verifier generated earlier for the Authorization request
code_challenge (optional)	A new Code challenge (if token refresh is going to be used)
code_challenge_method (optional)	`S256` (if token refresh is going to be used)

Response

If the token request succeeds, the server responds with a 200 response code.

Fields

Field	Description
access_token	The access token’s primary function is to authorize a user.
refresh_token	A refresh token is used to obtain access tokens after an initial authorization grant without interaction with the end-user.
expires_in	The duration of time the access token is granted for in seconds
id_token	An ID token is an artifact that proves the user has been authenticated. The ID token contains information about the user, such as user name and email, and is used to authenticate a user.

The access_token and id_token are JWTs. Each includes an account_id claim for the account selected on /authorize. When that request included account_id, the claim is that account. When it did not, the claim is the user’s default account.

Example

{
  "access_token": "8aca1...",
  "refresh_token": "861e9...",
  "expires_in": 3600,
  "id_token": "eyJhbG..."
}

Refresh

If the access token expires, it can be refreshed using the one-time refresh token.

Another (code_verifier, code_challenge) pair must be created.

The server will respond with a Token Response.

POST /oauth/token

Headers

Header	Description
Accept	application/json
Content-Type	application/x-www-form-urlencoded

Body

Body	Description
grant_type	refresh_token
refresh_token	The refresh token from the previous token response
client_id	Application ID registered for the application
code_verifier	Code verifier generated for the previous token request
code_challenge	A new Code challenge
code_challenge_method	`S256`