OAuth and OpenID Connect Explained
May 10, 2020
If you are a mobile or web application developer, it's likely that at some point you needed to add authorization and authentication to your applications. OAuth and OpenID Connect are security standards addressing these needs. OAuth takes care of authorization, while OpenID Connect, or OIDC, deals with authentication. Some applications like Auth0 implement these two standards and make it easy to integrate into your projects. As a result, OAuth and OpenID Connect allow your users to securely login to your application using their existing credentials in other services such as Facebook or Gmail. One less username and password to remember!
Some of the terminology involved with the authorization/authentication flow can be confusing. So, it's helpful to follow an example through the process flow while defining these concepts.
Imagine that your application is a (very annoying) blogging platform. It allows blog readers to subscribe to blogs and have the platform send an email to all their contacts alerting them about new posts. Your blogging platform needs access to the subscriber's contacts and their email addresses to send them these notifications. Using her existing Gmail account, for example, a user can authorize your blogging platform to access her contacts without giving her password to your application. The first step in the process is to obtain authorization from your user.
OAuth
With OAuth 2.0 (the current version of OAuth), your application requests authorization from users to access data or actions in other applications on their behalf. Let's define some of the concepts involved.
Resource Owner
The resource owner is your application's user. She is the owner of her data and any actions that may be performed with her account.
Client
The client is the application that wants to access the Resource Owner's (user) data and/or perform actions on her behalf. In our example, your annoying blogging platform.
Authorization Server
This is the application were the Resource Owner has an account already (e.g. Gmail).
When the user is signing up for the blog post email notifications, your application asks her to login using an existing account in another service, in this case, she chooses Gmail. Your application redirects her to Gmail's sign-in page.
Redirect URI
The URL where the Authorization Server redirects the Resource Owner after granting permission to the Client.
This can be a confirmation page in your blogging platform confirming the user's subscription to the service.
Resource Server
The API or service that the Client wants to use on behalf of the Resource Owner. This could be the same as the Authorization Server.
For example, an API function provided by Gmail for your application to access the email addresses in a user's contact list.
Response Type
The type of information the Client expects to receive from the Authorization Server, usually an Authorization Code (defined below).
Scope
These are specific permissions that the Client wants, such as access to data or to perform actions.
An example is reading contact's email addresses or actions such as creating new contacts.
Consent
In the backstage, the Authorization Server takes the Scopes the Client is requesting and verifies with the Resource Owner if she grants permission.
After login, a message listing the specific data or actions that your application will be able to access is presented to the user. She has the option to allow or deny this request (i.e. give consent).
Client ID
An ID that is used to identify the Client with the Authorization Server.
Gmail gives your blogging platform application an ID for identification.
Client Secret
This is a password only the Client and the Authorization Server know. It allows them to privately share information.
Authorization Code
It's a short-lived code the Authorization Server sends back to the Client. The Client then privately sends the Authorization Code back to the Authorization Server, along with the Client Secret in exchange for an Access Token (see next term).
Access Token
A token or key that the Client will use after the above authorization process to communicate with the Resource Server.
Continuing with our example, your blogging platform will obtain an Access Token from Gmail's Authorization Server after the user grants authorization. Your application uses this Access Token to read the email addresses of your user's contacts in Gmail. With this information, your application is now able to send new post notifications to everyone!
OpenID Connect
The process described above (with OAuth) is exclusively for authorization, and it only grants applications access to data and/or actions. OpenID Connect is a layer on top of OAuth that adds authentication. In other words, it allows a Client to establish a login session as well as to gain information about the Resource Owner (the application's user). This information is called Identity. An Authentication Server that supports OpenID Connect is also called an Identity Provider. It provides information about the Resource Owner to the Clients. OpenID Connect can't work without authorization (OAuth).
OpenID Connect allows users to use one login across multiple applications. This is called federated Single Sign-On or SSO. E.g. a user can log in with Facebook or Gmail to another application using SSO. The OpenID Connect flow is the same as with OAuth, but the Authorization Server returns an ID Token along with the Access Token to the Client.
ID Token or JWT
An ID Token is a string in JSON format, also known as a JSON Web Token (JWT). When the Client receives a JWT from the Identity Provider, it can extract the information inside, such as name, login date and time, expiration of the token, and it is possible to check if the JWT has been manipulated. The data inside the JWT is called claims. Additionally, a Client can request the Authorization Server further information about the Resource Owner.
Conclusion
The OAuth and OpenID Connect standards provide authorization and authentication for mobile and web applications. Many applications such as Auth0 implement these standards and make it easy to integrate into our projects.
In addition, OAuth and OpenID Connect provide advantages for both users and application developers. Using jargon from the paper The Quest to Replace Passwords by Bonneau et. al., OpenID Connect is "scalable-to-users" because they can use a single password across as many applications as they want. For application developers, it makes it easy to integrate these security features without having to worry about managing user's passwords.