Get Access Token

Exchange credentials for an access token for the given Connected Apps client.

This endpoint supports multiple grant types:

The authorization_code grant type is used to complete an OAuth or OIDC login flow with user interaction. When using the authorization_code grant type, a code and redirect_uri must be provided.
Additionally, a code_verifier must be provided if PKCE was used at the start of the login flow.

The response from the Authorization Code flow differs depending on the scopes granted to the client.

• If the openid scope has been granted, an id_token will be returned in the response.
• If the offline_access scope has been granted, a refresh_token will be returned in the response.

The refresh_token grant type is used to periodically exchange a refresh token for a new access token without user interaction. When using the refresh_token grant type, a refresh_token must be provided.

This endpoint returns different responses depending on the client being used:

• If a First Party Public or Third Party Public client is used, the original refresh token sent in the request will be rotated out and a new refresh_token will be present in the response. You must save this new token for next time.
• If a First Party Confidential or Third Party Confidential client is used, no token rotation will occur. The refresh token used in the request will remain valid for future use and no new refresh_token will be present in the response.

Connected App Access Tokens and ID Tokensare JWTs signed with the project'sJWKS. ID Tokens are valid for one hour after issuance. Access Tokens expiry is controlled by the client's access_token_expiry_minutes field, which also defaults to one hour.

You can validate and examine your access and refresh tokens by using the Token Introspection Endpoint.

Access token JWTs can be validated locally by using a Stytch Backend SDK, or any library that supports the JWT protocol.

Important: Unlike other Stytch API endpoints, this endpoint is not authenticated with a project_id and project_secret pair. Instead, it is authenticated via the client_id and client_secret of an active Connected App Client within the current project.

This endpoint is an RFC-6749 compliant token issuing endpoint.

• This endpoint supports passing the client_id and client_secret within the request body as well as within a HTTP-Basic Auth header.
• This endpoint supports both application/json and application/x-www-form-urlencoded content types.