I'm implementing OAuth 2 with OIDC.
This answer was helpful regarding the OIDC JWT OpenID Connect JWT token verification and usage strategy for backend api - jwks or session?
After the flow has completed, how do I use the OAuth 2 Access Token with my WebAPIs? I'm not understanding what I need to add into my WebAPI controllers to grant or deny access using the Access Token.
Should I be using the Access Token if I'm already using Roles for authorization?
Thank you for your help.
The purpose of OAuth 2.0 is to allow a client to access protected resources if allowed by the resource owner.
In other words, or in the most common case, a user comes to your app and wants to see some private info or perform some sensitive action. So, you want a way for your app to be able to make sure that this user is indeed allowed access to see or do those things. OAuth helps with this.
The access token your app gets back from the Authorization Server in an OAuth flow is proof that the resource owner, aka the real user, has authorized the client access, aka the real user has agreed to allow your app access to the info or actions. Then, the user can see their sensitive info or perform those sensitive actions.
But, that info or those actions to be performed might come from or happen somewhere else, aka somewhere accessed via APIs. So, you make an API request to get that info or perform some action and include the access token. The server receiving the request can then check that access token to make sure that the requester is in fact authorized.
Making that check will depend on the type of access token, but typically it's a JWT. In that case, the signature should be verified, expiration checked, and scopes adhered to.
The signature is to verify in order to make sure the claims in the JWT or token haven't been tampered with. Once that's verified, then you know that the expiration and scopes are actually the values that were sent from the Authz Server. Often the signature is calculated with HS256 or RS256. Links below on steps to validate.
Or, hopefully, because this is all very complex and difficult and easy to make a small mistake somewhere and risk compromising your security, the authorization server has an introspection endpoint. Your resource server, whatever is receiving those API requests, sends the access token to the introspection endpoint for the Authz Server to verify for you, and you should get a response back whether the access token is valid. If you don't need to use anything in the access token, then you can send the access token to whatever server requires that token to give up info or let you perform some actions.
OAuth 2.0 Accessing Protected Resources: https://www.rfc-editor.org/rfc/rfc6749#section-7
Validating a JWT: https://datatracker.ietf.org/doc/html/rfc7519#section-7.2
Validating a JWT (JWS) signed with HS256: https://www.rfc-editor.org/rfc/rfc7515.html#appendix-A.1.2
Validating a JWT (JWS) signed with RS256: https://www.rfc-editor.org/rfc/rfc7515.html#appendix-A.2.2