Tutorial 3.16: OAuth, OpenID Connect, and Modern Identity Systems

← Previous Tutorial (3.15) | Table of Contents | Unit Home | Next Tutorial (3.17) →

Table of Contents

Learning Objectives

After completing this tutorial, you should be able to:

Overview

In the previous tutorials, we explored authentication protocols for network access (RADIUS, TACACS+, Diameter) and federated identity (SAML). However, the modern web, mobile, and cloud landscape has been shaped by a new set of protocols: OAuth 2.0 and OpenID Connect (OIDC). These have become the de facto standards for securing APIs, enabling delegated access, and providing user authentication in web and mobile applications.

OAuth 2.0 is an authorization framework that allows third-party applications to obtain limited access to a user's resources without exposing the user's credentials. It is widely used for "Login with Google/Facebook," API access, and cloud service authorization. OAuth 2.0 defines several grant types (flows) for different client types and use cases, each with specific security considerations.

OpenID Connect (OIDC) builds on OAuth 2.0 to provide authentication and user identity information. OIDC adds an ID token (a JWT) that contains claims about the user, enabling single sign-on and user info retrieval. OIDC has become the standard for modern web and mobile authentication, offering a simpler and more flexible alternative to SAML.

This tutorial provides a comprehensive exploration of OAuth 2.0, OIDC, and modern identity systems. We begin by introducing the OAuth 2.0 framework, its roles, and the various grant types. We then dive deep into the authorization code flow (the most common), the implicit flow (now deprecated), the client credentials flow, and the refresh token flow. We analyze the security properties and common attacks (e.g., CSRF, redirect URI manipulation, token theft).

We then introduce OpenID Connect, explaining how it extends OAuth 2.0 with the ID token, UserInfo endpoint, and discovery. We cover the OIDC flows and the semantics of claims. We also discuss modern identity systems, including enterprise identity providers (Azure AD, Okta) and consumer identity providers (Google, Facebook, Apple).

We provide practical guidance on implementing OAuth 2.0 and OIDC, including best practices for security, troubleshooting, and integration patterns. The tutorial concludes with case studies illustrating enterprise SSO with OIDC, mobile app authentication, and API gateway security. By the end, you will have a thorough understanding of the protocols that power modern identity and access management.

1. Introduction to Modern Identity Systems

1.1 The Shift from Enterprise to Internet-Scale Identity

Traditional enterprise identity was built around on-premises directories (Active Directory) and protocols like Kerberos and LDAP. The rise of cloud, mobile, and APIs has driven the need for identity systems that are:

OAuth 2.0 and OIDC emerged as the foundation for this new paradigm, enabling secure delegated access and authentication for web, mobile, and IoT.

1.2 OAuth 2.0 vs. OpenID Connect

In practice, OIDC is often used for authentication, while OAuth 2.0 is used for authorization (API access). They are commonly used together.

Key Takeaway: OAuth 2.0 and OpenID Connect are the foundational protocols for modern identity systems, providing delegated authorization and authentication for internet-scale applications.

2. OAuth 2.0 Framework – Deep Dive

2.1 OAuth 2.0 Roles

2.2 Grant Types (Flows)

OAuth 2.0 defines several grant types (flows) based on the client type and use case:

2.3 Authorization Code Flow (Detailed)

This is the most secure and recommended flow for web applications. It involves an intermediate authorization code that is exchanged for tokens, preventing the access token from being exposed in the browser.

  1. Client redirects user to Authorization Server: Client constructs an authorization URL with parameters: response_type=code, client_id, redirect_uri, scope, state.
  2. User authenticates and consents: Authorization server authenticates the user and prompts for consent (if needed).
  3. Authorization server redirects back with code: Server redirects to the client's redirect URI with an code parameter (authorization code) and the state parameter.
  4. Client exchanges code for tokens: Client makes a POST request to the token endpoint with grant_type=authorization_code, code, redirect_uri, and client credentials.
  5. Authorization server returns tokens: Server responds with access_token, refresh_token (optional), expires_in, and optionally an id_token (if OIDC).
  6. Client uses access token to access resources: Client includes the access token in the Authorization: Bearer header.
// Example token exchange request POST /token HTTP/1.1 Host: auth.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& code=abc123& redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback& client_id=client123& client_secret=secret456

2.4 Implicit Flow (Deprecated)

In the implicit flow, the access token is returned directly in the redirect URI fragment. This flow was intended for SPAs, but it has security concerns (token exposure in the browser history, inability to refresh tokens without user interaction). OAuth 2.1 deprecates the implicit flow in favor of the Authorization Code flow with PKCE.

