Tutorial 3.14: Federated Identity and Single Sign-On

Learning Objectives
Overview
1. Introduction to Federated Identity
2. Single Sign-On (SSO) Concepts
3. Trust Relationships and Federation Models
4. Federation Protocols: SAML, OAuth, OIDC
5. SAML 2.0 Architecture and Flows
6. OAuth 2.0 Authorization Framework
7. OpenID Connect (OIDC)
8. Comparison and Selection
9. Security Considerations
10. Case Studies
11. Summary and Transition
Quiz
Exercises
Homework
Summary

Learning Objectives

After completing this tutorial, you should be able to:

Define federated identity and explain its benefits for inter-organizational access.
Describe the core components of SSO: Identity Provider (IdP), Service Provider (SP), and trust relationships.
Explain the trust models in federation, including direct trust and brokered trust.
Compare the three main federation protocols: SAML 2.0, OAuth 2.0, and OpenID Connect.
Analyze the SAML 2.0 flow, including assertions, bindings, and profiles.
Evaluate OAuth 2.0 grant types and their use cases.
Assess the security properties and token handling in OpenID Connect.
Design a federation solution for a given scenario, choosing appropriate protocols.
Identify common security threats in federation and propose countermeasures.

Overview

In modern digital ecosystems, users often need to access resources across multiple organizations—partners, suppliers, customers, and cloud services. Managing separate credentials for each domain is inefficient, insecure, and user-unfriendly. Federated identity addresses these challenges by enabling users from one organization (the identity provider) to authenticate and access resources in another organization (the service provider) using a single set of credentials. This is the foundation of Single Sign-On (SSO), which provides a seamless user experience while reducing password fatigue and administrative overhead.

This tutorial provides a comprehensive exploration of federated identity and SSO. We begin by defining the core concepts: Identity Provider (IdP), Service Provider (SP), and the trust relationships that underpin federation. We discuss the different federation models: direct trust (point-to-point) and brokered trust (via a federation hub). We then examine the three dominant protocols: SAML 2.0 (Security Assertion Markup Language), OAuth 2.0 (an authorization framework), and OpenID Connect (OIDC) (an identity layer on top of OAuth 2.0).

We dive deep into SAML 2.0, covering its architecture, assertions, bindings, and profiles, and walk through the Web Browser SSO profile. We then analyze OAuth 2.0, explaining its roles, grant types, and token usage, and how it enables delegated access. We then explore OIDC, which extends OAuth 2.0 with an ID token and standardized claims, making it suitable for authentication. We compare the protocols, providing guidance on when to use each.

Security is a critical aspect of federation. We discuss threats such as assertion tampering, token theft, and session hijacking, and describe countermeasures like signing, encryption, and audience restriction. The tutorial concludes with case studies: enterprise SSO using SAML and OIDC, social login with OIDC, and academic federations like InCommon. By the end, you will have a thorough understanding of federated identity and SSO, enabling you to design and implement solutions that provide secure, seamless access across organizational boundaries.

1. Introduction to Federated Identity

1.1 What is Federated Identity?

Federated identity is a system that allows a user to use a single digital identity to access resources across multiple domains or organizations. It is based on trust relationships between participating entities. The user's identity is managed by an Identity Provider (IdP), which authenticates the user and provides assertions about the user's identity to Service Providers (SPs) that rely on those assertions to grant access.

Federation eliminates the need for users to maintain separate credentials for each service, reducing password fatigue and the risk of credential reuse. It also simplifies administration for SPs, as they can outsource authentication to trusted IdPs.

1.2 Key Benefits

Improved User Experience: Users sign in once and access multiple services without re-entering credentials (SSO).
Reduced Administrative Overhead: SPs do not need to manage user accounts and passwords; they rely on the IdP.
Enhanced Security: Stronger authentication policies (e.g., MFA) can be enforced at the IdP for all services.
Scalability: Organizations can easily onboard new partners and services by establishing trust.
Compliance: Centralized auditing and consent management at the IdP.

1.3 Core Roles

Identity Provider (IdP): The entity that authenticates users and issues identity assertions. Examples: Azure AD, Okta, Google Identity.
Service Provider (SP): The entity that provides a service and relies on the IdP's assertions to grant access. Examples: Salesforce, Office 365, custom applications.
User (Subject): The principal who wants to access a service.
Federation Hub/Broker: An intermediary that facilitates trust between multiple IdPs and SPs, often used in large federations (e.g., InCommon).

