Filtering claims in handler

[aspnet-contrib]

Filtering claims in handler

[manfredsteyer]

Ok, I've got it. great idea!

[kevinchalet]

For reference, here's the commit who introduced the "destination" switch: e775161.

Here's how it works:

• for access and refresh tokens, all claims are copied from the ambient ClaimsIdentity unless they explicitly provide a destination that doesn't include "token". Because access and refresh tokens are most of the times opaque for the client, including all claims by default seemed a good compromise between confidentiality and usability.
• for identity tokens, that's an inverse reasoning (because JWT tokens are not opaque for the clients): claims are not added to the identity token unless they explicitly specify an id_token destination.

Note that you can combine both switches by specifying an id_token token destination 😃

[kevinchalet]

With access tokens now being JWT tokens by default, the behavior described in my previous post has changed:

• Refresh tokens and authorization codes: when they are not explicitly provided through the CreateAuthorizationCode/CreateRefreshToken notifications, authorization codes and refresh tokens are serialized using a data protector and claims are never filtered.
• Identity tokens and access tokens: these tokens can be natively created using a security token handler, a data protector or using the CreateIdentityToken/CreateAccessToken notifications.
  • When they are created using CreateIdentityToken/CreateAccessToken, it's up to the implementer to correctly filter the identities before serialization if the returned tokens are not opaque. To make it easier, new ClaimsIdentity.Clone extensions have been added to the extensions package: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/blob/dev/src/Owin.Security.OpenIdConnect.Extensions/OpenIdConnectExtensions.cs#L305
  • When they are created using a security token handler, claims are automatically excluded if they don't explicitly contain the id_token or token destination.
  • When they are created using a data protector, these tokens are assumed to be opaque and claims are only excluded if they contain an explicit destination that doesn't include id_token or token.