What Are Identity Providers?
Hiya,
Identity providers are a common feature in CIAM systems. Rather than relying on data stored in the local CIAM system, whether that be WebAuthn or passwords, identity providers allow users to authenticate with a remote data store. The authentication event is then passed to the CIAM system, which trusts the results from the identity provider, and creates and/or logs the user in. This process is also called federation.
The relationship between a CIAM system and a remote identity provider is similar to the relationship between an application and a CIAM system. In both cases, the former software system is delegating identity and account access control to the latter. The delegated use cases vary, but can account registration, MFA, and email verification.
Which Identity Providers Should You Integrate
There are a few different types of identity providers; I’ll discuss them more below. Which identity providers make sense to integrate into your CIAM system depends on your needs and those of your customers.
Your customers who are considering using an identity provider to log into your application want to:
login and gain access to your application as quickly as possible.
limit number of accounts they have to manage
trust the login system; uers have more trust in a known identity provider they selected than in a random site or application
As a developer integrating login into your site, you want to:
allow quick, secure access to your application
get the information about a user you need to fulfill your functional and marketing needs; this includes basic profile information and contact information such as a phone number or email address
possibly gain access to data held by a remote identity provider
Consider these topics when thinking about identity providers to integrate:
will logging in with this make my customer’s lives easier?
can I get the data I need?
With most CIAM systems integration will be either configuration, a feature request of the vendor, or impossible. With some open source solutions you can contribute an integration.
If the identity provider conforms to a specification such as SAMLv2 or OIDC, you may be able to use a generic integration instead of one build specifically for the remote data store.
Access To Data
I mentioned above that identity providers are primarily used to delegate authentication. For certain identity providers and use cases, you may also receive a credential. This is usually an access token and is used to access data held by the organization that manages that identity provider via an API. This credential is tied to the user who delegates access.
An example is Google Calendar. By authenticating a user using Google as well as asking for the correct permission (the https://www.googleapis.com/auth/calendar scope to be precise) an application can receive a Google access token.
The application can then present this token to the Google Calendar API and retrieve, update or add events to a user’s Google Calendar. Here’s the full list of Google services to which you can request access.
Whether or not an authentication using an identity provider offers you access to a suite of associated APIs depends on the organization behind the identity provider. Consult their documentation as needed.
Types Of Identity Providers
There are a few different types of identity providers.
Social identity providers, such as Google, WeChat, Line, and Facebook. These are good for general consumers and apps targeting them. What is common in one country might be rare in another, so when picking a social identity provider, make sure you investigate what is common in your target geography.
Enterprise identity providers, such as Microsoft Azure AD, Okta, or OneLogin. These are IAM systems that manage employee identity. If you are building a B2B or B2B2E application, support for these can make it easier to onboard your customers.
Government identity providers, like login.gov for the USA, Aadhaar for India or BankID in Sweden. These are government run systems tied to a specific country and are a great fit if you are building an app to be used by a national government or if you need to be assured of citizenship status.
Industry specific identity providers, like Xbox and Steam for gaming, Doximity and Medikey for health care, or university logins for higher education. If you are building an application targeting a specific industry, look for an identity provider serving that industry.
Ecommerce focused identity providers, like Amazon and Paypal. If you are building tools for users who might have such accounts, these are good choices.
Decentralized identity providers, like Sovrin and uPort. These allow for self-sovereign identity, which is a whole other kettle of identity fish.
Choose an identity provider or set of providers that are familiar to your customers, will signal you understand them, and can ease their onboarding process. Choosing the correct identity provider is not as critical as building features your customers want, but once you have thse, offering additional login options can decrease signup friction.
Becoming The Industry Identity Store
If you are building an application for an industry, you look around for an identity provider to ease your user onboarding and you don’t see one, consider becoming the industry identity store.
This is a right turn from building your application business. Consider the business model carefully. When you open up your user data, you extend your reach into the particular industry, but you also allow possible competitors to leverage your userbase. Are there even competitors or complementary applications that might need access to your customer base?
But if done right, becoming the source of identity for an industry can cement your place in the ecosystem and make it very hard to displace you. Plus, you’ll get a brand halo effect if other applications in your industry offer ‘login with ABC’ buttons.
To pursue this, split out your CIAM system. Allow third party applications to build on top of it to get access to your user profile data. You’ll deliver this data after the third party application delegates authentication to your system and the user logs in.
You may want to offer only login. If you have valuable user data that you want to share, you could offer up APIs that applications could use as well.
Depending on the number and value of your users, you might be able to charge for access to login functionality or data.
A solid CIAM system should enable building this type of platform.
Conclusion
Identity providers integrate into your application to ease access to your application as well as offer up additional useful data.
While you can certainly use CIAM without identity providers, the ability to federate to a remote data store is a key part of modern identity. It makes it easier for users to securely get into your application and access the functionality and data they want.
That is, after all, the point of any CIAM system.
Dan