Key Takeaway: Federated identity allows users to use a single identity across multiple organizations, improving user experience, security, and administrative efficiency.

2. Single Sign-On (SSO) Concepts

2.1 What is SSO?

Single Sign-On (SSO) is a property of an authentication system that allows a user to log in once and gain access to multiple applications without being prompted to log in again. SSO is a key benefit of federated identity. It can be implemented within a single organization (enterprise SSO) or across organizations (federated SSO).

2.2 How SSO Works

In a typical federated SSO scenario, the user attempts to access an SP. The SP redirects the user to the IdP for authentication. The IdP authenticates the user (if not already authenticated) and returns an assertion to the SP. The SP validates the assertion and grants access. Subsequent access attempts to other SPs that trust the same IdP do not require re-authentication, as the user already has a session at the IdP.

2.3 SSO in Practice

SSO is implemented using federation protocols like SAML, OIDC, or proprietary mechanisms. The IdP maintains a session for the user, often using a cookie or a browser token. When a user accesses a new SP, the IdP checks if the user has an active session and, if so, issues a new assertion without prompting for credentials.

2.4 Enterprise SSO vs. Federated SSO

Enterprise SSO: Within a single organization, using a central directory (e.g., Active Directory) and a single IdP. Often integrated with Kerberos or LDAP.
Federated SSO: Across organizations, where each organization has its own IdP, and trust is established between them.

Important: SSO is not a protocol but a capability. It is achieved through protocols like SAML, OIDC, or CAS (Central Authentication Service).

3. Trust Relationships and Federation Models

3.1 Trust Basics

In federation, trust is established between the IdP and SP. Trust means that the SP accepts the IdP's assertions as valid proof of identity. Trust is typically established through:

Digital signatures: The IdP signs assertions with its private key; the SP verifies the signature using the IdP's public key.
Metadata exchange: IdP and SP exchange metadata (certificates, endpoints) to establish trust.
Out-of-band agreement: Legal and operational agreements between organizations.

3.2 Federation Models

Direct Trust (Point-to-Point): IdP and SP have a direct trust relationship. Each SP must establish trust with every IdP it accepts. This model does not scale well.
Brokered Trust: A federation hub or broker is used to manage trust. IdPs and SPs trust the broker, and the broker facilitates trust between them. Examples: InCommon (academic), eduGAIN (global).
Cross-Certification: IdPs and SPs have certificates signed by a common Certificate Authority (CA).

3.3 Federation Agreements

Organizations typically sign a Federation Agreement that defines the terms of participation, including data protection, privacy, liability, and operational procedures.

Key Takeaway: Trust is the foundation of federation. It can be established directly or through a broker, and is formalized via metadata exchange and legal agreements.

4. Federation Protocols: SAML, OAuth, OIDC

4.1 Overview

Three protocols dominate the federated identity landscape:

SAML 2.0: Security Assertion Markup Language, an XML-based standard for exchanging authentication and authorization data. Mature, widely used in enterprise SSO.
OAuth 2.0: An authorization framework that allows third-party applications to obtain limited access to a user's resources. Not designed for authentication, but often used with OpenID Connect.
OpenID Connect (OIDC): An identity layer built on OAuth 2.0 that adds authentication and user claims. Designed for modern web and mobile applications.

4.2 Protocol Comparison

Aspect	SAML 2.0	OAuth 2.0	OpenID Connect (OIDC)
Primary Purpose	Authentication and authorization (SSO)	Authorization (delegated access)	Authentication (identity layer on OAuth)
Data Format	XML (SAML assertions)	JSON (tokens: access token, refresh token)	JSON (ID token, claims)
Typical Use	Enterprise SSO, web applications	API access, mobile apps, third-party login	Consumer SSO, mobile, modern web
Bindings	HTTP Redirect, POST, SOAP	HTTP (REST) with bearer tokens	HTTP (REST) with bearer tokens
User Info	In assertion (attributes)	Via User Info endpoint (OAuth)	In ID token and User Info endpoint
Complexity	Complex (XML, heavy)	Moderate	Moderate (simpler than SAML)

Note: OAuth 2.0 is an authorization framework, not an authentication protocol. OIDC adds authentication capabilities on top of OAuth 2.0.

5. SAML 2.0 Architecture and Flows

5.1 SAML Components

