Federated authentication and Single Sign-On are the cornerstones of modern authentication. One of the simplest ways to steal credentials is to capture them directly. That’s why secure authentication today focuses on minimizing how often users are asked to enter their credentials.
Reducing the number of logins involves replacing individual application login screens with a centralized login page. When a user accesses an application they haven’t logged into yet, they are redirected to the central login server. If the user has already authenticated there, the server recognizes their session and logs them in without prompting again. Consequently, the user authenticates a single time instead of authenticating separately for each application. This concept is known as Single Sign-On (SSO).
Single Sign-On allows users to authenticate to other applications and domains without having to log in again.
OpenID Connect is an authentication protocol designed to share identity information between applications. It allows identity data to be exchanged not only between OpenID Connect servers and applications, but also between different OpenID Connect servers. This is called federated authentication and it enables cross-domain Single Sign-On.
The most common case of federated authentication and Single Sign-On is authenticating with Social providers (e.g. Google, Microsoft, Facebook, etc.). For example:
Authenticating to a website using a Google account allows the user to use their Google account. If the user is not already logged into Google, they do not provide their credentials to the website (in this case, Spotify). Instead, they enter their credentials directly on Google's login page. Google then prompts the user to authenticate. After successful authentication, Google redirects the user back to the website they were trying to access.
During this process, users are commonly asked for consent, for example: "Do you want to share your email and profile information with website X?" Providing consent allows the website to identify who signed in. An example of such a consent prompt is shown below:
Once consent is given, Google shares the user’s details with the website (Spotify, in this case). This is a typical example of federated authentication.
OAuth enables websites to remain stateless. However, this means that the application’s state, such as whether a user is signed in, must be managed elsewhere: the authorization server. In other words, every authentication server is responsible for managing user sessions in some form or another.
Federated authentication, in essence, is the chaining of multiple authentication servers, meaning that every authentication server the user has used to authenticate federatedly maintains a session with that user.
The process of federated authentication between authentication servers resembles a standard client requesting authorization. As a result, the user performs the full OAuth authorization flow multiple times across different servers.
The user generally does not notice this because most authentication servers delegate these requests transparently. That's why federated authentication typically involves multiple redirects.
Federated authentication does not require downstream authentication servers to be OpenID Connect compatible. Common protocols used to enable federated authentication include:
By setting up a federation with another authentication server, you cannot restrict who can sign in to the federated server and who cannot. Typically, authentication servers that support federated authentication do not allow limiting access to specific accounts from a federated server. In other words, anyone who can authenticate to the federated server can also authenticate to your system.
Federated authentication involves linking multiple authentication servers to handle sign-in. This raises an important question: what happens when a user signs out? Specifically, which user sessions need to be terminated, and how is this managed?
Signing out involves various techniques:
How implement it compliant to the OIDC standard is specified in the OpenID Connect Session Management 1.0 specification.
Written by: Albert Starreveld
IAM Architect / Cloud Architect / Founder @ Entrypage.io
Published on: 25-05-2025