Building a Web-API with Oauth2/OpenID connect

Question

I'm trying to understand conceptually and practically how to perform an oauth2 with openID-connect flow in my web-api application, utilising Azure AD.

Importantly, when a request is made to the API I want to know who made the request.

My current understanding is :-

1. My client would detect that the user isn't logged in and redirect to a sign-in.
2. The user would provide their credentials, and be redirected back to the client, along with an oauth2 token.
3. This token would be supplied to web-api endpoints for any requests.

This is where it gets murky for me.

How exactly do I use this token to authorize access to a particular resource, determine who is accessing the resource, and what is the mechanism that does so?

I'm sort of assuming that I would need to reuse the token to make a call to the Azure AD user endpoint - if the token was indeed valid, the AD endpoint would return the users details - thereby providing some means of determining that the token is valid and providing details on the users identity. Authorizing access to a resource could be done through membership of groups in Azure AD.

BUT ...

I can only assume this a solved problem, and have noticed use of OWIN middleware as per this example

https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet

But I'm still rather unsure as to what is exactly going on.

The service makes mention of scopes and claims, but I don't understand where these are derived from (I assume from a token supplied by the client, but not sure). The service must be receiving identity information in the call.

Which brings me to two points, for this to be secure -

1. The token provided in call to the service would need to be secured in transmission (hence the use of HTTPS) - to prevent MITM.

2. The token would need to be signed some how - I guess by using client secret or something - to prevent information in the token being spoofed.

Can someone help me clear up this muddled mess?

In particular -

1. How is the identity of the API caller determined - is identity determined from a call in the client or the server?

2. How to limit access to some endpoints of the API based on a user role?

3. What do I do to practically achieve this by building on existing middleware and libraries available to me?

Answer 1

Apart from question #1 (the identity is verified on the service side) all your question are very open ended and would require a super long answer. I would recommend reading https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ - it is a good introduction to the flows underlying many of the modern authentication cenarios, including the web API one you are focusing on. Once you have read that, you will find a complete set of samples in https://azure.microsoft.com/en-us/documentation/articles/active-directory-code-samples/ - in particular, I suggest studying the web API and thru authorization one to find guidance on the 3 questions you listed. HTH!

Answer 2

Disclaimer: This will not be a comprehensive answer. It is off the top of my head.

OpenID Connect provides an identity layer on top of OAuth. In your case, Active Directory provides the authentication and sends back an access_token. The access token represents a user that AD has authenticated. If your doing OpenID Connect, then AD will also send an id_token, which may contain additional identity information (such as birthday, avatar, and whatever else AD exposes.)

Neither OpenID Connect nor Active Directory have anything to do with the the roles that your app assigns to a user; roles are entirely the bailiwick of your app. You assign user roles just like you normally would; you assign them to the nameid though instead of to an email address or username. Your app no longer has to authenticate the user but it does need to assign roles to the nameid.

How is the identity of the API caller determined - is identity determined from a call in the client or the server?

The identity is embedded in the access_token that AD includes in its response. This token will have a nameid in it that your app can associate with a user and role. The nameid is like an email address, username, or other uniqueID that your app uses to recognize the user.

How to limit access to some endpoints of the API based on a user role?

You choose. When your app receives a request with a particular access_token, that token will be associated with a particular user via its nameid, and you can assign whatever roles and rights to that user. Basically, associate roles with a nameid.

What do I do to practically achieve this by building on existing middleware and libraries available to me?

There is an unfinished demo here, though it doesn't use Active Directory as the provider, instead, it uses an internal provider. For the demo, the username is shaun and password is Testing123!. The source code is here.

Here is the link to the source of another demo, though again, it doesn't use Active Directory as the provider, instead, it uses Twitter.

The nice thing about OAuth and OpenID Connect is that we can use whatever identity provider we want, so you can adapt the demos to use Active Directory.