Assertion: A XML document containing authentication and attribute information. It includes:
- Authentication statement: When and how the user was authenticated.
- Attribute statement: User attributes (e.g., email, group).
- Authorization decision statement: Permissions (rarely used).
Protocol: Defines the request/response messages (e.g., AuthnRequest, Response).
Binding: How SAML messages are transported (e.g., HTTP Redirect, HTTP POST, SOAP).
Profile: A combination of protocol and bindings for a specific use case (e.g., Web Browser SSO, Single Logout).

5.2 Web Browser SSO Profile

The most common SAML use case. It involves a user accessing an SP via a browser. The flow is:

User attempts to access a protected resource at the SP.
SP generates an AuthnRequest and sends it to the IdP via a redirect (or POST) binding.
IdP authenticates the user (if not already authenticated) and generates an assertion.
IdP sends the assertion to the SP via HTTP POST (or artifact binding).
SP validates the assertion, creates a session for the user, and grants access.

5.3 SAML Assertion Structure (Simplified)

        <saml:Assertion ...>
          <saml:Issuer>https://idp.example.com</saml:Issuer>
          <saml:Subject>
            <saml:NameID>user@example.com</saml:NameID>
          </saml:Subject>
          <saml:AuthnStatement AuthnInstant="...">
            <saml:AuthnContext>
              <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
            </saml:AuthnContext>
          </saml:AuthnStatement>
          <saml:AttributeStatement>
            <saml:Attribute Name="email"><saml:AttributeValue>user@example.com</saml:AttributeValue></saml:Attribute>
          </saml:AttributeStatement>
        </saml:Assertion>
    

5.4 SAML Security

Signing: Assertions are signed by the IdP to prevent tampering.
Encryption: Assertions can be encrypted for confidentiality.
Audience restriction: Assertions include the intended SP's entity ID to prevent replay to other SPs.
NotBefore/NotOnOrAfter: Time validity window for the assertion.

Key Takeaway: SAML 2.0 is a mature, XML-based protocol for enterprise SSO. It provides strong security features but is more complex than OIDC.

6. OAuth 2.0 Authorization Framework

6.1 OAuth 2.0 Overview

OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to a user's resources (e.g., files, contacts) without exposing the user's credentials. It defines four roles:

Resource Owner: The user who owns the data.
Resource Server: The server hosting the user's resources.
Authorization Server: The server that issues access tokens after authenticating the resource owner.
Client: The application requesting access.

6.2 Grant Types

OAuth 2.0 defines several grant flows (authorization grant types):

Authorization Code: The most common, used for server-side web applications. The user authorizes the client, which receives an authorization code that it exchanges for an access token.
Implicit: For single-page applications (SPAs) where the client cannot keep secrets. The access token is returned directly in the redirect URI. (Deprecated in OAuth 2.1.)
Resource Owner Password Credentials: The client uses the user's username and password to obtain a token. Used for legacy or trusted applications. (Deprecated in OAuth 2.1.)
Client Credentials: The client authenticates itself (not on behalf of a user) to obtain a token for its own resources.
Refresh Token: Used to obtain a new access token after the current one expires, without user interaction.

6.3 Token Types

Access Token: A bearer token that grants access to protected resources. It has a limited lifetime.
Refresh Token: Used to obtain a new access token; has a longer lifetime and can be revoked.

6.4 OAuth 2.0 Security Considerations

Bearer tokens: Any party with the token can use it; tokens must be transmitted over HTTPS.
Client secret confidentiality: For confidential clients, the secret must be protected.
Redirect URI validation: Prevents authorization code interception.
State parameter: Protects against CSRF attacks.

Note: OAuth 2.0 is an authorization framework, not an authentication protocol. It does not provide user identity information beyond the token. That is the role of OpenID Connect.

7. OpenID Connect (OIDC)

7.1 What is OIDC?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds authentication and provides user identity information in a standardized way. OIDC is widely used for consumer SSO (e.g., "Login with Google") and modern enterprise applications.

7.2 OIDC Roles

OpenID Provider (OP): An OAuth 2.0 Authorization Server that also issues ID tokens. (Equivalent to IdP).
Relying Party (RP): The client application that relies on the OIDC provider for authentication. (Equivalent to SP).

7.3 OIDC Tokens

ID Token: A JSON Web Token (JWT) that contains claims about the user's identity (e.g., sub, email, name). It is signed and optionally encrypted.
Access Token: As in OAuth 2.0, used to access protected resources.
Refresh Token: Optional, used to obtain new tokens.

