The Token Service is the profile of Curity responsible for issuing security tokens, by which the server asserts data for use in a particular context. Example tokens that can be issued through the Token Service are OAuth Access- and Refresh Tokens and OpenId Connect Id Tokens.
A tokens is issued in response to an application’s request. Depending on the claims that are made in a token, it can serve multiple purposes. OAuth Access Tokens are meant to delegate a user’s authorization decision to an application, whereas an OpenId Connect Id Token is a statement, made by the Token Service, about an identity and how that identity was established. The application that requests a token, is referred to as a Client.
The claims that are made in a token, are commonly bound to an authenticated user (i.e. the token’s subject), attributes of that user (e.g. name, role within an organization, etc.), as well as delegated authorization that was requested by the client (e.g. Scopes and Claims that may be used as permissions). It is also very common to include information about the authentication context by which the token’s subject was established in a token, which is what OpenId Connect specifies for Id Tokens.
As there are multiple application types, there are also multiple ways that the application can request a token. These different requests are handled by a different flow within Curity. Examples of flows are the Code flow, designed for web applications; the Assisted Token flow, designed for Single Page Applications; the Client Credentials flow, designed for server-to-server scenarios; etc. Different flows have different interactions to fit their particular use.
To represent a token, Curity stores the user delegation data, and issues tokens based on this information. Using this model, it is possible to issue multiple tokens from the same delegation, where different tokens can have different lifetimes, different permissions or different claims made inside them. The process of issuing tokens uses Token Procedures, that by default follow standards, like OAuth and OpenId Connect. These procedures can be fully customized through scripting or plugins though, so tailor made tokens can be issued as well.
When user authentication is required, i.e., when the subject is being included in issued tokens, the Token Service relies on a configured Authentication Service profile. This nicely separates concerns, leaving authentication where it is done best.
Fig. 145 Overview of Token Profile components