In the previous post, we explored OAuth 2.0, a framework for delegated authorization. But OAuth alone doesn’t tell you who the user is — only that access was granted. That’s where OpenID Connect (OIDC) comes in.
Note: This article belongs to Part 2.2: Security Standards in our Application Security series.
OIDC builds on OAuth 2.0 to provide authentication and user identity, enabling modern federated login (think “Login with Google”) and single sign-on (SSO) patterns — all using standard web-based flows and tokens.
In this post, we’ll unpack how OpenID Connect works, how it differs from OAuth 2.0, and how to implement it with Spring Security.
Why OAuth Alone Isn’t Enough
OAuth 2.0 was never designed for user login. It was built to grant scoped access to protected resources — not to provide user identity. For example:
OAuth can tell an app:
✅ “You have permission to access this user’s calendar.”
But it doesn’t tell you who the user is.
That’s a problem if your app needs to:
- Display a user’s name or email
- Create or match a user record in your DB
- Enforce role-based access based on identity
That’s where OpenID Connect steps in — by layering authentication on top of OAuth.
What Is OpenID Connect?
OpenID Connect (OIDC) is an authentication standard built on top of OAuth 2.0. It adds a new token — the ID Token — which contains information about the user (also called “claims”).
With OIDC, your app can:
- Authenticate users via a trusted identity provider (IdP)
- Access their profile info securely
- Avoid handling passwords directly
It’s the foundation of:
- “Login with Google/Facebook/etc.”
- Enterprise SSO integrations (via OIDC or SAML)
- Social login in mobile apps and SPAs
Key Components in OIDC
| Concept | Description |
|---|---|
| ID Token | JWT that contains user identity claims (name, email, etc.) |
| UserInfo Endpoint | Optional endpoint for retrieving extended profile info |
| Discovery Document | JSON metadata about the IdP’s endpoints, keys, and capabilities |
| Scopes | OIDC defines openid (mandatory), plus optional profile, email, etc. |
| Claims | Identity data in the ID token (sub, name, email, etc.) |
OIDC vs OAuth 2.0
| Feature | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Purpose | Authorization | Authentication + Authorization |
| Token Types | Access Token, Refresh Token | Adds ID Token |
| Identity Support | ❌ No user identity info | ✅ User info via ID Token |
| Standard Scopes | Defined by APIs | openid, profile, email, etc. |
| Use Case | Accessing APIs on user’s behalf | Logging users in securely |
🔐 Spring Security + OpenID Connect (OAuth2 Login)
Spring Security provides built-in support for OIDC login with just a few lines of configuration.
Here’s how to configure a Spring Boot app to use OIDC for login:
# application.yml
spring:
security:
oauth2:
client:
registration:
google:
client-id: YOUR_CLIENT_ID
client-secret: YOUR_SECRET
scope: openid, profile, email
provider:
google:
issuer-uri: https://accounts.google.com
@Configuration
@EnableWebSecurity
public class OidcLoginConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.oauth2Login() // Enables OIDC login
.and()
.authorizeHttpRequests(auth -> auth
.anyRequest().authenticated()
);
return http.build();
}
}
✅ This will:
- Handle redirects to the IdP
- Fetch the ID Token and Access Token
- Populate
SecurityContextwith user identity from the ID Token
Accessing User Identity from the ID Token
Spring automatically parses the ID Token into a OidcUser object:
@GetMapping("/me")
public String getUserInfo(@AuthenticationPrincipal OidcUser oidcUser) {
return "Hello, " + oidcUser.getFullName();
}
You can also access claims like email, sub, and groups directly:
String email = oidcUser.getEmail();
String subject = oidcUser.getSubject(); // unique user ID
Best Practices for OIDC
- Always verify the
iss(issuer) andaud(audience) in the ID Token - Validate the signature and expiration of the ID Token
- Use HTTPS everywhere
- Prefer short-lived access tokens + refresh tokens
- For SPA or mobile apps, use Authorization Code Flow with PKCE
Common Pitfalls to Avoid
- ❌ Using the ID Token to call APIs (use the Access Token for that)
- ❌ Assuming
subis an email — it’s a stable, opaque identifier - ❌ Storing ID Tokens insecurely on the client
- ❌ Mixing OAuth and OIDC flows without clear separation
Use Cases for OIDC
| Scenario | Why OIDC Fits |
|---|---|
| Federated login (Google, GitHub) | Users log in without creating new passwords |
| SSO in enterprise apps | One login across multiple internal systems |
| Mobile app auth via browser | Avoids embedded credentials — works with PKCE + OIDC |
| User onboarding flows | Pull verified name/email from ID Token |
Conclusion
OpenID Connect fills the gap that OAuth 2.0 leaves open: user identity. It enables secure, standards-based login for any app — from a simple web UI to complex enterprise SSO systems.
By using OIDC with Spring Security, you get:
- Standards-compliant login flow
- Simplified identity extraction
- Secure, scalable authentication infrastructure
If OAuth is the gatekeeper, OpenID Connect is the identity badge that confirms who the person walking through actually is.
Check out https://docs.spring.io/spring-security/reference/5.8/servlet/authentication/openid.html and https://en.wikipedia.org/wiki/OpenID Wikipedia links for more information on the current topic.
What’s Next
Up Next in our Application Security Series is:
Part 2.3 👉 SAML Demystified: Enterprise SSO Made Simple to Understand
We’ll demystify SAML — another security standard still widely used in enterprise SSO systems and compare it with OIDC and explore where each makes sense in real-world architecture.
Have a Question?
OIDC can seem like magic at first — but under the hood, it’s just signed tokens and trust between systems. If you’re working through an OIDC login or integrating Spring Security with an IdP, feel free to reach out or share your challenges in the comments.