7.4 OIDC Flows

OIDC uses the same OAuth 2.0 grant types, with the addition of the ID token. The most common flows are:

Authorization Code Flow: The RP obtains an authorization code, exchanges it for an ID token and access token. Suitable for web apps.
Implicit Flow: ID token and access token are returned directly in the redirect. Used for SPAs (now deprecated in OAuth 2.1).
Hybrid Flow: Combines aspects of both, allowing some tokens to be returned immediately.

7.5 OIDC Claims

Claims are pieces of information about the user. Standard claims include:

sub: Subject identifier (unique to the user).
email: User's email.
name: Full name.
given_name, family_name.
iat, exp: Issued at and expiration times.

Additional claims can be requested using the scope parameter (e.g., profile, email, address, phone).

7.6 OIDC Security

JWT signing: ID tokens are signed with a key, allowing the RP to verify authenticity.
Audience restriction: The aud claim in the ID token must match the RP's client ID.
Nonce: Used to prevent replay attacks.
Token expiration: ID tokens have a short lifetime.

Key Takeaway: OIDC is a modern, lightweight identity protocol based on OAuth 2.0. It provides authentication, user claims, and is widely adopted for web and mobile applications.

8. Comparison and Selection

8.1 When to Use Each Protocol

SAML 2.0: Use in enterprise environments with a need for strong, standardized SSO. Often used with on-premises applications and legacy systems. Requires XML toolkits.
OAuth 2.0: Use when you need delegated authorization for APIs, mobile apps, or third-party access to resources. Not suitable for authentication alone.
OpenID Connect: Use for modern web and mobile applications that need authentication and user claims. Simpler than SAML, JSON-based, and widely supported.

8.2 Hybrid Scenarios

Many organizations use a mix: SAML for enterprise SSO with legacy apps, and OIDC for mobile and cloud-native applications. Federation bridges (e.g., Azure AD, PingFederate) can translate between protocols.

8.3 Summary Table

Protocol	Best For	Complexity	Support
SAML 2.0	Enterprise SSO, web apps	High	Wide (legacy & modern)
OAuth 2.0	API authorization	Moderate	Very wide
OpenID Connect	Consumer and enterprise SSO, mobile	Moderate	Rapidly growing

9. Security Considerations

9.1 Common Threats

Assertion Tampering: Attacker modifies a SAML assertion. Countermeasure: signing.
Token Theft: Attacker steals an OAuth access token or ID token. Countermeasures: HTTPS, short lifetimes, token binding.
Session Hijacking: Attacker steals the user's session at the IdP. Countermeasures: MFA, session timeout.
Redirect URI Manipulation: Attacker uses a malicious redirect URI to intercept authorization code. Countermeasures: strict redirect URI validation.
Phishing: Attacker tricks user into entering credentials into a fake login page. Countermeasure: use of trusted IdP and user education.

9.2 Best Practices

Use HTTPS exclusively for all federation communication.
Sign and optionally encrypt assertions/tokens.
Implement short token lifetimes and use refresh tokens securely.
Validate all tokens (signature, audience, issuer, expiration).
Use the state parameter (OAuth/OIDC) or RelayState (SAML) to prevent CSRF.
Implement MFA at the IdP for all federated users.
Regularly audit federation metadata and trust relationships.
Monitor for suspicious activity (e.g., many authentication requests from unusual locations).

Warning: Federation introduces additional attack surface. Security must be carefully designed and monitored to prevent trust exploitation.

10. Case Studies

10.1 Case Study: Enterprise SSO with SAML and OIDC

Background: A large enterprise with 10,000 employees uses a central identity provider (Azure AD). The organization has a mix of legacy on-premises applications (SAP, SharePoint) and modern cloud applications (Salesforce, Office 365, Workday).

Solution:

Azure AD serves as the IdP.
Legacy applications use SAML 2.0 for SSO (via Azure AD Application Proxy or ADFS).
Modern applications use OIDC for authentication.
Azure AD Connect synchronizes on-premises Active Directory to Azure AD.
MFA is enforced for all users.
Conditional Access policies enforce additional checks (e.g., location, device compliance).

Outcome: Users enjoy seamless SSO across all applications. Security is enhanced with MFA and conditional access. Administrative overhead is reduced.

10.2 Case Study: Academic Federation (InCommon)

Background: InCommon is the U.S. academic federation, with over 600 institutions. It uses SAML 2.0 to enable SSO for students and researchers across member institutions.

