The access token response for a particular user should, likely, be kept separate from the concept of the user identity. For instance, a secretary's identity may not change, but their authorization may include manipulating things for their (multiple) execs. In short, the audience for either token will vary.
At the same time, we should reduce the amount of processing required to validate any particular token. For access tokens, the basic random string bearer token should be replaced by a signed JWT, which contains sufficient information to validate that token and its access rights. From a practical perspective, this means keeping the token to less than 2000 characters when encoded, because of IE's restrictions, so we may need to add a configuration flag that controls that.
All tokens should contain the following:
iss: The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.aud: The audience, in this case our client_id. This SHOULD be an array of lists.iat: Issued-At Time. Timestamp in UTC, seconds (not milliseconds)auth_time: Time when the user was authenticated, timestamp in seconds UTC.nonce: A string value originally set by the client, returned and encoded. This should be validated by clients.amr: Authentication Method Reference, i.e. how did we authenticate the user, expressed as an array of strings. In our case, let's make this the authenticator type: Facebook, Google, combined with the client type (client creds, implicit, etc)azp: Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This is generally there to distinguish when azp and aud are different.sub: Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. In our case, a user-based auth flow would use the user id, while a client credentials flow would use the client id.
access_tokens should also contain the following.
scope: The authorized scopes for this token.
id_tokens should contain the following.
at_hash: Used only when using the Authorization Code Flow: Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the access_token value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is RS256, hash the access_token value with SHA-256, then take the left-most 128 bits and base64url encode them.c_hash: Code hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The c_hash value is a case sensitive string. Optional if no code is included.- Any of the standard ID Token claims listed out here: http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
The access token response for a particular user should, likely, be kept separate from the concept of the user identity. For instance, a secretary's identity may not change, but their authorization may include manipulating things for their (multiple) execs. In short, the audience for either token will vary.
At the same time, we should reduce the amount of processing required to validate any particular token. For access tokens, the basic random string bearer token should be replaced by a signed JWT, which contains sufficient information to validate that token and its access rights. From a practical perspective, this means keeping the token to less than 2000 characters when encoded, because of IE's restrictions, so we may need to add a configuration flag that controls that.
All tokens should contain the following:
iss: The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.aud: The audience, in this case our client_id. This SHOULD be an array of lists.iat: Issued-At Time. Timestamp in UTC, seconds (not milliseconds)auth_time: Time when the user was authenticated, timestamp in seconds UTC.nonce: A string value originally set by the client, returned and encoded. This should be validated by clients.amr: Authentication Method Reference, i.e. how did we authenticate the user, expressed as an array of strings. In our case, let's make this the authenticator type: Facebook, Google, combined with the client type (client creds, implicit, etc)azp: Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This is generally there to distinguish whenazpandaudare different.sub: Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. In our case, a user-based auth flow would use the user id, while a client credentials flow would use the client id.access_tokens should also contain the following.
scope: The authorized scopes for this token.id_tokens should contain the following.
at_hash: Used only when using the Authorization Code Flow: Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the access_token value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is RS256, hash the access_token value with SHA-256, then take the left-most 128 bits and base64url encode them.c_hash: Code hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The c_hash value is a case sensitive string. Optional if no code is included.