In the previous article we did a hands-on exercise on Keycloak protecting Spring Boot applications. We showed you how powerful Keycloak is. But in order to master Keycloak you need to understand the OpenID Connect (OIDC) protocol. OIDC is an extension of OAuth 2.0. Why does it extend OAuth 2.0? Before we can figure this out we need to review the OAuth 2.0 protocol again.

OAuth 2.0

We’ve talked a lot about the OAuth 2.0 protocol before, but it’s still confusing to everyone. So today we will talk about OAuth 2.0 from a different perspective.

Why open authorization

If I have developed an Internet photo storage service, here called it XX Album Storage Service, after careful operation of the user volume has reached a certain size, this time will often enter a bottleneck, I want to further enhance the visibility of the brand. Another third-party photo printing platform also saw my unique advantages and wanted me to open up some functions for them to call. Stronger together, bigger and stronger! I think this is a good idea, it can also help me to attract users and expand my influence after using my open service. From the user’s point of view, it is very attractive to enjoy photo cloud storage and cloud printing service at the same time. So it is very cost-effective to open some functions to third parties.

Client authorization access

Although there are many benefits of open authorization, it can’t be without rules. User privacy protection and data security are very important. After careful deliberation, I have determined the following principles of openness.

  • Third parties need to open an account in my platform, so that it is convenient for me to manage and audit the third-party platform. Which third party is not compliant I will limit the flow or even block their qualifications.
  • Clarify the open interface categories and classify their rights. Used to meet different levels of third parties. Some third parties can only get user information; some third parties can call cloud printing.
  • Calling these services must seek consent from the actual owners of the photos (resource owners), which is a legal issue. Access to the user’s information and resources is only possible with the user’s consent.

So the third-party printing platform submitted an access request according to the rules I set, and after the review and approval I sent him a set of client credentials containing clientId and the corresponding secret, and explicitly informed the third party which features he could apply for, and then the third party could develop according to the API documentation.

Authorization process

The user logs in to the photo printing platform and finds that it also offers the ability to pull photos from the XX album storage service for printing. So he tried it out with great enthusiasm. The process is roughly as follows.

  1. User tells Printing Platform : I heard that you can pull my photos from XX Album Storage Service and print them, please give me a hand.
  2. Print Platform replies to User: No problem, but I need to tell XX Album Storage Service first. I’ll have to bring my own identifier clientId, and the permissions for the matter you’re requesting scopes. and the type of process to follow authorizationGrantType. For security reasons we’d better get a state random code to prevent man-in-the-middle attacks. The XX Album Storage Service will confirm with you through the dedicated redirectUri line I provide, so you can confirm it then.
  3. XX Album Storage Service confirms with User: Do you want to authorize XX Print Platform to pull your photos?
  4. User will need to provide XX Album Storage Service with their user credentials and confirm them if they confirm; otherwise, reject them and the process ends here.
  5. XX Album Storage Service replies to Printing Platform after receiving confirmation message from User: The user has confirmed and given you a temporary credential code ( authorizationGrantType=code ), you can exchange it for Token and then you can pull the user’s photos with it.
  6. The printing platform exchanges the Token and successfully pulls the user’s photo and prints it.
  7. The user can enjoy the cross-platform cloud printing service without going back and forth, and the user experience is improved.

Deficiencies of OAuth 2.0

The OAuth 2.0 protocol only addresses the issue of authorization, where a client can access a resource as long as it is authorized by the resource owner. OAuth 2.0 itself does not provide a specification for user authentication, OAuth 2.0 itself cannot prove that the resource owner is the correct resource owner . The user authentication involved in OAuth 2.0 is based on other authentication, and OAuth 2.0 only consumes the results of the authentication and is not involved in the authentication process. For this reason OpenID Connect was created. Its relationship with OAuth 2.0 is as follows.

interface OIDC extends OAuth2{
   boolean authentication ();

In other words, OIDC adds an authentication process for resource owners on top of OAuth 2.0 to achieve a real sense of authentication authorization. For the sake of space, I will learn the OIDC protocol with you in the next article.