How it works:

Each member institution operates its own IdP.
InCommon provides a trust framework and metadata exchange.
Service providers (e.g., journal databases, research tools) register with InCommon.
Users authenticate at their home institution's IdP and access SPs without creating new accounts.
Attributes (e.g., affiliation, email) are released according to policies.

Benefits: Researchers can access a wide range of resources using their campus credentials. SPs simplify user management by outsourcing authentication.

10.3 Case Study: Social Login with OIDC

Background: A consumer-facing website wants to allow users to sign in with their Google or Facebook accounts. This reduces friction and increases conversion rates.

Solution:

The website acts as a Relying Party (RP) using OIDC.
Google and Facebook are OpenID Providers.
The website redirects users to the chosen IdP, which returns an ID token.
The website validates the token and creates a local session.
User attributes (email, name) are obtained from the ID token or User Info endpoint.

Outcome: Users can sign in quickly without creating new passwords. The website collects essential user information while delegating authentication.

11. Summary and Transition

This tutorial provided a comprehensive exploration of federated identity and single sign-on. We defined federated identity as a system that allows users to use a single identity across multiple organizations, and SSO as the seamless authentication experience it enables. We discussed the core roles—Identity Provider (IdP), Service Provider (SP)—and the trust relationships that underpin federation, including direct and brokered trust models.

We then examined the three main protocols: SAML 2.0 (mature, XML-based, enterprise SSO), OAuth 2.0 (authorization framework for delegated access), and OpenID Connect (identity layer on OAuth 2.0). We analyzed each protocol's architecture, flows, and security features, and provided guidance on when to use each. We also covered security considerations, including common threats and best practices.

The case studies illustrated enterprise SSO with both SAML and OIDC, academic federation (InCommon), and social login with OIDC. These examples demonstrated how federation is applied in practice to meet diverse needs.

This tutorial has equipped you with a thorough understanding of federated identity and SSO, enabling you to design and implement solutions that provide secure, seamless access across organizational boundaries. In the next tutorial, Tutorial 3.15, we will explore Internet Authentication Applications, covering protocols like RADIUS, TACACS+, and Diameter that are used for network access authentication.

Quiz

Answer the following questions to check your understanding. Click the "Answer" button to reveal the solution.

Q1. In a federated identity system, which component authenticates the user and issues assertions?

A) Service Provider (SP)
B) Identity Provider (IdP)
C) Resource Server
D) User Agent

Answer

B) The Identity Provider (IdP) authenticates the user and issues assertions.

Q2. Which protocol is an XML-based standard for exchanging authentication and authorization data?

A) OAuth 2.0
B) OpenID Connect
C) SAML 2.0
D) Kerberos

Answer

C) SAML 2.0 is an XML-based standard for exchanging authentication and authorization data.

Q3. What is the primary purpose of OAuth 2.0?

A) Authentication
B) Authorization (delegated access)
C) Single Sign-On
D) Encryption

Answer

B) OAuth 2.0 is an authorization framework for delegated access.

Q4. Which OIDC token is a JWT that contains claims about the user's identity?

A) Access token
B) Refresh token
C) ID token
D) Authorization code

Answer

C) The ID token contains claims about the user's identity.

Q5. In a SAML Web Browser SSO profile, the assertion is typically sent from the IdP to the SP via:

A) HTTP Redirect
B) HTTP POST
C) SOAP
D) TCP

Answer

B) The assertion is often sent via HTTP POST binding.

Q6. Which security feature in SAML prevents an assertion from being used by a different SP?

A) Signing
B) Encryption
C) Audience restriction
D) NotBefore/NotOnOrAfter

Answer

C) Audience restriction limits the assertion to a specific SP.

Q7. In OAuth 2.0, which grant type is used for server-side web applications?

A) Implicit
B) Authorization Code
C) Client Credentials
D) Resource Owner Password Credentials

Answer

B) The Authorization Code grant is used for server-side web apps.

Q8. Which protocol is built on top of OAuth 2.0 and provides authentication?

A) SAML
B) OpenID Connect
C) RADIUS
D) LDAP

Answer

B) OpenID Connect is an identity layer built on OAuth 2.0.

Q9. Which federation model involves a central broker that manages trust between IdPs and SPs?

A) Direct Trust
B) Brokered Trust
C) Cross-Certification
D) Peer-to-Peer

Answer

B) Brokered trust uses a central broker or hub.

