Introduction to Federated Identities

Let’s Talk About IAM

Today, I’d like to talk to you about a subject on which I’ve done a lot of work as part of an IAM team.

This team is responsible, as its name suggests, for the IAM of the company. Okay, but what is IAM?
IAM stands for “Identity and Access Management.” It’s a system that securely manages digital identities and user access rights to an organization’s resources. In simpler terms, it’s what lies behind online authentication systems.

A digital identity, in turn, is all the information that allows the recognition and authentication of a person or device on a network, such as a username, a password, or certificates.

There are several types of authentication to secure system access. The main ones are:

Classic Authentication (or password-based)
The user enters an identifier (like a username) and a password to prove their identity. It’s the most common method.
Federated Identity Authentication
It allows a user to access multiple applications or services using a single set of credentials, through a third-party provider. This simplifies the user experience as well as the administrator experience, which we will talk about.
Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA)
It combines several elements to verify a user’s identity, for example, a password (something you know) and a code sent by SMS or generated by an app (something you have). Essentially, it strengthens the security of theoretically being the only one to hold a password by adding proof of possessing a physical object (a smartphone or a hardware security key). This enhances security by adding an extra layer.
Biometric Authentication
It uses unique biological characteristics of the user, such as fingerprints, facial recognition, or voice recognition, to verify their identity.

In summary, the different types of authentication vary in complexity and security level, each method being suited to specific contexts depending on protection needs and ease of access.

You probably gathered from reading the title of this article, but today I’d like to talk to you about the concept of federated identities, which is the basis of the federated identity authentication method.

Why Federated Identity?

Password-Based Authentication

Rather than directly describing what federated identity corresponds to, I would first like to explain how we came to introduce this concept.
To do this, let’s talk about password-based authentication.

This one you know well, you use it every day. Whether for the applications you use in your leisure time (video games, forums, music), or corporate tools if you work in a company.
You have an identifier and a password. If both match, you access your account. Otherwise, you don’t. That’s it.
This method is simple and effective, as long as the password is strong enough.

The advantages are mainly its ease of implementation and its universal compatibility.
But this principle also implies that for each application you have an account on, you have a different identity. It’s still you each time, but each identity is distinct.

While it may seem quite logical to have to create different accounts to play Dofus, listen to music on Spotify, and go on Reddit, wouldn’t it seem illogical to have to create an account for each software you use in your work at a company?

When you join a company, on your first day, you are given an account, and you have access to everything you need with it: your email, your leave and absence management tool, communication platform, intranet portal, etc…

Can you imagine if we had to create an account for each application?
It would look like this:

One identity per application (this is what I wanted to represent by drawing identity cards in different colours).
This would bring about a few drawbacks:

User experience
Do you want to remember 40 pairs of login/password? Neither do I.
Administrator experience
If you do not want to remember so many credentials, you can imagine the nightmare it would be for the administrators who would have to manage each of your accounts.
Attack surface
The more heterogeneous your authentication system in your company is, the larger the attack surface. This also significantly increases vulnerability to the “new enemy” issue: the problem of protecting against former disgruntled employees whose accounts we might have forgotten to deactivate.
Security features
All the security layers you would like to benefit from for your information system would have to be implemented for each authentication system, so for each application.

These drawbacks all have one thing in common: the fact that the same user has an identity for each application they use.
Wouldn’t it be convenient if all these applications delegated their identities, and their IAM in the process, to an entity dedicated to this?

This is precisely the role of what we call an Identity Provider (IdP).

Federated Identities and Identity Provider

An identity provider is a service that manages user authentication and authorization by verifying their identity and allowing them to access digital resources securely.
It acts as the guardian of identities for all the services that delegate their identities to it. It plays a central role in corporate IAMs.

By implementing an identity provider, the user only has to authenticate once, and their identity will be propagated within the applications they wish to access. They will be authenticated for the entire day across all the applications that have delegated their identities.
In the field of federation, these applications are often called Service Providers (SP).

Since the user only needs to authenticate once for multiple applications, we talk about Single Sign-On (SSO). This term is generally used in businesses where applications revolve around the same ecosystem.

To give you a better idea of what this corresponds to, here is what a classic login flow looks like:

Now, here is what a federated identity login flow looks like:

