A successful authorization with Entrypage results in a number of tokens being conveyed to the resource the user is authenticating to.

Following the OpenID Connect protocol, these tokens are either ID tokens, access tokens, and/or refresh tokens.

Access Tokens vs ID Tokens

Entrypage is an opinionated platform that implements OpenID in its own way. This means it is only possible to place access-related claims in the access tokens, as they are meant to be used for authorization purposes. This is not configurable. The ID token is used for authentication purposes and as such, it contains details about who the user is. Consequently, tokens contain the following claims:

Access Tokens

Access tokens contain the following claims:

  • sub: The unique identifier of the user on whose behalf the resources are being accessed
  • role: Any roles granted to the user
  • scope: The authorization scope of the token
  • audience: The intended recipient of the token
  • iat: When the token was issued
  • exp: Until when the token is valid
  • issuer: The server that issued the token

ID Tokens

ID tokens contain all other claims, including but not limited to the following:

  • sub: The unique identifier of the user who is authenticating
  • email: The user’s email address
  • name: The user’s full name
  • given_name: The user’s first name
  • family_name: The user’s last name
  • picture: A URL for the user’s profile picture
  • iat: When the token was issued
  • exp: Until when the token is valid
  • issuer: The server that issued the token
  • etc.

Claim Management

Entrypage allows for claims to be customized on a per-user basis. This configuration can be done through the management portal or via the API. These custom claims are then automatically placed in the appropriate token, either the access token or the ID token, following the platform’s rule of separating authorization and authentication claims. This gives administrators or other applications the flexibility to add user-specific data to tokens.

API Interaction

Entrypage’s design emphasizes that the ID token and access token have distinct roles. While the ID token contains core identity information, the access token is primarily for authorization and may not have all the user details an API needs.

In scenarios where an API needs more than just a user identifier (e.g., an email address), you can use a standard OpenID Connect mechanism: the userinfo endpoint. An API can send the user’s access token to this endpoint on the authorization server to retrieve additional claims about the user.

Repeatedly consulting the userinfo endpoint can have a negative impact on your application’s performance. You should only do this when your use case absolutely requires it. Instead, you should rely on the claims already present in the tokens whenever possible.