Which statement correctly characterizes the relationship among SAML, OpenID Connect, and OAuth 2.0 in the context of TA identity federation?

• A. SAML uses JSON Web Tokens for enterprise SSO.
• B. OIDC builds on OAuth 2.0 and uses JWTs for authentication.
• C. OAuth 2.0 focuses on authentication.
• D. SAML is purely for authorization tokens in APIs.

Answer: (B)

OpenID Connect extends OAuth 2.0 by adding a way to prove who the user is, not just what they’re allowed to do. OAuth 2.0 handles authorization—granting access to resources—but it doesn’t define how to authenticate the user. OpenID Connect fills that gap by introducing an ID Token, typically a JSON Web Token (JWT), which carries identity information about the user. This ID Token lets a relying party verify the user’s identity and obtain basic profile data, while OAuth 2.0 handles the actual permissions/scopes.

SAML, by contrast, is an older, XML-based standard used for single sign-on in many enterprises. It uses SAML assertions rather than JWTs and operates differently from how OpenID Connect operates on top of OAuth 2.0. That’s why exactly stating that SAML uses JWTs for enterprise SSO isn’t correct, and because SAML assertions are not the same as the tokens used in OpenID Connect.

Another common misunderstanding is that OAuth 2.0 itself handles authentication. It does not define how to authenticate the user; its primary job is delegated authorization, not user authentication. That’s why the option claiming OAuth 2.0 focuses on authentication isn’t accurate.

So, the best description is that OpenID Connect builds on OAuth 2.0 and uses JWTs for authentication, providing a standardized way to obtain and verify user identity within federation scenarios.