Please help me to clarify the "access token" vs "ID token" terminology confusion

Questions
1

I want to implement JWT token generation for a Daml ledger using Amazon Cognito as an OAuth Service Provider. (You have excellent guides for doing the same using Auth0 as OAuth Service Provider, but in this project Cognito is preferred.)

The challenge is to put the custom Daml ledger claims into the token payload, as the following example shows:

{
2   "https://daml.com/ledger-api": {
3     "ledgerId": "aaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
4     "participantId": null,
5     "applicationId": null,
6     "admin": true,
7     "actAs": ["Alice"],
8     "readAs": ["Bob"]
9   },
10   "exp": 1300819380
11}

The Daml documentation consequently calls the JWT tokens necessary for API calls access tokens, according to the OAuth 2.0 terminology.

On the other hand, Cognito uses the newer, OIDC terminology:

Amazon Cognito user pools implements ID, access, and refresh tokens as defined by the OpenID Connect (OIDC) open standard:

  • The ID Token contains claims about the identity of the authenticated user such as name , email , and phone_number .
  • The Access Token grants access to authorized resources.
  • The Refresh Token contains the information necessary to obtain a new ID or access token.

I have found a blog post which explains How to Use Cognito Pre-Token Generation trigger to Customize Claims In ID Tokens.

For this blog post to be useful for me, I need to understand what category the Daml JWT token belongs to according to the Cognito terminology: access token or ID token?

Could any of you help me with that?

1 Like
2

TL;DR

Daml’s JWTs are access tokens, as they describe the rights and access over the resources (in this case, the ledger).

More words

Identity tokens are granted to you in order to authenticate you (you are who you say you are); this is the equivalent of holding an ID card that anyone can use to verify you are who you say you are.

Access tokens are granted, typically by exchanging an identity token, in order to authorize your access to a resource; this is the equivalent of a brick-and-mortar bank looking at your ID, deciding they trust it, and then using that trust to decide to grant you access to specific resources in the bank (namely, your own back account).

Note that this brick-and-mortar bank can not authenticate your identity—they merely use your confirmed identity to authorize you access to something. Likewise, a government behind a government-issued ID does not authorize your access to your bank account; the government merely speaks to the authenticity of your identity.

In your case, your Cognito lambda trigger takes the identity from Cognito (which your trigger trusts as having been properly authenticated) and then makes a decision about what to authorize that identity to; Cognito uses your supplied information to provide a signed access token from the raw information you provide (namely, the claims that the ledger expects).

Hope this helped!

5 Likes
3

Than the title of the blog post is inaccurate?

1 Like
4

Or I need to find another blog post which disusses how access tokens can be configured?

1 Like
5

From this StackOverflow thread it seems that I cannot add custom claims to access tokens:

Custom attributes are not available in Cognito access token. Currently it is not possible to inject additional claims in Access Token using Pre Token Generation Lambda Trigger as well. PreToken Generation Lambda Trigger allows you to customize identity token(Id Token) claims only.

The official documentation of the Pre Token Generation Lambda Trigger also mentions only id tokens:

Amazon Cognito invokes this trigger before token generation allowing you to customize identity token claims.

https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html

Does this mean that I cannot use Cognito to configure Daml JWT tokens?

1 Like
6

I’m not familiar with Cognito (and really just beginning to look at Daml auth), but from a brief look at their landing page it looks like they really do authentication, which means you can still use it for that.

I’d suggest a setup in which you host a “login” web application (possibly custom built yourself) which essentially just needs to:

  • Redirect login (authentication) to Cognito, and
  • Once users are logged in, issue them a token with Daml-specific permissions (authorization).

It should end up being a fairly small web-app that just ties together HTTP, Cognito and JWT generation, all of which likely have libraries available in many languages.

That application would then be your token/public cert provider as far as the Daml components are concerned.

2 Likes
7

Thanks, will try

1 Like