2.5 Client Credentials Flow

Used for machine-to-machine communication. The client authenticates using its credentials and obtains an access token that represents the client itself (not a user). This flow does not involve user consent.

2.6 Refresh Token Flow

When an access token expires, the client can use a refresh token to obtain a new access token without user interaction. Refresh tokens are long-lived and must be stored securely.

2.7 Token Types and Security

2.8 OAuth 2.0 Security Considerations

Important: OAuth 2.0 is a framework, not a strict protocol. Implementations vary; always follow security best practices and use well-tested libraries.

3. OpenID Connect (OIDC)

3.1 Introduction and Relationship to OAuth 2.0

OpenID Connect (OIDC) is a simple identity layer built on top of OAuth 2.0. It allows clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information. OIDC is the successor to OpenID 2.0 and is widely adopted.

3.2 OIDC Tokens

3.3 OIDC Flows

In practice, the Authorization Code flow with PKCE is recommended for all clients, including public clients (SPAs, mobile apps).

3.4 OIDC Claims and Scopes

Claims are pieces of information about the user. Common scopes:

3.5 UserInfo Endpoint

The UserInfo endpoint returns claims about the authenticated user. The client includes the access token in the request, and the server returns a JSON object with the user's claims.

3.6 OIDC Discovery and Dynamic Registration

OIDC Discovery defines a well-known configuration endpoint (/.well-known/openid-configuration) that returns the OP's metadata (issuer, authorization endpoint, token endpoint, UserInfo endpoint, JWKS URI, etc.). Dynamic registration allows clients to register with the OP programmatically.

// Example ID Token (JWT) payload { "sub": "1234567890", "name": "John Doe", "email": "john@example.com", "iss": "https://auth.example.com", "aud": "client123", "iat": 1311280970, "exp": 1311284570 }
Key Takeaway: OpenID Connect extends OAuth 2.0 with authentication and user identity, providing a standardized way to implement SSO and user profile retrieval in modern applications.

4. Modern Identity Systems

4.1 Enterprise Identity Providers (IdPs)

4.2 Consumer Identity Providers

4.3 Decentralized Identity and Self-Sovereign Identity (SSI)

Emerging paradigm where users own and control their identity data without relying on centralized IdPs. Uses blockchain and verifiable credentials. Standards: DID (Decentralized Identifiers), Verifiable Credentials (VCs). OIDC can be extended with SIOP (Self-Issued OpenID Provider) to support SSI.

4.4 Comparison of Identity Providers

Provider Protocols Target Audience Key Features
Azure AD OIDC, SAML, OAuth Enterprise Conditional Access, MFA, AD integration
Okta OIDC, SAML, OAuth Enterprise Lifecycle management, adaptive authentication
Auth0 OIDC, OAuth Developers Social login, extensibility, tenant support
Google OIDC, OAuth Consumers Billions of users, easy integration
Facebook OAuth Consumers Social graph integration

5. OAuth 2.0 and OIDC in Practice

5.1 Implementing an OAuth 2.0 Authorization Server

When building an authorization server, consider using well-established libraries or frameworks (e.g., Spring Security, OIDC libraries for Node.js, Python, or commercial solutions). Key endpoints:

5.2 Client Integration Patterns

5.3 Security Best Practices

5.4 Troubleshooting Common Issues

6. Case Studies

6.1 Case Study: Enterprise SSO with OIDC

Background: A large enterprise with 15,000 employees uses Azure AD as the central identity provider. They want to enable SSO for all internal and external applications, including custom web apps, SaaS apps, and mobile apps. They also need MFA and conditional access.

Solution:

Outcome: Employees have seamless SSO across all applications. Security is enhanced with MFA and conditional access. Administration is centralized.

6.2 Case Study: Mobile App Authentication with OAuth 2.0

Background: A mobile app (iOS/Android) needs to access a backend API. The app must authenticate users and obtain authorization to access user data. They want to use social login (Google/Facebook) and also support email/password.

Solution:

Outcome: Users can sign in with their preferred method. The app securely accesses the backend API. Refresh tokens keep users logged in across sessions.

6.3 Case Study: API Gateway Security with OAuth 2.0

Background: A microservices architecture with many internal services. They need to secure APIs for both internal and external clients. They want to use OAuth 2.0 for API authorization.

Solution:

Outcome: The API Gateway centralizes security enforcement. Internal services can focus on business logic. Token validation is efficient and consistent.

7. Future Trends and Evolution

7.1 OAuth 2.1

