(Technically, this is a blogpost about Oauth2 and not OpenID Connect)

Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy?

For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere. Access to private channels is often well managed as you don’t want random people in your limited conversations.

For many organizations, especially small ones, Slack may be the best option for authenticating your users on other applications. Unlike Google or other social identity providers, you can control who is a member of your Slack team, you can audit and confirm their profile information and you can restrict which channels they can access. The channel membership is a nice fit for application privileges, so you can say things like “this application can only be used by Slack users on the private channel #admin”

Slack implements Oauth2, which is a subset of OpenID Connect. This means that once you have the user’s access token, you have to make a Slack specific API call to get the user profile and other information, like their list of channels. So there is slightly more custom integration code than for full OpenID Connect providers.

For organization that already have a well established Slack team and no other identity manager in use (such as Active Directory), Slack may be your best source of trust for other applications. You can integrate with it using the standard Oauth2 protocol.

You can start your journey at my Boosterconf workshop in Bergen March 14th. https://2019.boosterconf.no/

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.

In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

Norway’s national Identity Provider

The advantages of using ID porten as an identity provider are considerable, but it comes with limitations as well. ID-porten is the identify provider supplied by the Norwegian government to all residents of Norway. It is (almost) fully compliant with OpenID Connect and is compatible with most tools and libraries.

When your user is authenticated with ID-porten, your application receives their national identification number (fødselsnummer eller d-nummer). This identity is generally safeguarded by two factor authentication and the user has been validated by personally showing their identification papers in a bank or police office. You can be very certain of the user’s identify.

The limitation is that even though you know the user’s identification number, you know very little about the user. You have to be authorized to use the national population register and do the lookup yourself to get their name and address. And even then, you don’t know what organizations the user is associated with and what authorization they have there. (This limitation is natural, considering the scope of responsibility of ID-porten)

So the dilemma is that you can be quite sure of who the user is, but you have no idea who they user is. 😂

(Some of this information is available in other national registers and as time goes by, it may be more accessible)

Furthermore, even though you know who your user is, you don’t know if you can trust them or if they are a crook. Most convinced criminals of course retain their right to use online banking and naturally they have ID-porten access. And that’s the way I think we should treat people, even those who have messed up in their lives.

Getting started with ID-porten is a bit harder than for other OpenID Connect providers, but this is mostly administration. First, not all applications are authorized to use it, of course, so you must contact Difi to get access. Secondly, ID-porten is very limited in terms for self service of application administration, so getting client credentials also involved soon emailing.

But once you have your application credentials, integrating with ID-porten is just as simple as any other OpenID Connect provider. As a matter of fact, I’ve made apps that work with Google accounts and re-targeted them to ID-porten with only changes to credentials.

Difi’s OpenID implementation is impressively accurate and robust, but there are still some issues you may run into in mobile app scenarios. (In technical parlance, response_mode=fragment doesn’t support response_type=code without a client secret, which is the easiest secure option for apps)

If you are providing services to Norwegians on behalf of local or state government, ID-porten is your mandatory identity provider. And you can use existing knowledge and tools for OpenID Connect to do so.

You can start your journey at my Javabin talk in Oslo this Wednesday. https://www.meetup.com/javaBin/events/258573600/

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.