2

Does Azure AD issue opaque access tokens or only JWT tokens?

If yes how do you validate opaque access tokens in that case? because there is no introspection end point?

user217648
  • 3,338
  • 9
  • 37
  • 61
  • Hello @user217648, If my answer is helpful for you, you can Upvote and accept it as answer( click on the check mark beside the answer to toggle it from greyed out to filled in.). This can be beneficial to other community members. Thank you – RahulKumarShaw Dec 28 '21 at 12:04
  • Your answer doesn't answer to my question. – user217648 Dec 30 '21 at 10:38

2 Answers2

0

A JWT has readable content, as you can see for example on https://jwt.io/. Everyone can decode the token and read the information in it. The format is documented in RFC 7519.

An opaque token on the other hand has a format that is not intended to be read by you. Only the issuer knows the format.

Here's a quote from https://auth0.com/docs/tokens:

Opaque tokens: Tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token needs to call the server that issued the token.

an opaque token is a simple string it is just a reference, hence, naturally, its format is entirely arbitrarily determined by the server that issues it (hence the term "proprietary format"). The token string is determined at the time of creation of the underlying (referred-to) content, i.e. when it is paired (associated) with the contents that this token (as the reference or foreign key) refers to

some JWT frameworks only the authentication token is a JWT, but as refresh token they use opaque tokens.

For more information refer this SO thread

RahulKumarShaw
  • 4,192
  • 2
  • 5
  • 11
  • Ok thanks. But how do I validate an opaque token by Azure AD? – user217648 Dec 15 '21 at 20:52
  • The opaque token does not pass any identifiable information on the user .To validate the token and retrieve the information on the token and the user, the resource server calls the authorization server and requests the token introspection endpoint of the authorization server. – RahulKumarShaw Dec 20 '21 at 05:58
  • So you mean Azure AD has a introspection endpoint which could be called by resource server? – user217648 Dec 21 '21 at 06:58
  • @user217648 yes right! – RahulKumarShaw Dec 21 '21 at 08:09
  • RahulKumarShow-MT, no, MS says Azure AD has not introspection endpoint. It is why I asked the question. Could you please point to an article or a link that justifies what you say? – user217648 Dec 30 '21 at 10:36
0

This is an old question, but I leave this answer here for anyone who come across this.

Azure AD doesn't support introspection and opaque tokens. Instead, Microsoft has implemented CAE to address some of the concerns around access tokens, primarily the lag between changes to user account and enforcement of the policy. That is, if the user is disabled after a token is issued, as long as the token is valid, resources owner accepts it upon validation (signage, scope, etc). See this: https://learn.microsoft.com/en-us/security/zero-trust/develop/secure-with-cae

In this document, Microsoft explicitly calls out introspection as a practice they're avoiding since it impacts the experience.

CAE however, doesn't address other issues with JWT tokens such as the possibility of leaking PII data.

If one has a choice not to use Azure AD, then Auth0, Ory Kratos (or Ory Hydra depending on what the use case is) and Curity are good alternatives with support for introspection.

Amir Keibi
  • 1,991
  • 28
  • 45