We are inundated with new apps and web services every day – all aimed at making our lives easier or better in some way. Now think of this: when is the last time you installed an app that doesn’t require registration/login? Very rare nowadays.
The experience of registering your user account in a new service can be quick and smooth – or it can be long and painful. Can you choose to assert your identity with fingerprint authentication (already facilitated by modem smartphones) or are you forced to create yet another username and password?
As a developer of front-end or back-end systems, you will inevitably encounter Identity and Access Management (IAM) at some point. To be more precise, you will likely deal with Customer Identity and Access Management (CIAM), which is specifically tailored to external users rather than internal employees.
For example, you might need to:
- design a new user registration workflow;
- configure authentication methods (such as social login or a mobile authenticator);
- enable Multi-Factor Authentication (MFA);
- connect your service to a partner’s application via OAuth 2.0;
- or secure the API of your web service.
Is this starting to sound complex? Don’t worry, most likely your company will buy CIAM APIs from identity specialists rather than reinvent the wheel in-house (see this Build vs Buy white paper to find out which approach is best for your organisation).
However, understanding the basics will put you in a good position to communicate what you need and why when it comes to CIAM.
Below is what you, as a developer, can gain by learning CIAM:
1. How to build great user registration experiences
A visitor comes to try out your web service. That first touch point can be a customer experience delight, or it can be a painful friction. Lousy registration workflows welcome a new user with confusing instructions, too many steps, too much data to fill in, absence of their native language, and a sense of the service not being secure. The result: the user abandons your site.
Here’s an example of a bad registration workflow:
Here’s an example of a good registration workflow:
2. Assess what the best authentication methods are for your service
If customers request “I want to login with my fingerprint,” and then someone in your organisation says “No, login with Google is more important”, but you were actually thinking of one-time SMS passwords, how do you assess among all available authentication methods which is the best for a particular service? There is no single answer.
There are authentication methods based on mobile, based on a physical token such as an ID card, biometrics, digital certificates, bank identification, and the list continues. Everybody talks about the end of passwords, but nobody can tell you with certainty what the solution is that will fully replace passwords.
This is why a developer should learn the pros and cons of a wide range of authentication methods and be aware of the emerging standards. Then you won’t get confused when you hear FIDO, 2FA, CIBA, TOTP, Mobile PKI, and other terminology.
3. How to connect any application or web service to an external identity provider
Today, most companies use a large number of services and applications. Some were built in-house (e.g. an old payroll system), others are based on installing a known package (e.g. Drupal), and others are a subscription to SaaS (e.g. Office365).
To make things easy for users, Single Sign-On (SSO) is a necessity. In order to accomplish this, the authorisation server (identity provider in SAML terminology) must connect to each of these applications. As you can imagine, each could have a different way to integrate. The oldest systems will likely use SAML or Shibboleth, which are based on XML. The newest services will use OpenID Connect, which is based on JSON. And there will be exceptions to the rule in which there is no immediate way to connect the applications. In these cases, a developer has to create some kind of connection adapter based on one of the aforementioned open standards. A solid understanding on the difference between SAML, OAuth 2.0 and OpenID Connect is crucial. We run through the differences between these protocols in our popular white paper, SAML vs OAuth 2.0 vs OpenID Connect.
4. Multi-tier identity delegation
For a long time, in most of the services you interact with, your user account was uni-personal. Think of your bank account, a podcast app, your online storage, a subscription to audioooks, a taxi booking app, etc. However, people have different expectations today and this is why now you can see music streaming and video streaming services which offer ‘family’ subscriptions.
You can replicate this model in other areas of life: think of an amusement park determined to bring 90% of their users to use its app. A child will access the app, but naturally without the full access as mum or dad, such as being able to buy services, delete the account or access to adult content. Simple as it sounds, doing delegation in a secure way requires a system with proven large-scale deployment.
Multi-tier delegation has countless possibilities beyond families: clubs, associations of house owners, team members filling in a start-up funding application, electronic power of attorney, etc.
5. How to protect an API
Popular services like Twitter allow many apps to access their APIs for different reasons: discover hashtags trends, schedule posts on behalf of a user, embed a tweet in a blog, etc. Similarly, your company has an API that a large number of users will be accessing, not through your company’s services but through a dozen third-party applications.
As a developer, you have probably already heard that API keys are not secure enough, but OAuth 2.0 sounds confusing and prone to misconfiguration. Indeed, it is easy to configure OAuth 2.0 the wrong way and make your service even less secure than what it was. Proven CIAM systems offer ‘golden paths’ and best practices to use OAuth 2.0 to protect an API. We talk about securing an API with OAuth 2.0 in another free white paper.
6. Comply with data protection regulations: data minimisation via authorisation policies
Regulations such as GDPR have many principles, and one of them is data minimisation. Beyond what personal data organisations should or should not store, the same applies to the data that one service transmits to another. An example follows:
A frequent traveller who already trusts in an airline, let’s say Trust Air, visits a car rental company’s website, Green Wheels, and notices that to make a booking he can log in with his Trust Air account. Nice and easy! Right after the authentication, the user will see a consent page that explains which personal data will be transmitted to Green Wheels. The less data Trust Air transmits to Green Wheels the better.
This is why learning authorisation policies, attribute release and the key concepts behind attribute-based access control (ABAC) are imperative for compliance today.
7. The newest trends in the field
CIAM is enriched by the newest advancements in digital identity, cybersecurity, payments industry as well as from design and laws. FIDO, Mobile Connect, CIBA, FAPI, LEI and Right to Represent are some of the names that will be ubiquitous when we talk about web services and applications in the decade ahead.