Single sign-on

As explained in Building Distributed Applications that Work

Single sign-on is an authentication mechanism that lets a user access multiple applications after authenticating once.

Single sign-on (SSO) lets a user access multiple applications after authenticating once. A shared identity provider (IdP) manages the login and lets protected applications verify that the user is authenticated. For example, a user signed in to a Google account can use Sign in with Google on participating websites. section 8.1

A typical sign-in flow works like this:

• A user requests a protected page. Finding no login information, the application redirects the user to the IdP’s login page. section 8.1
• After the user authenticates, the IdP redirects them back. A token sent with the redirect confirms authentication and can be kept in temporary storage, such as a browser cookie. section 8.1
• The token can authenticate the user with other applications protected by the same IdP. It eventually expires, though continued use can refresh it. section 8.1

Authentication establishes who a user is; authorization determines whether they may access a resource. OpenID Connect (OIDC) is commonly used for authentication, while OAuth can provide authorization alongside it. In an Aspire-hosted application, an internally hosted IdP can be reached through service discovery, and an authenticated UI can pass credentials and permission information to a backend API via a JWT. section 8.1 section 8.6

Figure 8.1 SSO flow

Follow the redirect from a protected application to the IdP and back to see where the shared sign-in takes effect. section 8.1

How Building Distributed Applications that Work covers it

How deep it goes

Walks through redirects, token storage, reuse, and expiry at a simplified flow level rather than protocol internals.

Examples

Illustrates shared login with a Google account and a protected-page redirect flow.

What it assumes

Introduces the redirect-and-token process from a simplified starting point without requiring protocol internals.

What you can do after

Evaluate/understand how one IdP login grants access across protected applications and when a user must authenticate again.

How it connects

Connects SSO to identity providers, authentication, authorization, OpenID Connect, OAuth, and JWTs.

liveBookmanning.com

Read Building Distributed Applications that Work on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Software Security for DevelopersA single sign-on service centralizes user authentication and enables authenticated users to access multiple applications without separately authenticating to each one.
• 

  liveBookmanning.com
  Real-World CryptographySingle sign-on is an authentication scheme that lets a user access multiple services by authenticating through one account provider.

Compare how 3 books explain single sign-on →

Related concepts

• identity provideruses · An identity provider is a system that authenticates users or other entities and supplies identity information or authentication assertions to relying applications and services.
• openid connectuses · OpenID Connect is an identity layer built on OAuth 2.0 that enables clients to authenticate end users and obtain standardized identity claims.
• Security Assertion Markup Languageuses · Security Assertion Markup Language is an XML-based standard for exchanging authentication, identity, and authorization assertions between identity providers and service providers.
• OAuthuses · OAuth is an authorization framework that enables a client to obtain limited, delegated access to protected resources without receiving the resource owner's credentials.
• Terraformused by · Terraform is an open-source infrastructure-as-code tool for defining, provisioning, and managing infrastructure resources through declarative configuration.
• Keycloakused by · Keycloak is an open-source identity and access management platform that provides authentication, authorization, and single sign-on, including support for identity standards and federation.

This explainer was generated by Manning's knowledge graph from the text of Building Distributed Applications that Work. The section links point to the parts of the book it draws on.