The main job of AS is to produce access tokens in the JWT format. The client and the user provide the following input information for that process:
application (via the endpoint URL), client identifier, scopes
identity, consent to the requested scopes
A resulting access token could look like this:
That’s a serialized JWT – when you copy&paste that JWT to here – you will see the following JSON string:
Issuer name of the access token
Audience (the identifier of the application the token is for)
Not before (start of validity period)
Expiration (end of validity persion)
The identifier for the client that asked for the token
The granted permissions
Subject. The unique identifier of the user (aka resource owner).
The token is digitally signed – either with a symmetric key or with an X.509 cert.
Remark: When doing an OAuth2 client credentials flow, where no user is involved, the sub claim is missing from the token.
All claims besides sub come from the AS configuration database. It’s the job of the claims transformation module to provide the sub claim. But more on that in a separate blog post.