Microsoft Identity Platform: Series Intro

Authentication and authorization processes have come a long way since I was doing full-time web development. Without giving any exact dates, let’s say there was a time before angular, and it was in this ‘Before Angular’ (BA, pronounced BAH) time, I cut my teeth on web development. Come to think of it, this was likely the ‘Before Bootstrap’ (BB) time as well, but who’s counting?

Back in those days, we security-minded folks built web applications (or Protected Resources to use OAUTH terminology) with the idea of authentication and authorization in mind. That is to say, the authentication service and the protected resource were the same. The pattern here was quite simple and generally involved a database that acted as a source of truth for the registered users in the system and what access those registered users had.

Users who wanted access to the protected resource would provide data asserting who they were (typically a username and password). The protected resource would look that up in the database to pull a user record. This user record would be linked with a set of claims (or roles, if you prefer), which would be used for authorization decisions within the application. At the time, there was no real “set” way of doing authorization, although patterns were emerging. Generally, applications would place a user object into the session for that HTTP request. For example, one of the properties, a list of strings, would be checked before granting access to a particular function or piece of data (if you were fancy).

Many forces were being applied to the nature of applications and data that caused this simplified view of authentication and authorization to eventually change and morph into modern concepts such as OAUTH2 and OpenID Connect. The goal of this post isn’t to provide a historical account, but here are a couple of important ones:

• Monolith applications gave way to micro-applications, which caused an increase in the number of protected resources—causing decisions around replicating the truth to those protected resources or creating a bigger/better centralized “truth” for all.
• Enhanced requirements from a security perspective forced authentication to go beyond the simple username/password days, causing changes to all protected resources
• Users, faced with password and sign-on fatigue, started to want to “bring-their-own-identity,” which helped to separate the concerns of authentication vs. authorization
• There was a separation between “client” and “server” technologies (thanks javascript), which allowed for different access patterns that resulted in re-thinking how an application communicated authentication between its components
• A separation of authentication server from protected resource introduced new avenues of attack, requiring thinking to advance in how users controlled what clients could access data/services on their behalf

In short, forces on all sides (business, technical, security, etc.) mandated separating the authentication server from the protected resource. As the ecosphere of ways that users interact with protected resources (clients, in OAUTH parlance) increased, so did the need for dynamically understanding which clients were allowed to access protected resources and what they were explicitly authorized to do within those protected resources.

So, with all that preamble out of the way, what exactly is the Microsoft Identity Platform? It is effectively an authentication service that:

• Allows users to bring-their-own-identity from various sources, such as Azure Active Directory, personal Microsoft accounts, or 3rd party federated login services (or social accounts)
• Handles the brokering and authentication steps to the sources of truth while allowing for additional protections such as MFA
• Handles the authentication of OAUTH 2.0 compliant client applications
• Is also a set of open-source libraries to assist developers in handling OAUTH 2.0 handshakes
• Handles authorization processes such as consent, and admin controlled configuration for authorized client applications
• Provides a way to dynamically (and programmatically) register new client applications and secure them at scale

The goal of this series of posts is to dive more into the Microsoft Identity Platform and how you can use it to secure your applications in the wild. I hope you enjoy it!

 

About Shamir Charania

Share This Article

Comments