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
Section titled “How It Works”code_verifierand code_challenge are generated.code_challengeis submitted to/authorizeendpoint.- The authorization server returns an authorization code.
code_verifierand authorization code are submitted to/tokenendpoint.- The server responds with an
oauth_code, anid_token, anaccess_token, and arefresh_token. - The
access_tokenis 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 Identity.
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
Section titled “What You Need”You will need the following information from Trimble:
- Client name
- 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.
Verifier
Section titled “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
Section titled “Challenge”The challenge code is a BASE64-URL-encoded string of the SHA256 hash of the code verifier.
Authorization
Section titled “Authorization”Request
Section titled “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/authorizeParameters
Section titled “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 Client name (Scope is space delimited) |
| 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 Identity 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 |
Prompt Options
Section titled “Prompt Options”Possible values for the optional prompt parameter
| Prompt value | Description |
|---|---|
| none | Trimble Identity will not display any UI, if there is no SSO session the /authorize call will redirect to the caller with a error |
| login | Trimble Identity will always display the sign in UI, regardless of whether an SSO session exists |
| create | Trimble Identity will display the sign up page rather than the sign in page |
Response
Section titled “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_4shooRequest
Section titled “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/tokenHeaders
Section titled “Headers”| Header | Description |
|---|---|
| Accept | application/json |
| Content-Type | application/x-www-form-urlencoded |
| 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
Section titled “Response”If the token request succeeds, the server responds with a 200 response code.
Fields
Section titled “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. |
Example
Section titled “Example”{ "access_token": "8aca1...", "refresh_token": "861e9...", "expires_in": 3600, "id_token": "eyJhbG...",}Refresh
Section titled “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/tokenHeaders
Section titled “Headers”| Header | Description |
|---|---|
| Accept | application/json |
| Content-Type | application/x-www-form-urlencoded |
| 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 |
Examples
Section titled “Examples”Postman
Section titled “Postman”Fork this Postman collection into your own workspace to quickly get started using Authorization Code with PKCE.
You need the following from your Developer Console application:
- Client name
- Client id
- Client secret
- Callback url
To use with Postman, the Postman callback url (https://oauth.pstmn.io/v1/browser-callback) must be configured for your application.