OAuth and Open ID Connect¶
Read more about https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth
The ForwardAuth make heavy use of the Access Tokens and ID Tokens. Its actually what the application is all about, it retrieves, validates, verifies, parses and checks the Access Tokens and the ID tokens and its content to make sure that the user has access to the URL he/she requested. The two tokens come from two different specifications and serves different purposes.
The ID Token comes from the OIDC spec, and is for authentication, eg. the user profile
The Access Token comes from the OAuth2 spec, and is for authorization, eg. the user access assertions.
There is also a Refresh token also from the OAuth2 spec, but its not in use in the ForwardAuth application.
From the Auth0 documentation describing the difference between Access Tokens and Id tokens
Note that the audience value (located in the aud claim) of the token is set to the application’s identifier. This means that only this specific application should consume the token.
You can think of the ID Token as a performance optimization that allows applications to obtain user profile information without making additional requests after the completion of the authentication process. ID Tokens should never be used to obtain direct access to resources or to make authorization decisions.
The ID token is only to be consumed by the ForwardAuth application that requested it, it shouldn’t be read by other applications.
Don’t limit access based on content in the ID Token. The Id token is for transferring the user profile, not for authorization.
More from the same Auth0 documentation about Access Tokens
The Access Token is meant to authorize the user to the API (resource server). As such, the token is Completely opaque to applications – applications should not care about the contents of the token.
The token does not contain any information about the user except for the user ID (located in the sub claim). The token only contains authorization information about the actions that application is allowed to perform at the API (such permissions are referred to as scopes).
Use the content of the Access Token to make authorization decisions.
Use scopes to define permissions.
Traefik ForwardAuth application shouldn’t do anything with the Access Token.
The receiving API can do whatever it wants with the Access Token.