[TSG-Access-RD] ID Tokens, Access Tokens, and Third-Party Authorizers

Hollenbeck, Scott shollenbeck at verisign.com
Thu Feb 28 14:25:14 UTC 2019


Folks, I think I need to make some changes to our model based on a fresh reading of what's what from a token perspective.

We currently say that ID tokens are OPTIONAL and access tokens are required. We have that backward. Here is an example of what the payload of ID token in JWT format can contain:

{
  "iss": "accounts.google.com",
  "azp": "459439924005-pi97copm2c25ht80sn4lmd4a0a3q9pd0.apps.googleusercontent.com",
  "aud": "459439924005-pi97copm2c25ht80sn4lmd4a0a3q9pd0.apps.googleusercontent.com",
  "sub": "103892603076825016132",
  "email": "sah6284 at gmail.com",
  "email_verified": true,
  "at_hash": "eeqP6eJsX2aNb0b_L2zTvA",
  "iat": 1551362510,
  "exp": 1551366110
}

Note that it contains the claims that identify the requestor. The access token can be a JWT or an opaque string, but it doesn't contain the claims that a third-party authorizer would need to see to identify the requestor as part of making an authorization/access control decision. The access token can be used by the third-party authorizer to request information from the IdP *if it's needed*. More info here:

https://auth0.com/docs/tokens

>From an RDAP perspective, the access token can be sent in an HTTP Authorization header (Authorization: Bearer <token>) and the ID token can be sent as a query parameter. My draft currently has them both being sent as query parameters, but that probably needs to change, too.

I'll get into the document and make the changes.

Scott


More information about the TSG-Access-RD mailing list