External Identity

I'll assume you've read my first post, which is a gentle introduction to modern authentication . We now look at some of the security advantages of using Microsoft's Azure AD to act as your Identity Provider. Azure Active Directory ('AAD') is of course the cloud successor to the very successful Active Directory, a distributed directory of users introduced at around the turn of the century. Active Directory used a protocol called Kerberos (developed outside of Microsoft in the 80s and 90s) to carry out that all-important authentication handshake and carry tokens around the system. The Azure version uses OpenID Connect, a widely used authentication protocol built on OAuth 2.0.  This ensures that the user's user name and password are not seen by the relying application, and that only the relying application can read and trust the token from AAD. Connect your applications As a company, you configure or write your applications to connect to AAD for authentication, and

 Back in the last century, businesses used to have these things called websites... Well ok, we still have them, and many of them are still monolithic. There's a front end - what the user sees - and there's a back end database with a bunch of tables all relating to something the user might experience: Here we've got products, users, transactions (orders), chat, and sign-in credentials. Now in a smarter world, these functions would be broken up and outsourced to specialist software products, and that's what modern authentication does with the sign in credentials.  It's not only safer, it also provides some nice functionality like being able to sign in across multiple different applications (single sign on - SSO). The way this works is that when the user wants to (or is forced to) sign in, they're actually redirected to another website (called an Identity Provider or IdP).  The IdP handles the sign in, and returns a token back to the original application.  Because