This is an example of SSO in a business where the identity provider is an Active Directory (AD).
But the logic is exactly the same with social logins.
Yes indeed! When you connect to an application, say Spotify, and click on “Continue with Google,” it’s exactly the same principle:

Here, Google plays the role of identity provider, and Spotify is the service provider.
Spotify does have its own IAM if you want to create an account there, but it also offers to delegate your identity to the one you already have with Google.

Here it is! So, how does it work?

Like any communication system, there are protocols dedicated to identity federation. Mainly two: SAML and OIDC.
Although they follow the same principle, they don’t work quite the same and are used in different contexts.

Without going into too much technical detail, I will describe the SAML protocol in more detail to explain the principle of federation before talking about OIDC.

Security Assertion Markup Language (SAML)

SAML protocol in a nutshell

SAML is the most widely used protocol for implementing SSO in businesses, mainly for historical reasons.
Data is written in XML and transmitted according to certain rules.
The most important thing to remember is probably that everything systematically passes through the web browser, which acts as the intermediary in all exchanges.

Via the browser, the user attempts to access a service provider (an application). This application is configured to delegate its identities, so it immediately redirects the authentication request to the identity provider via a SAML Request. The identity provider returns to the user via the browser to ask them to authenticate using their SSO username and password. This is when the user encounters the Active Directory page seen in the previous diagram. This interface is called the login prompt.
Once authenticated via the Identity Provider, it sends a SAML Assertion (contained in a SAML Response). It’s a kind of pass issued to the service provider, saying “I know this user, and they have properly authenticated with me, you can let them through.” The user then accesses the requested service.

What is interesting is that now that the identity provider has accepted the authentication of this user, any SAML Request sent via this user, regardless of which service provider (as long as it refers to the same identity provider), will be automatically accepted. When the identity provider receives the next SAML Request, it will send a SAML Assertion directly without going through the login test pattern, at least as long as the session token is still valid.
It’s important to note that this only works as long as the user’s session is active. If the session expires, the user will have to re-authenticate (companies generally set a lifetime for this session token of around 8 hours).

Note: federated identity authentication in SAML can be IdP-initiated or SP-initiated. In the first case, you connect directly to the IdP to perform SSO. In the second case, this is done from one of the service providers linked to the identity provider. This second case, SP-initiated, is the most common and is shown in this diagram.
The first corporate application the user will have had to connect to during the day is the only one that asked him to perform SSO authentication.

What defines a Service Provider here is its ability to generate and send SAML Requests and to consume the Assertions received via a dedicated endpoint. This endpoint is called the Assertion Consumer Service (ACS).
What defines an Identity Provider here is its ability to consume SAML Requests via a dedicated endpoint called a Sign-In endpoint and to generate and send SAML Assertions.

The trust in SAML

Does anything about this explanation surprise you? When the user wanted to access the service provider, how did it know which identity provider to contact, and vice versa? Moreover, they never communicate directly but always through the browser, so how can they trust each other?

The answer to the first question is very simple: it’s possible to configure an identity provider to specify the service providers it can trust, and vice versa.

Regarding trust, it’s based on the same principle as TLS: via certificates.
The service provider must therefore be aware of the certificate of the identity provider to which it has delegated its identities. Thus, when the identity provider sends an assertion, it will be signed, and the service provider can verify the signature using the public key contained in the certificate it already knew.
An identity provider is required to sign its response, either at the level of the SAML Response or at the level of the SAML Assertion.

On its side, the identity provider can hold the certificates of the service providers with which it communicates, although it’s not mandatory because it’s quite uncommon to sign a SAML Request, unlike assertions.

In summary, the service provider must have the following information about the identity provider:

IdP Issuer: the identifier of the identity provider
IdP Sign-In URL: so that the service provider knows where to send its SAML Requests
IdP certificate: so that the service provider can verify the identity provider’s signature when it receives the assertion

The identity provider must have for each service provider:

SP Issuer: the identifier of the service provider
SP ACS URL: so that the identity provider knows where to send its assertion
SP Certificate: optional, so that the identity provider can verify the signature of the service provider when it receives the SAML Request (if it’s signed)

I explained earlier that it’s possible to configure this information on one side or the other, but it’s interesting to know that a file standard has been established in SAML to avoid having to configure everything manually each time. These are the metadata files, containing the useful information that we want to transmit to the other side before starting the exchanges.

