Formatting Okta Authorization Headers for SSWS and OAuth 2.0 Bearer Tokens
Last Updated:
Overview
When using tokens for authorization in Application Programming Interface (API) calls, the required keyword in the authorization header depends on the token type. Formatting the authorization header correctly for an SSWS API token or an OAuth 2.0 Bearer token ensures successful API authentication and prevents authentication failures.
For example:
- SSWS API Token:
Authorization: SSWS <api_token> - OAuth 2.0 Bearer Token:
Authorization: Bearer <access_token>
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Application Programming Interface (API)
- Okta API token
- OAuth 2.0 access token
- Authentication
Solution
What is the correct format for an SSWS token?
Okta uses an SSWS token, a proprietary API token, for authenticating requests to its own APIs. The "SSWS" keyword remains specific to Okta and signals the authentication type to the servers.
Format the header using the SSWS keyword followed by the API token.
- Format:
Authorization: SSWS <api_token> - Example:
Authorization: SSWS 00QCjAl4MlV-WPXM...0HmjFx-vbGua
This header tells the Okta API that a long-lived API token, generated within the Okta Admin Console, authenticates the request.
The OAuth 2.0 Bearer Token Uses an Industry-Standard Format
OAuth 2.0 serves as an industry-standard protocol for authorization. The "Bearer" token represents the most common type of issued token. The Bearer keyword indicates that the party possessing the token has access to the associated resources. This standard applies widely and extends beyond Okta.
Format the header using the Bearer keyword followed by the access token.
- Format:
Authorization: Bearer <access_token> - Example:
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImYxZ...
An application uses this header when making API calls on behalf of a user or itself after completing an OAuth 2.0 flow. These tokens are typically short-lived.
