This article describes the process for obtaining user-scoped OpenID Connect (OIDC) or OAuth 2.0 tokens for Single-Page Applications (SPA), Web, or Native applications without using a browser. This technique is useful for unit, integration, or end-to-end testing.

• OpenID Connect (OIDC) and OAuth 2.0
• Single-Page Applications (SPA), Web, or Native apps using Implicit or Authorization Code Flow
• Implicit Flow or Authorization Code Flow
• Users with passwords in Okta and no Multi-Factor Authentication (MFA) requirements
• Okta Identity Engine (OIE)
• Okta Classic Engine

This method involves two or three API calls to Okta. The process starts by obtaining a sessionToken via primary authentication, which is then exchanged for tokens or an authorization code.

Prerequisites

• Use Postman Collections for formatting requests. Both the Authentication and OpenID Connect collections are required.
• Ensure the user is not prompted for MFA at the organization level.
• Note that external, federated, or social users cannot use this technique.

1. Complete Primary Authentication

Perform a POST request to the /authn endpoint to obtain a sessionToken.

1. Submit a request to POST https://<oktaDomain>/api/v1/authn.
2. Include the username and password in the JSON body.
3. Verify the response status is SUCCESS.
4. Copy the sessionToken value from the response.

NOTE: If the status is not SUCCESS, refer to the Primary Authentication API documentation to complete the transaction.

2. Make an Authorize Request

Exchange the sessionToken for tokens or an authorization code. Use the built-in Org Authorization Server or a Custom Authorization Server.

1. Submit a request to GET https://<oktaDomain>/oauth2/v1/authorize or GET https://<oktaDomain>/oauth2/<authorizationServerId>/authorize.
2. Provide the following query parameters:
   • client_id: The ID of the application.
   • response_type: Set to id_token, token, or code.
   • response_mode: Set to form_post.
   • sessionToken: The value obtained in Step 1.
   • scope: Space-separated scopes (for example, openid profile).
   • redirect_uri: A registered Sign-in redirect URI.
   • nonce and state: Arbitrary strings.

For Proof Key for Code Exchange (PKCE), include code_challenge and code_challenge_method.

Outcome

• Implicit Flow: If response_type is id_token or token, the tokens appear in the HTML body of the response. Implicit Flow does not support Proof Key for Code Exchange (PKCE).
• Authorization Code Flow: If response_type is code, the response contains a code value. Proceed to Step 3.

3. Make a Token Request (Authorization Code Flow Only)

Exchange the authorization code for tokens.

1. Submit a request to POST https://<oktaDomain>/oauth2/v1/token or POST https://<oktaDomain>/oauth2/<authorizationServerId>/token.
2. Set the Content-Type to application/x-www-form-urlencoded.
3. Provide the grant_type, code, redirect_uri, client_id, and code_verifier (if using PKCE).

The tokens created can now be used to test the resource server or other integrations.

NOTE: This technique is intended for testing and debugging. Production requests to the /authorize endpoint should redirect the browser. Asynchronous JavaScript and XML (AJAX) cannot be used with the /authorize endpoint.

Related References

• Postman Collections
• Primary Authentication Documentation
• Retrieve a Session Cookie Through the OIDC Authorization Endpoint