Token-Based Authentication

  • is a method that allows users to enter their username and password in order to obtain a token that allows them to make a specific request - without using their username and password. Once their token has been obtained, the user can offer the token - which offers access to a specific resource for a time period - to the remote site

Authentication/Authorization/Delegation Entities

Token Classes

refer to Actors

Authentication/Authorization Token intended for the Application Client to be able to access other token(s) from the Security Token Service (STS). tokens such as:

  • Access Token
  • Refresh Token
  • ID Token

Token Class

Description

Access Token

  • intended for the Application Client to make secured API calls to the Resource Holder (on behalf of Resource Owner)
  • like a session
  • a type of “by-reference/opaque token”

Refresh Token

  • intended for the Application Client to obtain a new Access Token from the Security Token Service (STS)
  • like a password
  • a type of “by-reference/opaque token”

ID Token

  • intended for the Application Client to know about the Resource Owner
  • introduced in OpenID Connect (OIDC)
  • a type of “by-value token”, unlike Access Tokens and Refresh Tokens that are opaque to the client, ID Tokens contains information about the resource owner for the client
Link to original

Access Token - Pass Types

Access Token Pass Types

Description

Example Implementation

Pass-By-Reference

  • the standard form of an access token — without extraneous content, simply used for a client to make a protected call to the Resource Holder on behalf of the Resource Owner
  • IF the protected call is specific to a Resource Owner, then the Resource Holder requires knowledge about the Resource Owner, this binding between token and info is done by:
    • translating the token into a pass-by-value token (this is done at API Gateway, where it validates the pass-by-reference token against the STS and receives its corresponding pass-by-value token. The API Gateway then injects the Pass-By-Value token into the internal system where it gets passed around like hot-potato)
    • setup a user-session cache server (e.g. Redis) and allow the Pass-By-Reference token to be passed around the internal system. Whenever an internal service receives this token it fetches the Resource Owner’s info from the user-session cache server

Pass-By-Value

  • an access token that contains information about the Resource Owner

Access Token - Profile Types

  • Holder of Key (HoK) Tokens - like a credit card, ensures that the Client presenting the token is the one it was issued to
  • Bearer Tokens - like cash, do not ensure whether the Client presenting the token was actually issued it

Access Token - Types

Token Type

Description

API Keys - Authentication Tokens

  • secret key/token always traveling with a request
  • usually opaque (i.e. pass by reference) cannot contain any meaningful data

WS-Security Tokens (esp SAML Tokens)

Legacy Tokens

  • those issued by a Web Access Management System (WAMS)

OAuth Access Tokens

  • OAuth is basically a way to separate the Authentication Process from the Access to the Resource and therefore limit the exposure of the credentials

JSON Web Tokens (JWT)

  • used in OpenID Connect as an ID Token implementation
  • ability to be transparent (i.e. pass by value) allows data to be embedded within the token itself, such as who logged in, what kind of credential was used, when login occurred, was SSO cookie used, or did the user login afresh, various attributes/claims about the user (e.g., first name, last name, customer number, etc.)

Resources