OpenId Connect Token Validation in Web service using Owin

Question

Currently In my web service I leveraged app.UseWindowsAzureActiveDirectoryBearerAuthentication to validate AAD issued tokens and its awesome! I would like to do something similar for any OpenId Connect tokens but I am not sure if UseWindowsAzureActiveDirectoryBearerAuthentication is the correct one since it is specific for AAD and it says nothing about the underlying protocol. It seems the only other two options are app.UseJwtBeararAuthentication and app.UseOAuthBeararAuthentication. The identity provider I will use will most likely support discovery so the idea is to simply register the valid audience, issuer and discovery or metada url and let the authentication middleware take care of the rest (retrieve the sign key, caching it, validate expiration, issuer, audience, etc) just like I do with UseWindowsAzureActiveDirectoryBearerAuthentication. Which one of those two middlewares is the recommended one?

Answer 1

Both app.UseWindowsAzureActiveDirectoryBearerAuthentication and app. UseJwtBearerAuthentication calls UseOAuthBeararAuthentication middleware internally. Former is for xml where latter is for jwt tokens. I would recommend app.UseJwtBearerAuthentication is that meets your requirements.

Answer 2

There isn't really any magic sauce that OpenID Connect adds when you are accessing a web service, it's all more or less the same as OAuth2. You keep using the “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750 for that. The tokens that are sent to web API are access tokens, which remain opaque even in OpenID Connect. The machinery you are describing is for id_tokens, which are all obtained through grants that rely on the app being delivered via a browser (hence not web services, but web apps serving a UX or native clients). In the case of a web service a client is not necessarily a web browser, which is why you normally stick with the RFC 6750 for accessing it. Now: Azure AD happens to use the same token format and the same signing keys for both id_token and access token, whihc is probably why you thought the approach could have been generalized - but no specification mandates anything at all about access tokens hence it is an approach that does not generalize to other providers - for web services/API. It does for web UX.