If you want to know more about SAML, I recommend the excellent article Everything you should know about SAML and how to exploit it by Thibz, with whom I worked on this subject.

But as I mentioned, SAML isn’t the only protocol allowing identity federation.
But why? Why did another standard emerge if SAML works so well?
There are several reasons for this, and instead of explaining them directly, let’s take a quick historical look.

Some delegation methods history

SAML History

In 2002, SAML 1.0 was launched. It enabled identity federation by providing a standard for exchanging authentication information across multiple security domains.
In 2005, SAML 2.0 was released. It extended these capabilities by improving interoperability, simplifying the identity federation process, and introducing features like Single Logout (SLO).

Let’s briefly mention the SLO, which allows a single logout across all service providers, but I won’t dwell on it, especially since it’s very rarely implemented by service providers.

The birth of OAuth

At the same time, this was around the period when all sorts of services that gradually became part of our daily lives started to emerge:

Social networks like LinkedIn (2003) or Facebook (2004)
Video sharing platforms like YouTube (2005)
Later:
Music sharing platforms like Spotify (2008)
Live video streaming like Twitch (2011)

And many others, to name just the most well-known.

You might be wondering why I’m talking about all this? Because with the rise of all these services came the need to delegate authorization.
Why? Let’s take a simple example to refresh your memory: Facebook.

When Facebook was launched, to help it grow faster, it wanted each member to connect as quickly as possible with their contacts elsewhere, and if they weren’t on Facebook yet, to suggest they join the social network via email.
In this case, Facebook needed to access the user’s email contacts, like from Gmail, the most widely used service.
Here’s how they did it:

Yes, they actually asked for your Gmail username and password to say, “Don’t worry bro, I’ll check your contacts for you. But I promise, after that, I won’t look at anything else, okay?”
Do you remember? Today, that seems absurd, doesn’t it?

Then came the OAuth 1.0 protocol in 2010.
OAuth works by allowing a user to delegate access to a third-party application to access their resources on another service without sharing their credentials, through the use of secure authorization tokens.
These tokens contain scopes that limit their access, for example, “access contacts and nothing else,” and they have durations that can be time-limited and can be revoked at any time.

As soon as this protocol was released, it was quickly adopted by Facebook, and the web page you saw now looked like this:

Better, right? At least, it definitely inspires a lot more trust.

Okay, but I can already hear some of you saying, “Hey, I’m already reading a long article about identity federation, and now you’re talking about an authorization delegation protocol. That’s nice, but it has nothing to do with it.”
And I understand you perfectly, but actually, it has more to do with it than you think, because this protocol, which was originally not designed to address identity federation needs like SAML, ended up becoming the foundation for the most widely used identity federation protocol today: OIDC.

Have you noticed a crucial point in common between SAML and OAuth? Even though SAML is about identities and OAuth is about permissions, both are about delegating something.

If you’ve noticed this, you’re not alone.

OpenID Connect (OIDC)

How OIDC works

The transition from SAML to OIDC mainly stems from the evolving technological needs and inherent limitations of SAML, including its complexity and reliance on the XML format. SAML, designed in 2005, was widely used for identity federation in enterprise environments, but with the rise of web and mobile applications, there was a need for lighter protocols based on JSON and adapted to REST APIs.

Note: This doesn’t mean it’s impossible to manage permissions in SAML, but just not directly. SAML sends in its assertions a whole mapping of attributes containing one or more roles, which allow the service provider to manage authorizations using RBAC (Role-Based Access Control).

OAuth2, introduced in 2012, addressed this need by providing a framework for delegating authorization, but it lacked a robust authentication layer. OpenID Connect (OIDC), designed in 2014, was built on OAuth2 to provide this authentication layer while retaining the simplicity and flexibility of the OAuth2 model. OIDC also adopted JSON Web Tokens (JWT), which are much lighter than the XML assertions used by SAML, making OIDC more suited to modern environments.

Thus, OIDC emerged to meet the growing demand for a more flexible authentication protocol that’s easier to integrate into modern architectures while building on the foundations of OAuth2.

The transition from XML to JWT is obviously not the only difference between SAML and OIDC, the entire flow has been redesigned. This time, the steps are divided into two flows:

Authorization

