As such, they have access to all of the Common Procedure API.
The basics of how token procedures work is explained in the Token procedures page.
Below, links to the reference documentation are provided, as well as an overview of the token procedure API’s main parts.
The context object is provided as an argument to the result function of each token procedure.
This object has a number of common functions and properties that always exist.
These are described in this section.
The types of the context object given to each kind of token procedure is shown at Procedure Context object.
Before issuing a token, a token procedure must obtain the basic claims that the token must contain. This is referred
to as the token data.
For example, the default token data for an access token can be obtained by calling the
For a delegation (which is an authorization grant from which tokens may be produced), there’s an equivalent method,
See also getDefaultRefreshTokenData, getDefaultIdTokenData, getDefaultDeviceCodeData
Once a token procedure builds the token data, it must, of course, issue the token. For that, it needs to use a TokenIssuer.
As with token data, procedures obtain an issuer via Procedure Context object.
The most common token issuers are:
Token procedure context objects expose the request object, which contains full data about the HTTP
ScriptRequest sent by the OAuth OAuthClientConfiguration.
However, for convenience, it also exposes the following directly:
In cases where the client presents an existing token, the token is available as well:
The JSON data returned by Curity on token requests will include the data returned by the token procedure.
The context ‘s defaultResponseData property returns appropriate response data the procedure may want to use for that.
Several utilities are available to help token procedures, all accessible directly via the context object: