1

Is there a standardised way of differentiating that an access token has been created through either client credentials or authorisation code flows? I know that the authorization code flow is used for user authentication and contains user personal information but besides those claims that might be attached to jwt, is there a standard good practice to know that a token has been created through a specific flow without knowing beforehand?

Stefan Rusen
  • 27
  • 6

2 Answers2

0

One option is to include a client claim, that is specific to the client that requested the tokens.

For example, with IdentityServer, you have a concept of ClientClaims that you can read more about here. ClientClaims are claims that are specific to a client and not vary depending on the user.

Access token generated by a user, also typically includes the AMR claim and access tokens using client credentials flow do not contain the AMR claim.

Read more about the AMR claim here.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • Thanks, Tore for the references, I was mainly asking about a standard way of doing this. The ClientClaims is indeed an option but this is not a standard way of doing this, for example, some Identity providers add a "sub_type" claim with a user/client value, and other identity providers have some other way of doing this. Regarding the AMR claim, this is mainly somewhat standardized in OIDC but it's mainly used for user-based authentication to specify which authentication was used. – Stefan Rusen Jun 14 '23 at 09:47
  • Yes, but if the AMR is missing then the client is using client credentials flow. But if you compare an access token with Authorization code flow vs client credentials, then they look almost the same and as an API , you should not need to care about the difference. As an API you should authorize the token based on the other parameters in the token. like audience, scope... – Tore Nestenius Jun 14 '23 at 09:52
0

For most providers, the sub claim will not be in the access token if the client credentials flow was used.

In OAuth 2.0 and OIDC, sub is meant to be the user that authenticates and is giving the client authorization. In a client credentials flow, there is no user. Therefore, no sub claim.

Example:

{
  "client_id": "12345678-1e82-4b65-5422-5d5a2412f604",
  "iss": "https://auth.server.com/12345678-d2f0-2685-8ec0-cf4cafd35d25/as",
  "iat": 1686873337,
  "exp": 1686873637,
  "aud": [
    "abc"
  ],
  "scope": "abcScope"
}

The other flows require a user to authenticate and grant authorization. Those tokens should have a "sub" claim. Example (where sub is the user's ID):

{
  "client_id": "fa902d6a-aa45-0505-a7c6-a44b531c7636",
  "iss": "https://auth.server.com/12345678-d2f0-2685-8ec0-cf4cafd35d25/as",
  "iat": 1686873658,
  "exp": 1686877258,
  "aud": [
    "https://api.server.com"
  ],
  "scope": "openid profile",
  "sub": "1732f103-1a0b-2244-123c-7977000e2154",
  "sid": "2da96319-e069-4be8-aebe-71087012509b",
  "env": "12345678-d2f0-2685-8ec0-cf4cafd35d25",
  "org": "a6fdcde8-0ae2-4b3c-08de-012345678912"
}
akdombrowski
  • 673
  • 4
  • 9