0

I've begun an implementation using the OpenID Connect Implicit Flow - I've retrieved my access token and ID token in my browser based javascript app, and now I need to protect the resource on my ASP.NET Core Web API so it can only be accessed via a valid access token from a user with a specific claim.

What middleware do I use to validate the token(s) and determine the user and their claims so I can then allow or deny them access to the resource they are requesting?

I've looked at OpenIdConnectAuthentication middleware, however the only implementation examples I've seen use a SignInScheme of "Cookies", not the Bearer token that my js app is providing.

Thanks

Steve
  • 1,584
  • 2
  • 18
  • 32

1 Answers1

2

What middleware do I use to validate the token(s) and determine the user and their claims so I can then allow or deny them access to the resource they are requesting?

If your authorization server issues JWT tokens, you can use the JWT bearer middleware developed by the ASP.NET team: https://github.com/aspnet/Security/tree/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer.

app.UseJwtBearerAuthentication(new JwtBearerOptions {
    Authority = Configuration["jwt:authority"],
    Audience = Configuration["jwt:audience"]
});

You can find a sample here: https://github.com/aspnet/Security/tree/dev/samples/JwtBearerSample.

Kévin Chalet
  • 39,509
  • 7
  • 121
  • 131
  • Thanks very much for the reply Kévin (you do great work!). I have looked at the JwtBearer middleware but it doesn't appear to include making a request to the UserInfo endpoint to get the claims to then use in the request. Not only that but I can only get it to work with the ID Token and not the Access Token (which from what I've read I think I should be using) as per this post (http://stackoverflow.com/questions/38394545/usejwtbearerauthentication-signing-key). Can you provide any further assistance for me? Thank you! – Steve Jul 18 '16 at 03:34
  • 1
    In theory, the userinfo endpoint is only used by the client application to retrieve data about the authenticated user, not by the resource server: the access token should contain all the claims it needs to correctly identify the user. If the access token can't be directly read by the resource server, an option is to use the introspection endpoint provided by your authorization server, if it's supported. Note that I don't recommend using the identity token to query your API. It's not issued for that. – Kévin Chalet Jul 18 '16 at 10:25
  • Thanks again. That has raised a whole lot more questions. For example, how would I validate the access token without the ID token in the RESTful api as the spec indicates I need the ID token (http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowTokenValidation). Another question is whether the implicit flow is even the right flow for SPA with RESTful api with external IdP. Plus lots more. Do you know a forum to ask these sorts of questions as apart from yourself I'm struggling to find good answers and implementations to these questions? – Steve Jul 18 '16 at 22:00
  • 1
    Unlike clients/relying parties, resource servers don't need the identity token to validate access tokens, as they don't need to bind them with a particular user/session: validating the signature, the issuer, the audience and the expiration time is generally enough to ensure a token is valid. The implicit flow is totally appropriate for SPA apps. If you have questions about OpenID Connect, feel free to open new tickets, I'm pretty sure you'll find someone to answer them (maybe me?) :) – Kévin Chalet Jul 18 '16 at 23:31
  • And again my understanding becomes hazy - am I right to view the RESTful API as the resource server and not the relying party? Even if it's the same web server as the SPA? It's the validation and verification of the access code by the RESTful API that I keep hitting a brick wall at. Should the *kid* of the access token match one of those in the jwks_uri? To get the JwtBearerAuthentication middleware to work it needs to but doesnt, and I doubt my external IdP (Okta) would supply me an invalid access code (I can use the access code to call the user_info endpoint manually). Thanks for ur help – Steve Jul 19 '16 at 00:19
  • 1
    `am I right to view the RESTful API as the resource server and not the relying party?` > that's right. `Should the kid of the access token match one of those in the jwks_uri?` > ideally yes. But it's not mandatory and access token might not even be JWT tokens, specially if they are not meant to be used by your own APIs, but only with Okta's own services (it's even the most common scenario: e.g Google and Facebook issue opaque access tokens that are only usable by their own services). – Kévin Chalet Jul 19 '16 at 00:22
  • Can I trouble you for one more question then I'll stop (for this post at least ;) )... Do you have any suggestions of what I should do now that I have an access token with a kid that doesn't match the ones in jwks_uri and the JwtBearerAuthentication checks these therefore I can't use it? Surely I do not have to roll my own authentication middleware! – Steve Jul 19 '16 at 04:22
  • 1
    You should contact Okta and ask them if you can use the access tokens they issue to protect your own APIs. If they say no, then one option is to create your own authorization server to issue your own tokens (that can be validated by your APIs) and treat Okta as an external authentication provider. – Kévin Chalet Jul 19 '16 at 07:57