A web application already uses an external provider's OAuth 2.0 flow to obtain API access tokens. The developers now need the application to verify who actually signed in and read basic profile claims such as name and email from a signed token issued by that same provider. Which technology adds this capability?
Select an answer to reveal the explanation.
Short Explanation
OAuth hands your app a key to the API, but it never actually tells you whose hand is holding it. OpenID Connect sits on top of OAuth 2.0 and adds the ID token, the signed 'this is who signed in' card. The trap is asking for more OAuth scopes and thinking that's authentication.
Full Explanation
OpenID Connect is an identity layer built on top of OAuth 2.0. When the client includes the openid scope, the provider returns an ID token, a signed JSON Web Token containing claims about the authenticated user, such as a subject identifier and, with the right scopes, name and email. The client validates the signature, issuer, audience and expiry, and then knows who signed in. Because the application already runs an OAuth 2.0 flow with the provider, adding OpenID Connect is the natural extension. Requesting broader OAuth scopes only widens what the access token may do at the API; an access token is meant for the resource server and is not a defined proof of the user's identity to the client. Attribute-based access control is an authorization model that evaluates attributes to permit or deny actions; it does not authenticate anyone or produce identity claims. A Kerberos service principal name identifies a service instance so clients can obtain Kerberos tickets for it inside a Kerberos realm; it is unrelated to an external provider's OAuth flow and returns no signed profile token. Exam caveat: OAuth is authorization, OpenID Connect is authentication on top of OAuth 2.0. Operational check: confirm the request includes the openid scope and that the application validates the ID token's signature, issuer and audience.