“OAuth 2.0 is a protocol to provide (an application/server) temporary access to a resource”
OAuth 2.0 is sometimes also known as a delegation /authorization protocol. In this scenario user already has access to Google contacts he/she is delegating his access to the server on the other hand user is authorizing the server to access the contacts on behalf.
Somewhere else in our applications permission to access Google Drive, Google sheets are some of the situations we come across. Behind the scenes, these applications are using OAuth 2.0 and Open ID Connect protocols. For an application, the Fig 01 shows that it needs to add more friends by importing contacts from Google contacts.
How does OAuth works here?
A URL is linked to the Invite friends from Contacts button while a user clicks the button he/she will be redirected to the URL. Here the URL is AUTH URL for Google. There are different AUTH URLs for Facebook, Twitter, etc. exist. Few parameters are too passed along with the URL. Few parameters along with the URL here:
Request Scope : contacts (Resource we need to access for)
Response type : code ( grant code to be shared with server)
Call back URL (Google provides it when you register)
Client Id (Called by Google after user clicks “allow”)
Once the user clicks he/she is redirected to a login page to choose an account if there are already signed accounts then the user will be allowed if it is a trusted account then while clicking allow button Google will redirect to the call back URL which we sent as a parameter and add a temporary grant as part of the URL. Once the UI has that code by GOOGLE it can share it with the server. Server can use the code to access the contact but there is a risk involved. The call back URL which is on UI. Therefore the code is not secure. One more step involved. Then the server needs to connect to AUTH Server to get the real access token. Once the server has the access token it can access the Resource Server.
During OAuth Flow the user has already selected the particular account or the user already signed in to a particular account. Can we use this process to get the user authenticated for a application? so in that case, we will tweak the flow a little bit so for our application.
Instead of the Invite friends button above here we have Sign-in with Google, we will use the same flow as before but once we receive the code on the server-side instead of using the code to get some access token to access the Google contacts here we will get the user profile. This flow which is on top of OAuth is called Open ID Connect. This provides us the ability to log-in using that AUTH provider. Here the difference is the parameter Request Scope is Open ID profile Email, not the contacts as above.
Request Scope: Open ID profile Email
Instead of an Access token what we get here is an access token and an ID Token which has all the details of the user profile. This ID token is JSON Web Token. This is a cryptographically signed token. This has user claims which allow the client to verify the identity of the user.
From the above discussion, you will get an idea that OAuth and Open ID Connect are similar but they are not identical. In OAuth 2.0 authorization code flow there is no validation done for user identity that’s why it is authorization protocol whereas in Open ID Connect flow application will verify the identity of a user by validating ID Token. Therefore it is an authentication protocol.
Why not just OAuth 2.0? Facebook does the same with OAuth, do not they?
OAuth itself has no notion of identity. Facebook extends OAuth for authentication by building an extension called Signed Request which is essentially the same as the Open ID Connect ID token.
I hope this helps you to get a basic idea of OAuth 2.0 and OpenID Connect.
References
