I keep hearing a lot of questions about the JWT token draft and in particular what should go in "sub" (Subject) claim. In the context of an access token, there is confusion about whether it is the resource owner or the client.
Part of the problem is that JWT's can be used in multiple different ways. Thus content can and should vary: 1. An identity assertions (such as an authentication) 2. As access tokens (such as an authorization) In the OAuth context then, 1 is input to the authorization process and it seems reasonable to follow typical terminology and profiles found in classic federation. But under 2, this terminology seems week since it doesn't express what an access token should necessarily express. An access token should problem carry the following in order of priority: 1. An integrity check (either in the token itself or a lookup via RS to AS call) 2. A positive access control decision (authorizing a set of scopes/roles/rights) the bearer may have 3. Security session information (see openid connect for example) 4. Identity claims (of the resource owner and/or the client app and/or other intermediary parties) When it comes to access tokens, it seems reasonable that in some cases, 3 and 4 may not even be present. Particularly if the bearer or authorizing resource owner needs to be anonymized. What matters is that the bearer of the token has the right to access a resource. In other cases, 4 is needed in part to facilitate JIT provisioning. My concern is that the current JWT spec is too biased towards passing identity assertions and is not neutral enough for authorization information. I would rather see the JWT spec do both jobs, or be a foundational spec for 2 or more profiles that do assertions or authorizations. Phil @independentid www.independentid.com [email protected] _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