Q10. Which OIDC claim uniquely identifies the user?

A) email
B) name
C) sub
D) aud

Answer

C) The sub (subject) claim uniquely identifies the user.

Q11. In OAuth 2.0, which parameter is used to protect against CSRF attacks in the authorization code flow?

A) scope
B) state
C) redirect_uri
D) client_id

Answer

B) The state parameter protects against CSRF attacks.

Q12. Which protocol is commonly used for academic federations like InCommon?

A) OAuth 2.0
B) OpenID Connect
C) SAML 2.0
D) RADIUS

Answer

C) SAML 2.0 is the protocol used in InCommon and many other academic federations.

Exercises

These exercises are designed to help you apply the concepts from this tutorial. Attempt each exercise before revealing the sample solution.

Exercise 3.14-1: SAML Flow Tracing

Describe the complete SAML 2.0 Web Browser SSO flow, including all messages and redirects. Assume the user is not yet authenticated. Include the roles, bindings, and the contents of the AuthnRequest and Response. What is the purpose of the RelayState parameter?

Sample Solution

SAML Web Browser SSO Flow:

User accesses a protected resource at the SP (e.g., https://sp.example.com/secure).
SP checks for an existing session; if none, it generates an AuthnRequest (with an ID, issue instant, and optionally a RelayState) and sends it to the IdP via a redirect (HTTP Redirect binding) or POST.
User is redirected to the IdP's Single Sign-On endpoint.
IdP processes the AuthnRequest, authenticates the user (if not already authenticated), and generates an assertion containing authentication and attribute statements.
IdP sends the assertion to the SP via HTTP POST (most common) with the RelayState (if any).
SP receives the POST, validates the assertion (signature, audience, expiration), extracts the user identity and attributes, creates a session, and redirects the user to the originally requested resource.

RelayState: A parameter that allows the SP to pass state information (e.g., the target URL) to the IdP and have it returned, enabling the SP to redirect the user to the correct page after authentication.

Exercise 3.14-2: OIDC Integration

You are developing a web application that needs to authenticate users using Google as the OpenID Provider. Describe the steps to integrate OIDC, including the configuration required, the endpoints used, and the token validation process. What scopes would you request to obtain the user's email and profile information?

Sample Solution

OIDC Integration with Google:

Register the application with Google Cloud Console to obtain a client ID and client secret.
Configure the redirect URI (e.g., https://yourapp.com/callback).
When a user clicks "Login with Google", redirect to Google's authorization endpoint: https://accounts.google.com/o/oauth2/v2/auth with parameters: client_id, redirect_uri, response_type=code, scope=openid%20email%20profile, state (random string).
Google authenticates the user and returns an authorization code to the redirect URI.
Your app exchanges the code for tokens by calling https://oauth2.googleapis.com/token with client_id, client_secret, code, redirect_uri, and grant_type=authorization_code.
Google returns an ID token (JWT), access token, and refresh token.
Validate the ID token: verify signature, issuer (accounts.google.com), audience (your client ID), expiration, and nonce (if used).
Extract user claims from the ID token (sub, email, name).
Optionally, fetch additional claims from the UserInfo endpoint: https://openidconnect.googleapis.com/v1/userinfo using the access token.
Create a local session for the user.

Scopes: openid email profile to obtain basic profile information.

Exercise 3.14-3: OAuth 2.0 Grant Type Selection

You have three different applications:

A traditional web application (server-side, with a backend).
A single-page application (SPA) running entirely in the browser.
A mobile app that needs to access a user's Google Drive files.

Which OAuth 2.0 grant type would you recommend for each and why? Discuss any security considerations for each.

Sample Solution

1. Traditional web app: Authorization Code grant. The app can keep the client secret secure on the server. It exchanges the code for tokens, reducing the risk of token interception. Use PKCE for added security.
2. SPA: Authorization Code with PKCE (or Implicit if PKCE is not available, but PKCE is now preferred). The app cannot keep a secret, so PKCE prevents authorization code interception. Use state parameter for CSRF protection.
3. Mobile app: Authorization Code grant with PKCE. Use a custom URI scheme for the redirect. The mobile app can securely store a client secret? Actually, mobile apps are considered public clients; PKCE is essential.

Security: Always use HTTPS; validate redirect URIs; use short-lived access tokens; and use refresh tokens with rotation.

Exercise 3.14-4: Federation Trust Model

An organization wants to set up a federation with three partners. Each partner has its own IdP. The organization's SPs need to trust all three IdPs. Compare direct trust vs. a brokered trust model. Which would you recommend and why? What are the trade-offs?

Sample Solution

Direct Trust: Each SP must be configured to trust each IdP individually. This requires managing metadata (certificates, endpoints) for all IdPs. For three partners, that's manageable, but as the number grows, it becomes unwieldy. Each SP must also independently decide which IdPs to trust.

Brokered Trust: A federation hub (broker) is used. All IdPs and SPs trust the broker. The broker provides a single set of metadata and manages trust. SPs only need to trust the broker. This scales better and simplifies administration.

Recommendation: Brokered trust, even for only three partners, as it provides a clear framework for expansion and reduces administrative overhead. The broker can also enforce policies (e.g., attribute release). The main trade-off is the need to establish and maintain the broker infrastructure.

Exercise 3.14-5: SAML vs OIDC Comparison

You are migrating an enterprise SSO system from SAML 2.0 to OpenID Connect. What are the key differences in architecture, message format, and user experience? What challenges might you encounter? Provide a migration strategy.

Sample Solution

Key Differences:

Message format: SAML uses XML; OIDC uses JSON (JWT). OIDC is lighter and easier to consume in modern web/mobile apps.
Bindings: SAML uses HTTP Redirect, POST, and SOAP; OIDC uses HTTP/REST with bearer tokens.
User experience: Both provide SSO, but OIDC is more native to mobile and SPAs.
Security: Both support signing and encryption, but OIDC's JWT is simpler to implement.
Attributes: SAML uses AttributeStatement with arbitrary XML; OIDC uses claims in the ID token or UserInfo endpoint.

Challenges:

Legacy applications that only support SAML may need a federation gateway.
Re-configuring all SPs and IdPs to use OIDC.
User attribute mapping and consent.
Updating client applications to handle JWT tokens.

Migration Strategy:

Deploy a federation broker that supports both SAML and OIDC (e.g., Azure AD, PingFederate).
Migrate SPs one by one: start with modern applications using OIDC, then legacy applications via SAML.
Use the broker to translate between protocols during the transition.
Phase out SAML endpoints gradually.

Homework

These homework questions require deeper analysis, research, and application. Answer each question comprehensively.

Homework 3.14-1: Federated Identity Strategy

Write a 1,000–1,250 word strategy paper on implementing federated identity for a large enterprise that has multiple business units, each with its own identity systems, and also needs to collaborate with external partners. Include an analysis of the trust models, protocol choices, and governance framework. Discuss how to handle attribute release, consent, and privacy.

Sample Answer

Federated Identity Strategy for Enterprise

Assessment: Multiple IdPs (internal and external) and SPs (internal and SaaS).
Trust Model: Use a central hub (broker) to simplify trust management. Each internal business unit's IdP trusts the hub; external partners trust the hub.
Protocols: Use SAML 2.0 for legacy apps and OIDC for modern apps. Use the hub to translate.
Governance: Establish a federation agreement, define attribute release policies, and implement consent management.
Attribute Release: Minimize released attributes; use opt-in consent for sensitive attributes.
Privacy: Comply with GDPR/CCPA; provide user control over data sharing.

Homework 3.14-2: Security Analysis of Federation

Write a 750–1,000 word analysis of the security vulnerabilities in federated identity systems. Include at least five distinct threats, describe their impact, and propose specific countermeasures for each. Discuss the role of the IdP, SP, and the communication channels in security.

Sample Answer

Security Analysis of Federated Identity

Threat 1: Assertion Tampering – Impact: attacker modifies assertion to gain unauthorized access. Countermeasure: signing.
Threat 2: Token Theft – Impact: stolen access token used to access resources. Countermeasure: HTTPS, short lifetimes, token binding.
Threat 3: Redirect URI Manipulation – Impact: attacker intercepts authorization code. Countermeasure: strict redirect URI validation.
Threat 4: Phishing – Impact: user credentials stolen. Countermeasure: MFA, user education.
Threat 5: Session Hijacking – Impact: attacker uses stolen session cookie. Countermeasure: session timeout, IP binding, MFA.

IdP must protect user credentials and session; SP must validate tokens; channels must be encrypted (HTTPS).

Homework 3.14-3: OIDC vs SAML Research

Write a 1,000–1,250 word research paper comparing OpenID Connect and SAML 2.0 in terms of architectural principles, security features, deployment complexity, and suitability for modern applications. Provide a decision framework for choosing one over the other, including factors like application type, user base, and organizational context.

Sample Answer

OIDC vs SAML 2.0

Architecture: SAML is XML-based, uses complex bindings; OIDC is JSON/JWT, simpler REST.
Security: Both support signatures and encryption; OIDC's JWT is more widely supported in modern languages.
Deployment: SAML requires metadata exchange and more configuration; OIDC is simpler for developers.
Modern apps: OIDC is better for mobile and SPAs; SAML is still prevalent in enterprise.
Decision framework: Use SAML for legacy enterprise SSO; use OIDC for new applications, mobile, and consumer SSO.

Homework 3.14-4: Federation Implementation Plan

Develop a detailed implementation plan for setting up a federation between your organization and a key partner. Include steps for:

Establishing trust (metadata exchange).
Choosing protocols (SAML or OIDC).
Configuring IdP and SP.
Testing the connection.
Attribute mapping and release.
User onboarding and support.
Monitoring and troubleshooting.

Sample Answer

Federation Implementation Plan

Step 1: Define use case and required attributes.
Step 2: Agree on protocol (SAML 2.0).
Step 3: Exchange metadata (entity IDs, endpoints, certificates).
Step 4: Configure IdP (your side) to release attributes to partner SP.
Step 5: Configure SP (partner side) to accept assertions from your IdP.
Step 6: Test with a test user; verify authentication and attribute release.
Step 7: Roll out to production users; provide documentation.
Step 8: Set up monitoring (log analysis, alerting).
Step 9: Plan for regular metadata updates and periodic testing.

Homework 3.14-5: Future of Federation

Write a 1,000–1,250 word essay on the future of federated identity. Discuss emerging trends such as decentralized identity (Self-Sovereign Identity), the role of blockchain, and the impact of AI on authentication and authorization. How will federation adapt to the needs of the Internet of Things (IoT) and edge computing?

Sample Answer

Future of Federated Identity

Decentralized Identity (SSI): Users control their own identity; federated models may evolve to support verifiable credentials.
Blockchain: Can provide a tamper-proof ledger for trust and consent.
AI: Risk-based authentication and anomaly detection will become integral to federation.
IoT: Billions of devices will need federated identity; lightweight protocols (e.g., OIDC for IoT) will emerge.
Zero Trust: Federation will integrate with continuous verification and micro-segmentation.

Summary

This tutorial provided a comprehensive exploration of federated identity and single sign-on. We defined federated identity as a system that enables users to use a single identity across multiple organizations, and SSO as the seamless authentication experience it enables. We discussed the core roles—Identity Provider (IdP), Service Provider (SP)—and the trust relationships that underpin federation, including direct and brokered trust models.

Tutorial 3.14: Federated Identity and Single Sign-On

Table of Contents

Learning Objectives

Overview

1. Introduction to Federated Identity

1.1 What is Federated Identity?

1.2 Key Benefits

1.3 Core Roles

2. Single Sign-On (SSO) Concepts

2.1 What is SSO?

2.2 How SSO Works

2.3 SSO in Practice

2.4 Enterprise SSO vs. Federated SSO

3. Trust Relationships and Federation Models

3.1 Trust Basics

3.2 Federation Models

3.3 Federation Agreements

4. Federation Protocols: SAML, OAuth, OIDC

4.1 Overview

4.2 Protocol Comparison

5. SAML 2.0 Architecture and Flows

5.1 SAML Components

5.2 Web Browser SSO Profile

5.3 SAML Assertion Structure (Simplified)

5.4 SAML Security

6. OAuth 2.0 Authorization Framework

6.1 OAuth 2.0 Overview

6.2 Grant Types

6.3 Token Types

6.4 OAuth 2.0 Security Considerations

7. OpenID Connect (OIDC)

7.1 What is OIDC?

7.2 OIDC Roles

7.3 OIDC Tokens

7.4 OIDC Flows

7.5 OIDC Claims

7.6 OIDC Security

8. Comparison and Selection

8.1 When to Use Each Protocol

8.2 Hybrid Scenarios

8.3 Summary Table

9. Security Considerations

9.1 Common Threats

9.2 Best Practices

10. Case Studies

10.1 Case Study: Enterprise SSO with SAML and OIDC

10.2 Case Study: Academic Federation (InCommon)

10.3 Case Study: Social Login with OIDC

11. Summary and Transition

Quiz

Exercises

Homework

Summary