OAuth is a protocol used to authorize a client application’s access to some resource. In the past applications may have used basic authentication such as a user name, password combination or single sign on protocols such as SAML.
So let’s see how OAuth works by using the example of accessing your Google account which we will term a resource.
Let’s say you as a user are the resource owner of your Google account. Now there’s a web client application which wants to access some of the info stored in your Google account. Using OAuth you might send a request like so:
In effect you are sending the Google Authorization server your user id, a redirect URI which the Authorization server can call back, the response type you need which in this case is an authorization code and the scope of access that the user application needs which here is access to your contacts.
Remember that for OAuth to work you also need to create a client id and client secret which the Google Authorization server can use.
So once you have logged in with your credentials and Google has signed you in it asks you whether it should grant access to your contacts to the client application.
Assuming you clicked “Yes” Google now sends an authorization code back to your web application and redirects the user to the page specified in the redirect_uri. All this happens in the context of the browser and is termed as front channel flow.
authorization_code = 6789abcd
Remember the authorization code is publicly visible in the response sent by the Google Authorization server and can be seen in the browser address bar as well. However this doesn’t matter since just the authorization code does not ensure any access.
In the next step the web application’s server now uses the authorization code and the client secret and sends a POST request to the Google Authorization server. Thus it’s the unique combination of both the code and the client secret which ensures that no other application can pretent to be you and talk to the Google Authentication server.
So the request would be something like :
The response to this request is an access token which grants the client application the requested access. In other words the client application has been authorized to access the resource it requested in this case your contacts.
access_token = 4563ghjk
Once the access token has been received by the client application it then uses it to access the resource that it requested. The resource server ofcourse checks to see if the client application is accessing what it is actually authorized to access.
So something like
And that’s it. That’s how OAuth works.
Note that an access token only contains info about which user has been authorized to access what resource. It should not specify any info about the user.
Over the years OAuth was hacked to also provide authentication which it was not designed to support. So multiple implementations cropped up from Google, Facebook and the like to misuse the access token to also provide info about the user who requested the access.
To bring in some form of standardization and to separate authentication from authorization Open ID Connect was written on top of OAuth.
With OpenID the client application sends out “openid” as an additional scope parameter when it initially sends a request. In addition to an access token, an OpenID Authorization server will also send out a user token which contains info about the user. This information can be used immediately by the server application to access some info about the user. The user token is usually a JSON Web Token.
Additional information about the user can also be obtained by sending out a request to a user info endpoint and supplying the user token.
So in short an Open ID server will provide a user token, a user info endpoint, a standard set of scopes and standardized implementation.
So there it is. Do not mixup OAuth with OpenID. Open ID handles authentication and OAuth handles authorization.