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 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. 144 Overview of Token Profile components