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.
(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.
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.
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.
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.
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.
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.
Shamir Charania, a seasoned cloud expert, possesses in-depth expertise in Amazon Web Services (AWS) and Microsoft Azure, complemented by his six-year tenure as a Microsoft MVP in Azure. At Keep Secure, Shamir provides strategic cloud guidance, with senior architecture-level decision-making to having the technical chops to back it all up. With a strong emphasis on cybersecurity, he develops robust global cloud strategies prioritizing data protection and resilience. Leveraging complexity theory, Shamir delivers innovative and elegant solutions to address complex requirements while driving business growth, positioning himself as a driving force in cloud transformation for organizations in the digital age.