Why OIDC Extends OAuth2: Secure Authentication with Keycloak Explained

This article explains how OpenID Connect (OIDC) builds on OAuth 2.0 to provide authentication, demonstrates a practical Keycloak integration with a Spring Boot app, and walks through a complete authorization flow for a photo‑storage service using client credentials and secure token exchange.

Programmer DD
Programmer DD
Programmer DD
Why OIDC Extends OAuth2: Secure Authentication with Keycloak Explained

In the previous article we demonstrated protecting a Spring Boot application with Keycloak, showcasing its power. To master Keycloak, we must first understand the OpenID Connect (OIDC) protocol, which is an extension of OAuth 2.0. Why does OAuth 2.0 need this extension?

OAuth 2.0

Earlier we discussed many aspects of the OAuth 2.0 protocol, yet many people remain confused. Today we will look at OAuth 2.0 from a different angle, as more and more services use it to open APIs.

Why Open Authorization

Imagine I have built an online photo‑storage service called XX Photo Album Service. After careful operation the user base grows to a scale where I hit a bottleneck and want to increase brand awareness. A third‑party photo‑printing platform sees my unique advantage and wants to access some of my functions.

Partnering with a third party is beneficial: they can drive users to my service while I gain exposure. From the user’s perspective, being able to store photos in the cloud and print them through a single workflow is highly attractive, making open APIs a win‑win.

Client Authorization Integration

While open authorization offers many benefits, it must follow rules to protect user privacy and data security. I have defined the following principles:

Third parties must create an account on my platform for management and auditing; non‑compliant parties can be throttled or blocked.

Define the categories of exposed APIs and classify permissions, e.g., some parties can only read user info, others can invoke cloud printing, facilitating tiered billing.

Access to a user’s resources must be granted with the resource owner’s explicit consent, addressing legal requirements.

After the printing platform submits an integration request and passes review, I provide it with a client credential set containing clientId and secret, and specify which functions it may call.

Authorization Flow

A user logs into the printing platform and discovers it can pull photos from XX Photo Album Service for printing. The high‑level process is as follows:

The User tells the Printing Platform: “I heard you can fetch my photos from XX Photo Album Service for printing, please do it.”

The Printing Platform replies to the User: “Sure, but I need to contact XX Photo Album Service with my clientId, requested scopes, and authorizationGrantType. I’ll also include a random state to prevent MITM attacks. XX Photo Album Service will redirect to the redirectUri you provided for confirmation.” XX Photo Album Service asks the User: “Do you authorize XX Printing Platform to pull your photos?”

If the User agrees, they provide their credentials to XX Photo Album Service; otherwise the flow ends. XX Photo Album Service receives the user’s confirmation and returns a temporary code (with authorizationGrantType=code) to the Printing Platform.

The Printing Platform exchanges the code for a Token and uses it to fetch the user’s photos.

The Printing Platform successfully retrieves and prints the photos.

The user enjoys cross‑platform cloud printing without extra steps, improving the overall experience.

Background of OIDC

OAuth 2.0 only solves the authorization problem: a client can access a resource once it obtains the resource owner’s consent. OAuth 2.0 itself does not define a standard for user authentication.

Consequently, OAuth 2.0 cannot prove that the resource owner is truly the legitimate owner, and any authentication it relies on depends on external mechanisms. OAuth 2.0 merely consumes authentication results without participating in the authentication process.

Because of this limitation, OpenID Connect (OIDC) was created. OIDC builds on OAuth 2.0 and adds a verification step for the resource owner, achieving true authentication‑authorization.

interface OIDC extends OAuth2{
   boolean authentication()
}

In other words, OIDC extends OAuth 2.0 with an authentication flow for the resource owner, delivering genuine authentication‑authorization. I will continue exploring the OIDC protocol in future articles. Feel free to leave comments with any questions.

securityAuthenticationOAuth2Authorizationopenid-connectKeycloak
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.