OAuth 2.1 is an upcoming revision that consolidates and simplifies the OAuth 2.0 specification. It deprecates the implicit and password grant types, mandates PKCE for public clients, and incorporates best practices. It aims to make OAuth more secure and easier to implement.

7.2 Token Binding and JWT Best Practices

Token binding ties a token to a specific client context (e.g., TLS session). This can prevent token theft and replay attacks. JWT best practices include using short-lived tokens, strong signing algorithms (e.g., ES256), and proper audience validation.

7.3 Decentralized Identity (DID/Verifiable Credentials)

Self-Sovereign Identity (SSI) aims to give users control over their identity data. Standards like DID (Decentralized Identifiers) and Verifiable Credentials are emerging, and OIDC can be extended with SIOP (Self-Issued OpenID Provider) to support SSI.

7.4 AI and Identity

AI/ML is being used for risk-based authentication, anomaly detection, and adaptive access control. Identity systems are becoming more intelligent, adjusting policies based on real-time risk.

Key Takeaway: OAuth 2.0 and OIDC continue to evolve with OAuth 2.1, token binding, and integration with decentralized identity. Modern identity systems are increasingly intelligent and adaptive.

Quiz

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

Q1. Which OAuth 2.0 role is responsible for authenticating the user and issuing access tokens?

Answer
C) The Authorization Server authenticates the resource owner and issues access tokens.

Q2. Which OAuth 2.0 grant type is recommended for server-side web applications?

Answer
C) The Authorization Code Grant is recommended for server-side web apps.

Q3. In OpenID Connect, which token contains identity claims about the user?

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

Q4. Which OAuth 2.0 parameter is used to protect against CSRF attacks?

Answer
B) The state parameter protects against CSRF attacks.

Q5. Which extension to the Authorization Code Flow prevents authorization code interception attacks?

Answer
A) PKCE (Proof Key for Code Exchange) protects against code interception.

Q6. In OIDC, which endpoint returns additional user claims?

Answer
C) The UserInfo Endpoint returns additional user claims.

Q7. Which OAuth 2.0 grant type is deprecated in OAuth 2.1?

Answer
C) The Implicit grant is deprecated in OAuth 2.1.

Q8. Which scope is required to indicate the use of OpenID Connect?

Answer
C) The openid scope is required for OIDC.

Q9. In OAuth 2.0, which role hosts the protected resources and validates access tokens?

Answer
C) The Resource Server hosts protected resources and validates access tokens.

Q10. Which of the following is a common security vulnerability in OAuth 2.0?

Answer
A) Redirect URI manipulation is a common vulnerability.

Q11. Which OIDC flow is recommended for single-page applications (SPAs)?

Answer
B) Authorization Code Flow with PKCE is recommended for SPAs.

Q12. What is the purpose of the refresh token in OAuth 2.0?

Answer
A) The refresh token is used to obtain a new access token without user interaction.

Exercises

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

Exercise 3.16-1: OAuth 2.0 Flow Tracing

Describe the complete OAuth 2.0 Authorization Code flow for a web application. Include all steps, parameters, and the security measures in place. Explain what happens if the user denies consent.

Sample Solution

Authorization Code Flow:

  1. User clicks "Login" -> client redirects to authorization endpoint with response_type=code, client_id, redirect_uri, scope, state.
  2. Authorization server authenticates user and prompts for consent.
  3. If user approves, server redirects to redirect_uri with code and state.
  4. Client exchanges code for tokens via POST to token endpoint with grant_type=authorization_code, code, redirect_uri, and client credentials.
  5. Server responds with access_token, refresh_token (optional), expires_in, and (if OIDC) id_token.
  6. Client uses access token to access resources.

Security: state prevents CSRF; redirect URI validation prevents code interception; client secret ensures only authorized client can exchange code.

Denied consent: Server redirects to redirect_uri with error=access_denied and no code.

Exercise 3.16-2: OIDC ID Token Validation

You receive an ID token from an OIDC provider. Describe the validation steps you must perform on the client side before trusting the identity. Include signature validation, issuer, audience, expiration, and any other relevant checks.

Sample Solution

ID Token Validation Steps:

  1. Verify the signature using the provider's JWKS (public keys). Ensure the algorithm is appropriate (e.g., RS256).
  2. Check the iss (issuer) claim matches the expected provider URL.
  3. Check the aud (audience) claim matches the client ID.
  4. Check the exp (expiration) claim: token must not be expired.
  5. Check the iat (issued at) claim: token should not be from the future (allow some clock skew).
  6. If a nonce was used in the authentication request, verify it matches.
  7. Check auth_time if required.
  8. Additional checks: verify the azp (authorized party) if needed.

