Microsoft Identity Platform: OAUTH Basics

In last week’s post, I gave a brief overview of the Microsoft Identity Platform. It’s a bit hard to understand how the Microsoft Identity Platform fits into the new authentication/authorization paradigm without understanding OAuth. So let’s get started.

At its core, OAuth 2.0 is a delegation protocol. The introduction of OAuth 2 in Action draws the parallel between this delegation protocol and the use of valet keys in cars. For those who don’t have a fancy car, the car’s valet key allows the car owner to give limited access to someone else. In the simplest case, valet keys allow people to drive the vehicle but not open up the glove compartment box (which might have confidential information such as vehicle registration, etc.). Other, more advanced keys can limit how fast the car is driving or how far it can drive before the engine gets cut.

OAuth 2 performs this same function, but for the use of protected resources on the internet. Using this protocol, users can provide limited access to a client application to use a protected resource on their behalf, allowing the user and resource provider to limit precisely what that access is.

Before moving on, it’s essential to understand the major players in an OAuth 2 transaction.

First and foremost, there is the resource owner. The ‘resource owner’ is the user who was previously granted some access to a protected resource. A protected resource can be any resource that is enforcing authentication/authorization on the internet. Typically this would be a web server, hosting an application that the user has already registered. In an OAuth 2 transaction, users want to use a client application to access a protected resource. This ‘client application’ could be a thick application installed on their desktop or another web application. It could even be a Javascript application that runs ‘client-side.’ The last core component is the authentication server. Since OAuth 2 handles delegated authorization, a resource owner (and client) gets authenticated first. The following diagram shows all the players and a standard interaction.

(Image from OAuth2 in Action)

At this point in most OAuth intros, I would dive right into the authorization code grant (one of the most common ways a client obtains a valid access token to use against a protected resource), which is also known as the “OAuth Dance.” For those who want to take that path, I recommend visiting the RFC, which outlines that process. Because this series covers the Microsoft Identity Platform, which effectively represents the authentication/authorization server above, I will focus on four popular authentication processes that work with the platform.

Process 1: The authentication server authenticates the resource owner

Keeping in mind that this process is not shown in the above diagram (OAuth assumes the resource owner is already authenticated to provide authorization), the Microsoft Identity Platform acts as an authentication service. It can use multiple back-ends, including Azure AD or B2C, allowing several social authentication types. Effectively, when a client application redirects a user to the authentication/authorization server for authorization, a resource owner is first prompted for credentials to prove who they are.

Authentication (or AuthN for short, for some reason) is implemented using OpenID Connect, a protocol built on top of OAuth.

Process 2: The authentication server authenticates the client application

OAuth postulates a couple of different client application variates, namely public and confidential client applications. In both cases, the authentication server needs to keep track of which clients are created, their respective configuration and handle the authentication elements for that client application. The Microsoft Identity Platform has configurations to support both public and confidential client application authentication. It can also act as a central registry to determine which applications have been added to a given environment.

Process 3: The authentication server facilitates authorization for client applications

Remember that OAuth is a delegation protocol, and ultimately, a user is delegating part of its permission set to a client application. There are several processes involved here to facilitate the delegation. The most important one is keeping track of which resource owners have authorized which client applications. This is done via a consent process, whereby a user is prompted to give consent to a client application. OAuth talks quite a bit about TOFU, or trust-on-first-use, a process where the user is bothered for consent only the first time.

The Microsoft Identity Platform handles most of these implementation details for you, including the idea of “admin consent” (where an administrator can consent on behalf of all users) and in the cases where client applications require further consent (in the case of it requesting access to more resources than previous). Lastly, Microsoft Identity Platform handles the user side of things, allowing users to revoke consent (for example) for a client application later.

Process 4: The authentication server registers a protected resource

Typically, a protected resource needs to be registered (in some way) with the authentication server to read tokens passed to it. The Microsoft Identity Platform allows one to register protected resources (such as a web API) to use tokens issued by the identity platform for authentication and authorization decisions.

One other important process here is surfacing the authorization information (for example, scopes) that an application has available. By registering it with the authentication service, it makes these scopes available for users to consent to as part of downstream processes.

Conclusion

The Microsoft Identity Platform handles several authentication and authorization processes as it relates to OAuth. Since most of this doesn’t rely on code, these configurations are surfaced via the platform, configured by administrators when setting up desired authentication/authorization flows. In the next few posts, I will go over each of the defined processes above in more detail.

 

About Shamir Charania

Share This Article

Comments