JavaScript SDK access tokens and codes

📘

The content on this page deals with a legacy feature of the ​Akamai​ Identity Cloud (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 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_nativeoauth/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 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.