Exercise 3.16-3: OAuth 2.0 Security Analysis

You are auditing an OAuth 2.0 implementation. List at least five potential security issues you would look for and explain how to mitigate them.

Sample Solution
  • 1. Insecure redirect URI validation: Attackers can intercept authorization codes. Mitigation: register full redirect URIs and validate exact match.
  • 2. Missing state parameter: CSRF attack. Mitigation: generate and validate state.
  • 3. Client secret exposure: In public clients (SPAs, mobile). Mitigation: use PKCE for public clients, never embed secrets in client-side code.
  • 4. Token leakage: Access tokens exposed in browser history or logs. Mitigation: use short-lived tokens, avoid storing tokens in local storage; use secure HTTP-only cookies for refresh tokens.
  • 5. Weak token signing algorithm: Use strong algorithms (RS256, ES256) instead of HS256 for signed tokens.
  • 6. Lack of scope restriction: Request minimal scopes; ensure authorization server enforces scope limits.

Exercise 3.16-4: OIDC Discovery Configuration

An OIDC provider publishes a well-known configuration endpoint. What information does it typically contain? Provide a sample JSON response and explain the purpose of at least five fields.

Sample Solution

OIDC Discovery Document:

{ "issuer": "https://auth.example.com", "authorization_endpoint": "https://auth.example.com/authorize", "token_endpoint": "https://auth.example.com/token", "userinfo_endpoint": "https://auth.example.com/userinfo", "jwks_uri": "https://auth.example.com/keys", "response_types_supported": ["code", "id_token", "code id_token"], "subject_types_supported": ["public"], "id_token_signing_alg_values_supported": ["RS256"], "scopes_supported": ["openid", "profile", "email"], "claims_supported": ["sub", "email", "name", "picture"] }
  • issuer: The issuer identifier, must match the iss claim in tokens.
  • authorization_endpoint: URL for user authentication and consent.
  • token_endpoint: URL for exchanging authorization codes and refresh tokens.
  • jwks_uri: URL to retrieve JSON Web Key Set for verifying signatures.
  • scopes_supported: List of scopes the provider supports (e.g., openid, profile).
  • claims_supported: List of claims the provider can include in ID tokens.

Exercise 3.16-5: OAuth 2.0 Implementation Plan

You are tasked with implementing OAuth 2.0 for a new mobile app that needs to access a backend API. The app will use a third-party identity provider (e.g., Auth0). Outline the steps to integrate OAuth 2.0 (with OIDC) into the mobile app and the backend API. Include considerations for token storage, refresh tokens, and security.

Sample Solution

Mobile App OAuth 2.0 Integration Plan:

  • Step 1: Register the app with the identity provider (Auth0). Obtain client ID, configure redirect URI (using a custom URL scheme).
  • Step 2: Use a secure authentication library (AppAuth for mobile) to implement Authorization Code Flow with PKCE.
  • Step 3: Upon user login, the library opens a browser session (Chrome Custom Tabs/SFSafariViewController) for authentication.
  • Step 4: After successful authentication, the app receives an authorization code, which is exchanged for tokens (access token, refresh token).
  • Step 5: Store the refresh token in secure platform storage (Keychain/Keystore). Store the access token in memory (or secure storage with short expiry).
  • Step 6: For every API request, include the access token in the Authorization header.
  • Step 7: When the access token expires, use the refresh token to obtain a new access token silently.
  • Step 8: Backend API validates the access token using the provider's JWKS endpoint.
  • Step 9: Implement token revocation on logout and security best practices (HTTPS, state parameter, etc.).

Homework

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

Homework 3.16-1: OAuth 2.0 Security Research

Write a 1,000–1,250 word research paper on OAuth 2.0 security vulnerabilities and mitigations. Include an analysis of the following vulnerabilities:

Provide real-world examples and discuss how PKCE, state parameter, and other mitigations address these threats.

Sample Answer

OAuth 2.0 Security: Vulnerabilities and Countermeasures

  • Authorization Code Interception: Attacker intercepts the authorization code. Mitigation: PKCE, short-lived codes, strict redirect URI validation.
  • CSRF: Attacker tricks user into approving a request. Mitigation: state parameter.
  • Redirect URI Manipulation: Attacker uses a malicious redirect to capture code. Mitigation: exact match validation.
  • Token Theft: Attacker steals access token. Mitigation: short-lived tokens, HTTPS, token binding.
  • Scope Escalation: Client requests more scopes than needed. Mitigation: authorization server enforces scope limits.

Homework 3.16-2: OIDC vs. SAML Comparative Analysis

