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.
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.
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.
Printing Platform: I heard that you can pull my photos from
XX Album Storage Serviceand print them, please give me a hand.
Print Platformreplies to
User: No problem, but I need to tell
XX Album Storage Servicefirst. 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
staterandom code to prevent man-in-the-middle attacks. The
XX Album Storage Servicewill confirm with you through the dedicated
redirectUriline I provide, so you can confirm it then.
XX Album Storage Serviceconfirms with
User: Do you want to authorize
XX Print Platformto pull your photos?
Userwill need to provide
XX Album Storage Servicewith their user credentials and confirm them if they confirm; otherwise, reject them and the process ends here.
XX Album Storage Servicereplies to
Printing Platformafter receiving confirmation message from
User: The user has confirmed and given you a temporary credential
authorizationGrantType=code), you can exchange it for
Tokenand then you can pull the user’s photos with it.
printing platformexchanges the
Tokenand successfully pulls the user’s photo and prints it.
- 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.
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.