OAuth delegates access
OAuth 2.0 is an authorization framework. A user permits one application to access a resource without sharing the user’s password. The resulting access token is meant for a particular API and scope.
An access token does not, by itself, tell your application who the human is. Its format may even be opaque. To learn the account identity, the client normally calls the provider’s user-information endpoint with that token.
OpenID Connect adds identity
OpenID Connect builds an authentication layer on OAuth 2.0. It introduces an ID token containing claims about the authenticated subject, plus standardized discovery and user-information behavior.
For a social-login product, the useful output is often deliberately narrow: a verified or provider-supplied email address. Your application can map that email to its own user record without importing the provider’s permissions model.
Why providers behave differently
Not every provider returns identity in exactly the same way. Some return an ID token from the token endpoint. Others require a second request to a user or email endpoint. GitHub, for example, can return multiple email addresses, so a login integration needs a consistent rule for choosing the primary address.
A broker absorbs those protocol differences and presents one completion contract to your backend. That reduces provider-specific code, but it does not remove your responsibility to verify the broker result server-side.
Authorization code flow in plain English
The browser is redirected to the provider with a client ID, callback URL, requested scopes and state value. The provider returns a short-lived authorization code to a registered callback. A trusted server exchanges that code for tokens over a direct HTTPS connection.
The important boundary is that provider client secrets and broker API keys stay out of the browser. Browser parameters coordinate the flow; trusted server-to-server calls establish the result.
Which one should you use?
If you need a person to sign in, use an OpenID Connect identity response where the provider supports it, or retrieve the account identity through the provider’s protected user endpoint. If you need permission to act on a user’s resources, that is OAuth authorization and should use only the scopes required.
For Login Broker integrations, your application consumes one verified-email result and keeps ownership of users, roles and application sessions.