JavaScript SDK access tokens and codes

šŸ“˜

The content on this page deals with a legacy feature of the ā€‹Akamaiā€‹ Identity Cloudd (in this case, the JavaScript SDK). If you are currently an Identity Cloud customer and are using the JavaScript SDK, that SDK is still supported. However, if youā€™re new to the Identity Cloud the JavaScript SDK is no longer available. Instead, you should use Hosted Login for your login and registration needs.


Registration utilizes several OAuth access tokens and codes through both the social and traditional authentication process. Following is an overview of each type of token and the context in which each is used.


Access tokens

Access tokens are provisioned after a successful authentication through Registration when the response type is set toĀ tokenĀ in theĀ Registration JavaScript API or as an API parameter.

They allow for scoped, time-limited access to the Identity Cloud user profile database through the Registration UI. They may also be used as authentication for someĀ /entity operations instead of a client ID and secret.

Access tokens areĀ bearer tokens and are only valid for one hour by default. The lifetime can be configured to a shorter time by ā€‹Akamaiā€‹ Professional Services, but an expiration of longer than one hour is not allowed for security reasons. Access tokens may be refreshed using theĀ oauth/token operation or provisioned manually using theĀ access/getAccessToken operation.


Authorization codes

After a user has been successfully authenticated, that user is not immediately given an access token. Instead, the user is issued an authorization code thatĀ must be exchanged for an access token (using theĀ oauth/token operation) for access to the user profile database. There are three ways that a user can obtain an authorization code:

  1. After a successful authentication through Registration (assuming the response type is set toĀ code in theĀ JavaScript settings or as an API parameter).

  2. By initiating theĀ Forgot Password?flow. Authorization codesĀ are Ā generated in the reset password workflow and are appended to the base URL set in the theĀ [password_recover_url]](doc:application-and-api-client-settings) client setting. The lifetime of the code in the reset password link is configurable in theĀ recover_code_lifetime client setting.

  3. By being manuallyĀ provisionedĀ through theĀ access/getAuthorizationCode operation.

Each authorization code is valid for one-time use only.


IDP tokens

IDP tokens are provisioned by an IDP (Identity Provider) after a successful social authentication. They allow for scoped, time-limited access to user data through the IDPā€™s APIs. IDP tokens must be converted into a Social Login token with theĀ signin/oauth_tokenĀ operation for use withĀ Registration.


Refresh tokens

Refresh tokens are only returned in the response of a successfulĀ oauth/token call when exchanging an authorization code or a previous refresh token for an access token. This allows for infinitely refreshable access tokens.

Each refresh token does not have an expiration time and is valid for one-time use only.


Social login tokens

Social Login tokens are provisioned after a successful authentication through Social Login. They allow for scoped, one-time access to user data through theĀ auth_info operation.

These tokens are also used to complete the social authentication process in API-based Registration implementations with theĀ oauth/auth_native,Ā oauth/register_native , andĀ oauth/auth_native_traditional operations. For normal login or registration, a Social Login token will be passed into theĀ tokenĀ parameter, and for an account merge process a Social Login token will also be passed into theĀ merge_tokenĀ parameter.

Social Login tokens may be provisioned manually using theĀ signin/oauth_tokenĀ operation in exchange for an IDP token.


Verification codes

Verification codes are generated in the email verification workflow and appended to the base URL set in the theĀ verify_email_url client setting. The lifetime of the code in the reset password link is configurable in theĀ verification_code_lifetime client setting.

Verification codes may also be provisioned manually through the /access operation.

Each verification code is valid for one-time use only.