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:
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:
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!
Shamir is a Microsoft Most Valuable Professional (MVP – Azure) and has extensive experience building solutions in the cloud, from strategy to deployment to automation