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:

• Client
  application (via the endpoint URL), client identifier, scopes
• User
  identity, consent to the requested scopes

A resulting access token could look  like this:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
eyJpc3MiOiJUaGlua3RlY3R1cmVBdXRob3JpemF0aW9uU2VydmVyIiwiYXVkIjoidXNlcnMiLCJuYmYiOj
EzNzE0OTM1NTAsImV4cCI6MTM3MTQ5NzE1MCwiY2xpZW50X2lkIjoiY29kZWNsaWVudCIsInNjb3B
lIjpbInJlYWQiLCJzZWFyY2giXSwic3ViIjoiZG9taW5pY2sifQ.
pcmbseDO9_sp2wQpkJTQhmu_CqDJQHC-N5HqIltByvM

That’s a serialized JWT – when you copy&paste that JWT to here – you will see the following JSON string:

{
    “iss”: “ThinktectureAuthorizationServer”,
    “aud”: “users”,
    “nbf”: 1371493550,
    “exp”: 1371497150,
    “client_id”: “codeclient”,
    “scope”: [
        “read”,
        “search”
    ],
    “sub”: “dominick”
}

• iss
  Issuer name of the access token
• aud
  Audience (the identifier of the application the token is for)
• nbf
  Not before (start of validity period)
• exp
  Expiration (end of validity persion)
• client_id
  The identifier for the client that asked for the token
• scope
  The granted permissions
• sub
  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.

HTH