When does a relying party need the UserInfo endpoint if it already has an ID token?

The ID token proves the authentication and identifies the user (sub); the UserInfo endpoint delivers further profile claims (name, email, picture...) on demand, fetched over the back channel with the access token.

The two serve different purposes:

• The ID token is about the authentication event: who the user is, who vouches for it, for which client, when and how they logged in. It is signed, so the RP can verify it once and rely on it. Providers keep it small, and often include only a few profile claims or none.
• The UserInfo endpoint is an OAuth-protected API on the authorization server. The RP calls GET /userinfo with Authorization: Bearer <access token> and receives a JSON object with the claims the user consented to, for example:

{"sub": "248289761001", "name": "Jane Doe", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg"}

Which claims come back depends on the requested scopes (profile, email, address, phone). One rule matters for security: the RP must check that the sub in the UserInfo response equals the sub in the ID token, otherwise it might attach someone else's profile to the session.

Go deeper:

• OpenID Connect Core 1.0: UserInfo Endpoint — including the rule that the sub values must match.
• OpenID Connect Core 1.0: Requesting Claims using Scope Values — which claims the profile, email, address and phone scopes return.