OpenID Connect 1: Microsoft Azure Active Directory
The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten.
Different Identity providers can support different levels of trust between you and your users.
The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master. As a developer, you owe yourself and your users to play with OpenID Connect before you ever implement a username+password.
You can start your journey into OpenID Connect at my JavaBin presentation this Wednesday, or my workshop at Boosterconf in Bergen.
In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.
Why Microsoft Azure Active Directory can enable cross-organization cooperation
The main advantage of using Microsoft’s Active Directory as an OpenID Connect provider is that you can validate your users’ association with specific organizations, whether it’s your own organization or one of your customers or suppliers.
While an identity provider like Google accounts or Facebook will supply the name of the user, this information is not at all validated. Just because a Google user is registered with the name “Johannes Brodwall”, there is no way of knowing if this is truly their name. But if you get the same name from Sopra Steria’s active directory, you can be a lot more confident.
Similarly, end user Identity providers like Google and Facebook can validate that a user had an @soprasteria.com address at some point in time. But when the same claim comes from active directory, you know that this email address was still active at the time of the authentication. Again a much more powerful claim. Your trust is limited to your knowledge of the users organization, of course. The first time a user arrives from an unknown organization (“tenant” in active directory terminology) you basically know nothing about the organization and the user. Anyone can register an active directory with email addresses that resemble a legitimate organization. A common misconception is that an administrator of the user’s organization must be involved in order to integrate with an active directory. This is not the case. Anyone can make an application registration that can authenticate users from any active directory. (This used to be called “multi tenant applications”, but Microsoft seems to be smoothing out a lot of the difference between multi tenant and single tenant apps now). But the user will be asked if they consent to your app getting their name, email etc. The full power of active directory can be unleashed for organizations where the administrator gets involved. If you make an app that e.g. Sopra Steria wants to use officially, an administrator at Sopra Steria can authorize your app to get user details without explicit individual consent and can also authorize your app to receive information about users’ roles and groups. And the administrator can require their users to use Multi-factor authentication for your app and even audit user logins from their organization to your app. This means that your active directory application will have to deal with both unknown organizations, known organizations with default configuration and organization where an administrator at the organization have set up your app. Active Directory gives considerable power out of the box and if you’re willing to deal with the complexity, you can get even more. And all it requires from the developer is to integrate with the fully standard compliant OpenID Connect protocol. This is as easy for Java developers as for .NET developers. Stay tuned for my upcoming articles about ID-porten and Slack as ID-providers.