It starts just like in SAML: the user tries to access the application. Then, this application sends a nonce and the requested scopes to the identity provider through the browser (via a redirect). The nonce is a random token used to protect against replay attacks by ensuring that the authentication response matches the original request sent by the application.
Then there is the authentication and consent step. The authentication step is similar to what exists in SAML, i.e., a login page, but with an additional step that shows the user the scopes the identity provider will have access to and asks for their consent to these scopes.

There are two standard scopes in OIDC, in addition to others:

The profile scope: represents the right to view user info (name, first name, email, email_verified)
The openid scope: represents the right to receive an identity token as proof of connection

The identity provider then sends an authorization code to the browser, once again through the browser.

Then comes the second step, obtaining the access token.

Obtaining the access token

The bulk of the work has already been done, this step will be extremely simple and brief. The application now has an authorization code and will communicate directly with the identity provider, this time without passing through the browser, to communicate this code and the nonce. The identity provider will then respond with an access token as well as an ID token.
The ID token plays the same role as a SAML assertion, while the access token will manage permissions.
Thus, the application can return the service to the browser.

And that’s how this introduction to identity federation (almost) ends. I hope that this concept, as well as the workings of SAML and OIDC, will be clearer to you by now.

I wanted to tell you about the history of this method, and how useful and well thought-out it is, but I also wanted to conclude with a last section showing its current limitations.

Beyond federation

Points of attention

As practical and innovative as it may be, identity federation, like any method, has its advantages but also its drawbacks. It’s important to consider and mention them.

Single point of failure

First, let’s talk about the case of SSO. While the centralization of data is at the heart of its benefits, it can also represent risks.
Since access to multiple applications is linked to a single identity provider, if that provider experiences service interruptions or the user account is blocked, this can paralyze access to all linked applications.

However, solutions can be implemented, such as redundancy systems, but it’s crucial to be very aware that centralizing identity management in a single system requires special attention to that system, whether in terms of security or high availability.

Data privacy

In my opinion, the issue is even more concerning with social logins. By choosing an identity provider through which you will authenticate across various services, you are placing trust in them. If you use the “Login with Google” button, keep in mind that you are trusting Google.
Whether it’s Google, Facebook, or any other identity provider, always ask yourself: “Am I ready to trust this company to delegate my identity for the service I want to access?”

Personally, I assess it on a case-by-case basis. I find it very convenient for everyday tools, but I wouldn’t use identity federation to access systems that contain highly sensitive data.
So, the right approach is simply to be aware of what you’re doing when you engage in identity federation and ask yourself the right questions to make an informed decision.

Data compromise

Whether in the case of SSO or a social login, if a hacker manages to access the identity provider, they could potentially access all the services linked to it.

I would say that the best practices to prevent this are the same as for any authentication method: activate multi-factor authentication (MFA) where possible and opt for strong passwords,.

Personally, I enable MFA on all services that offer it, and all my passwords are highly complex and managed by a password manager.

Technical limitations

There are currently a number of limitations to identity federation, and I’m going to describe two of them that struck me most during my work on identity federation.

Manage the identity life cycle on the identity provider side

There is currently a challenge of synchronizing identity creation, updates, and deletion between different systems, as identity management is typically centralized with the identity provider. This gap can, for example, be addressed by SCIM (System for Cross-domain Identity Management), a standard protocol designed to automate the exchange of user identity information between identity providers and service providers, simplifying user provisioning and de-provisioning across multiple platforms.

The delegation of authorizations concerns only the IdP (not possible between two SPs)

In current identity federation systems like SAML or OIDC, authorizations are centralized by the Identity Provider (IdP), which delegates access to resources to Service Providers (SPs). It’s not possible for two SPs to directly transfer authorizations between each other without going through the IdP.
This lack of inter-SP delegation can theoretically be addressed by introducing standardized policy management, allowing for unified authorization management across different service providers.

This is typically implemented within the IAM systems of various cloud providers.
Implementing this type of IAM policy within a cloud provider that develops its own products is fairly conceivable since the policies can be integrated directly within the products.
However, doing the same within a cloud provider that does not have access to the source code of the products it has integrated to sell services can prove particularly challenging.

Thank you for reading this article. If you’d like to dive deeper into the topics I covered, you’ll find references in the section below. See you!