Skip to main content

OAuth 2.0, OIDC, and SAML

Premium

Authentication and authorization protocols like OAuth 2.0, OpenID Connect (OIDC), and SAML are foundational to modern identity systems.

Interviewers expect you to understand how these protocols work conceptually, what problems they solve, and how they fit into IAM design. This lesson gives you a clear, structured way to explain them without overwhelming detail.

Strong candidates show that they can:

  1. Describe how federated identity systems authenticate users.
  2. Differentiate between authentication and authorization flows.
  3. Recognize where each protocol is typically used.
  4. Identify common implementation risks.

What to expect

Typical interview prompts include:

  • “Explain the difference between OAuth 2.0 and OIDC.”
  • “How would you secure OAuth tokens in a web application?”

Expect a mix of quiz-style and scenario-based questions on OAuth2.0, OIDC, and SAML.

Overview

ProtocolPurposeToken typeCommon use case
OAuth 2.0Delegated authorization.Access tokens.API access or third-party integrations.
OIDCAuthentication + authorization.ID tokens + access tokens.Web and mobile app login (“Sign in with Google”).
SAMLFederated authentication (legacy).XML assertions.Enterprise SSO (internal systems).

In interviews, reference their differences by focus:

  • OAuth: Access control.
  • OIDC: Authentication.
  • SAML: Enterprise SSO and federation.

Prompt: “Explain the difference between OAuth 2.0 and OIDC.”

Strong response: “OAuth 2.0 allows delegated authorization, granting limited access to resources without sharing credentials. OpenID Connect builds on OAuth by adding authentication through ID tokens. OAuth answers ‘what can this app do?’, while OIDC answers ‘who is this user?’.”

We will elaborate on what you need to know about each protocol for your interviews in the sections below.

OAuth 2.0

Purpose: Allow one application to access resources on behalf of a user without sharing credentials.

How it works:

  1. The user grants an application permission to access a resource (for example, Google Drive or GitHub).
  2. The app receives an access token from an authorization server.
  3. The token allows limited API access, scoped to the granted permissions.

OAuth 2.0 lets a third-party calendar app access your Google Calendar without ever seeing your password.

Common pitfalls:

  • Misconfigured redirect URIs leading to token leakage.
  • Storing tokens insecurely.
  • Missing scopes or token expiry controls.

Describe OAuth 2.0 as a delegation framework, not authentication. It’s about granting access, not proving identity.

OpenID Connect (OIDC)

Purpose: OIDC extends OAuth 2.0 to provide authentication in addition to authorization.

How it works:

  1. Uses OAuth 2.0 flows but adds an ID token that includes verified user identity information.
  2. Applications can use the ID token to authenticate the user.

OpenID Connect is what lets you “Log in with Google” or “Log in with Microsoft” while OAuth handles permissions behind the scenes.

Common pitfalls:

  • Misinterpreting access tokens as identity proof.
  • Failing to validate the ID token signature or issuer.
  • Ignoring token expiration or audience claims.

OIDC is the modern standard for user authentication in web and mobile applications.

SAML

Purpose: Provide federated single sign-on (SSO) between identity providers (IdPs) and service providers (SPs).

How it works:

  1. The user requests access to a service provider.
  2. The IdP authenticates the user and sends a SAML assertion (XML-based token).
  3. The service provider grants access based on the assertion.

When employees log in to internal tools through Okta or Azure AD, they’re often using SAML behind the scenes.

Common pitfalls:

  • XML signature wrapping attacks.
  • Unvalidated assertions or issuers.
  • Poor clock synchronization causing token reuse.

SAML remains prevalent in enterprise environments but is being replaced by OIDC for modern web apps.

Next Lesson