I'm using OpenIdDict and Aspnet core 2.0 Identity. I have it configured (for now) to use the Password flow (Resource Owner Password Credentials Grant). The client is an Angular SPA, that I made. I have control over client and server.
I'm currently coding a custom AuthorizationHandler and it works well so far.
However, I'm a little concerned about my ClaimsPrincipal. My secured WebAPI methods are decorated with Authorize attributes
[Authorize(AuthenticationSchemes = AuthValidationDefaults.AuthenticationScheme)]
From my understanding, if I add a Policy to my Authorize, the context I get is the same as the one from my controler. It has a "User" property which I can call "HasClaims" from.
I've added a few "permission" type claims to my Principal and they do indeed show up.
Is this ClaimPrincipals built simply by decoding the bearer token passed from SPA ? If so, it does seem unsafe to trust this list of claims to do anything server side... but, the bearer token is the access_token and not the id_token and can't simply be decoded on https://jwt.io/
I could use the UserManager/RoleManager to get all my claims, server side, for the logged in user and then use that list to valide against. However, I'm worried about possible performance issues doing so...
So, I would like to know if the ClaimPrincipals I get (as the User property) of my Controller is trustable or if I should get my claims myself.
So, I would like to know if the ClaimPrincipals I get (as the User property) of my Controller is trustable.
It is. By default, OpenIddict creates and validates its access tokens using ASP.NET Core Data Protection and the authentication ticket serializer provided by ASP.NET Core (the same used by the cookies middleware to protect the authentication cookies).
These tokens are encrypted and HMACed so their content can't be altered by an attacker. For more information, you can read https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/introduction.