OAuth2 vs OpenID Connect: the practical difference
How OAuth2 and OpenID Connect differ, when to use each, and how they show up in modern authentication and authorization.
OAuth2 and OpenID Connect show up together in almost every modern login document — and many people use the terms as synonyms. They are not. OAuth2 solves authorization (what an app may do on someone’s behalf). OpenID Connect solves authentication (who that person is). Getting that difference wrong leads to fragile architectures, misused tokens, and exposed APIs.
What OAuth2 actually is
OAuth2 defines how a client obtains an access token to call protected resources without asking for the user’s password on every integration. The classic flow is Authorization Code: the user authenticates at the authorization server, the app receives a code, and the backend exchanges it for tokens.
- Access token — credential for calling APIs
- Refresh token — renews the access token without a new login
- Scope — limits what the token allows
What OpenID Connect adds
OIDC is a layer on OAuth2 that standardizes identity. Besides the access token, you receive an ID Token (JWT) with claims such as sub, email, and email_verified. Your application can know who signed in without inventing a proprietary profile endpoint.
// ID Token (simplified payload)
{
"iss": "https://auth.gatekeeperid.cloud/realms/tenant-a",
"sub": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"aud": "my-spring-app",
"exp": 1710000000,
"email": "dev@empresa.com"
}When to use each
OAuth2 alone makes sense when…
- You integrate machine to machine (Client Credentials)
- The goal is to delegate access to a third-party API, without a user profile
- Identity is already resolved by another channel
OIDC is necessary when…
- Human users sign in to your application
- You need SSO across products
- Social login (Google, Microsoft) enters the flow
- RBAC depends on who the authenticated user is
Common mistakes
- Treating the access token as an ID token — exposing sensitive data in the frontend
- Validating a JWT with base64 decode only, without checking the signature
- Storing the client secret in a SPA or mobile app
- Ignoring
audandissduring validation - Using the password grant in public apps
How Gatekeeper ID helps
Gatekeeper ID wraps OAuth2 and OIDC per tenant: an isolated realm, JWT issuance, refresh, social login, and a ready integration API. On Spring Boot, the SDK validates tokens via JWKS and applies RBAC with @GatekeeperProtected — without standing up an authorization server from scratch.
To go beyond tokens, read JWT, explained and social login in Java.
Conclusion
OAuth2 authorizes; OIDC authenticates. Most B2B and SaaS products need both. A platform that already delivers the right flows, multi-tenant isolation, and an SDK removes months of work and attack surface.