Clarify the usage of ID token for authenticating to an API you own

Get Help
2

Hi @omar.dfin

I would say our documentation takes a hard stance on these topics because it describes generic architectures, the most common use cases. The OIDC and OAuth2 protocols (the subject of the documentation you point) are very clear in the semantics of the different type of tokens:

  • The ID token contains information about the user and the authentication act
  • The Access Token represents the credentials to access a protected resource. In the most common usage of OAuth2, it represents the delegated permission given by a user to a client application to access the user’s resources.

Using the ID token as a bearer token for authorization is fine in some specific scenarios (the ID token is, after all, a cryptographically signed token issued by a trusted party). Make sure you understand that:

  • This is only safe when the front and backend are two parts of the same application, and you use the ID token only from the front end to its corresponding back end. If you need a common backend shared by different clients, you should define the backend as an API and use access tokens.
  • This shouldn’t be used for third-party applications.
  • The ID token might contain PII information about the user, which you will be sending along with every request to the backend.
  • You should use an asymmetric signing algorithm (RS256), otherwise any client in possession of the client secret could forge tokens.
  • As always, you should verify the aud claim. Under this usage, the audience of the token received in the backend will match the single client ID shared between the frontend and the backend.
  • You won’t be able to use scopes to limit the things that the token is capable of.
  • This design won’t let you open your backends to potential third-party clients.

Hope this helps!

2 Likes