Write a 1,000–1,250 word analysis comparing OpenID Connect and SAML 2.0 for enterprise SSO. Discuss architectural differences, protocol features, security, and implementation complexity. Provide a decision framework for choosing between them for a new project.

Sample Answer

OIDC vs. SAML for Enterprise SSO

  • Architecture: SAML is XML-based, uses complex bindings; OIDC is JSON/JWT, simpler REST.
  • Security: Both support signing and encryption; OIDC's JWT is more widely used in modern languages.
  • Implementation Complexity: SAML requires more configuration; OIDC is easier for developers.
  • Use Cases: SAML for legacy enterprise apps; OIDC for modern web/mobile.
  • Decision Framework: Use OIDC for new projects; use SAML when integrating with legacy systems that only support SAML.

Homework 3.16-3: OAuth 2.0 Implementation for an API Gateway

Design and document a solution for securing a microservices architecture using OAuth 2.0 and an API Gateway. Include:

Sample Answer

API Gateway OAuth 2.0 Security Design

  • Architecture: API Gateway acts as Resource Server, validates tokens using JWKS from Authorization Server. Internal services trust the gateway and do not validate tokens.
  • Token Validation: Use local validation (JWKS) for performance; use introspection for revocation checks.
  • Client Flows: External clients: Authorization Code (for users) or Client Credentials (for machine). Internal services: Client Credentials.
  • Security: HTTPS, token expiration, scope enforcement.
  • Revocation: Provide a logout endpoint that revokes the refresh token; access tokens are short-lived.

Homework 3.16-4: Decentralized Identity Research

Write a 1,000–1,250 word research paper on Self-Sovereign Identity (SSI) and its relationship to OIDC. Discuss DID (Decentralized Identifiers), Verifiable Credentials, and the role of OIDC in SSI (SIOP). Analyze the benefits, challenges, and potential impact on traditional identity systems.

Sample Answer

Self-Sovereign Identity and OIDC

  • SSI: Users own and control their identity data, using DIDs and Verifiable Credentials.
  • SIOP (Self-Issued OpenID Provider): An OIDC profile for SSI, allowing users to act as their own IdP.
  • Benefits: User control, privacy, portability.
  • Challenges: Adoption, scalability, revocation.
  • Impact: Could reduce reliance on centralized IdPs and enable new trust models.

Homework 3.16-5: OAuth 2.1 vs. OAuth 2.0

Write a 1,000–1,250 word analysis of OAuth 2.1, the upcoming revision. Explain the key changes from OAuth 2.0, including the removal of implicit and password grants, the mandatory use of PKCE for public clients, and other security improvements. Discuss the implications for existing OAuth 2.0 implementations and migration strategies.

Sample Answer

OAuth 2.1: The Next Generation

  • Changes: Deprecation of implicit and password grants, PKCE required for public clients, and removal of less secure practices.
  • Implications: SPAs must switch to Authorization Code with PKCE; password grant clients must migrate to other flows.
  • Migration: Update clients to use modern flows; use OAuth 2.1-compliant libraries.
  • Benefits: Improved security and simplicity.

Summary

This tutorial provided a comprehensive exploration of OAuth 2.0, OpenID Connect, and modern identity systems. We began by introducing the evolution of identity systems from enterprise-centric to internet-scale, and the roles of OAuth 2.0 and OIDC in this landscape. We then dove deep into the OAuth 2.0 framework, covering its core roles, grant types (flows), and security considerations. We analyzed the Authorization Code flow in detail, and discussed the deprecated implicit and password flows, and the client credentials flow.

We then explored OpenID Connect, explaining how it extends OAuth 2.0 with authentication and the ID token. We covered the structure of ID tokens, the UserInfo endpoint, OIDC flows, and discovery. We also surveyed modern identity systems, including enterprise providers (Azure AD, Okta) and consumer providers (Google, Facebook), and discussed emerging trends like decentralized identity (SSI).

Practical guidance was provided on implementing OAuth 2.0 and OIDC, including security best practices and troubleshooting. The case studies illustrated enterprise SSO with OIDC, mobile app authentication, and API gateway security, demonstrating real-world applications.

Finally, we looked at future trends, including OAuth 2.1, token binding, and the integration of AI and decentralized identity. This tutorial has equipped you with a thorough understanding of the protocols that power modern identity and access management, enabling you to design, implement, and secure applications using OAuth 2.0 and OIDC.

← Previous Tutorial (3.15) | Table of Contents | Unit Home | Next Tutorial (3.17) →

© 2026 COMP400 – Computer and Network Security • School of Computing and Information Systems, TrustOpen University • Unit 3: Authentication and Access Control