🥇An Illustrated Guide to OAuth and OpenID Connect

Note. transl.: This great article by Okta explains how OAuth and OIDC (OpenID Connect) work in a simple and clear way. This knowledge will be useful to developers, system administrators, and even "regular users" of popular web applications, which most likely also exchange confidential data with other services.

In the Stone Age of the Internet, sharing information between services was easy. You simply gave your login and password from one service to another, so that he entered your account and received any information he needed.

"Give me your bank account." “We promise that everything will be fine with the password and money. That's honest, honest!" *hee hee*

Horror! No one should ever require a user to share a username and password, credentials, with another service. There is no guarantee that the organization behind this service will keep the data secure and will not collect more personal information than necessary. It may sound crazy, but some apps still use this practice!

Today there is a single standard that allows one service to securely use the data of another. Unfortunately, such standards use a lot of jargon and terms, which complicates their understanding. The purpose of this material is to explain how they work using simple illustrations (Do you think that my drawings resemble children's daubing? Oh well!).

By the way, this guide is also available in video format:

Ladies and gentlemen, welcome: OAuth 2.0

OAuth 2.0 is a security standard that allows one application to gain permission to access information in another application. Sequence of steps for issuing a permit [permission] (or consent [consent]) often call authorization [authorization] or delegated authorization [delegated authorization]. With this standard, you allow an application to read data or use the functions of another application on your behalf without giving it your password. Class!

As an example, let's say you discover a site called "Unlucky Pun of the Day" [Terrible Pun of the Day] and decided to register on it in order to receive daily puns in the form of text messages on the phone. You really liked the site, and you decided to share it with all your friends. After all, everyone likes creepy puns, right?

“Unfortunate pun of the day: Heard about the guy who lost the left half of his body? Now he is always right!” (approximate translation, because the original has its own pun - approx. transl.)

It is clear that writing to each person from the contact list is not an option. And, if you are even a little bit like me, then you will go to any lengths to avoid unnecessary work. Fortunately, Terrible Pun of the Day can invite all your friends by itself! To do this, you just need to open access to your contacts' email - the site itself will send them invitations (OAuth rules)!

“Everyone loves puns! - Already logged in? “Would you like to allow the Terrible Pun of the Day website to access your contact list? - Thank you! From now on, we will send reminders every day to everyone you know, until the end of time! You are the best friend!"

Choose your email service.
If necessary, go to the mail site and sign in to your account.
Give Terrible Pun of the Day permission to access your contacts.
Return to the Terrible Pun of the Day site.

In case you change your mind, applications using OAuth also provide a way to revoke access. Once you decide that you no longer wish to share contacts with Terrible Pun of the Day, you can go to the mail site and remove the pun site from the list of authorized applications.

OAuth Flow

We have just gone through what is usually called stream [flow] OAuth. In our example, this flow consists of visible steps, as well as several invisible steps, in which two services agree on a secure exchange of information. The previous Terrible Pun of the Day example uses the most common OAuth 2.0 flow, known as the "authorization code" flow. ["authorization code" flow].

Before diving into the details of how OAuth works, let's talk about the meaning of some terms:

Resource Owner:

It is you! You own your credentials, your data, and control all activities that may be performed on your accounts.
Client:

An application (for example, the Terrible Pun of the Day service) that wants to access or perform certain actions on behalf of Resource Owner'a.
Authorization Server:

The app that knows Resource Owner'a and in which u Resource Owner'a already have an account.
resource server:

Application programming interface (API) or service that Client wants to use on behalf Resource Owner'a.
Redirect URI:

The link that Authorization Server will redirect Resource Owner'and after granting permission Client'at. It is sometimes referred to as the "Callback URL".
response type:

The type of information expected to be received Client. The most common response type'ohm is the code, that is Client expects to receive Authorization code.
Scope:

This is a detailed description of the permissions that are required Client'y, such as accessing data or performing certain actions.
CONSENT:

Authorization Server beret Scopesrequested Client'om, and asks Resource Owner'a, is he ready to provide Client'have the appropriate permissions.
customer ID:

This ID is used to identify Client'a on Authorization Server'e.
Client Secret:

This is the password that is only known Client'u and Authorization Server'at. It allows them to share information privately.
Authorization code:

Temporary code with a short period of validity, which Client provides Authorization Server'y in exchange for Access Token.
Access Token:

The key that the client will use to communicate with resource server'om. A sort of badge or key card that provides Client'have permission to request data or perform actions on resource server'e on your behalf.

Note: Sometimes Authorization Server and Resource Server are the same server. However, in some cases, these may be different servers, even if they do not belong to the same organization. For example, the Authorization Server might be a third party service trusted by the Resource Server.

Now that we've covered the core concepts of OAuth 2.0, let's go back to our example and take a closer look at what happens in the OAuth flow.

You, Resource Owner, you want to provide the Terrible Pun of the Day service (Clienty) access to your contacts so that they can send invitations to all your friends.
Client redirects the browser to the page Authorization Server'a and include in query customer ID, Redirect URI, response type and one or more Scopes (permissions) it needs.
Authorization Server verifies you, asking for a username and password if necessary.
Authorization Server displays a form CONSENT (confirmations) with a list of all Scopesrequested Client'om. You agree or refuse.
Authorization Server redirects you to the site Client'a, using Redirect URI with Authorization code (authorization code).
Client communicates directly with Authorization Server'ohm (bypassing the browser Resource Owner'a) and safely sends customer ID, Client Secret и Authorization code.
Authorization Server checks the data and responds with Access Token'om (access token).
Now Client can use Access Token to send a request to resource server to get a list of contacts.

Client ID and Secret

Long before you allowed Terrible Pun of the Day to access your contacts, the Client and Authorization Server had established a working relationship. The Authorization Server generated the Client ID and Client Secret (sometimes called App ID и Secret App) and sent them to the Client for further interaction within OAuth.

"- Hello! I would like to work with you! - Sure, not a problem! Here are your Client ID and Secret!”

The name implies that the Client Secret must be kept secret so that only the Client and Authorization Server know it. After all, it is with his help that the Authorization Server confirms the truth of the Client.

But that's not all... Please welcome OpenID Connect!

OAuth 2.0 is only designed for authorization - to provide access to data and functions from one application to another. Open ID Connect (OIDC) is a thin layer on top of OAuth 2.0 that adds the login and profile details of the user who is signed into the account. The organization of a login session is often referred to as authentication [authentication], and information about the user logged into the system (i.e. about Resource Owner'e), — personal data [identity]. If the Authorization Server supports OIDC, it is sometimes referred to as provider of personal data [identity provider]because it provides Client'have information about Resource Owner'e.

OpenID Connect allows you to implement scenarios where a single login can be used in multiple applications - this approach is also known as single sign on (SSO). For example, an application may support SSO integration with social networks such as Facebook or Twitter, allowing users to use an account they already have and prefer to use.

The flow (flow) OpenID Connect looks the same as in the case of OAuth. The only difference is that in the primary request, the specific scope used is openid, - A Client eventually gets like Access TokenAnd ID Token.

Just like in the OAuth flow, Access Token in OpenID Connect, this is some value that is not clear Client'at. From point of view Client'a Access Token represents a string of characters that is passed along with each request to resource server'y, which determines if the token is valid. ID Token represents a completely different thing.

ID Token is a JWT

ID Token is a specially formatted string of characters known as JSON Web Token or JWT (sometimes JWT tokens are pronounced like "jots"). To outside observers, JWT may seem like incomprehensible gibberish, but Client can extract various information from the JWT, such as ID, username, login time, expiration date ID Token'a, the presence of attempts to interfere with the JWT. Data inside ID Token'a are called applications [claims].

In the case of OIDC, there is also a standard way by which Client may request additional information about the individual [identity] from Authorization Server'a, for example, an email address using Access Token.

Learn more about OAuth and OIDC

So, we briefly reviewed how OAuth and OIDC work. Ready to dig deeper? Here are additional resources to help you learn more about OAuth 2.0 and OpenID Connect:

As always, feel free to comment. To keep up to date with our latest news, subscribe to Twitter и YouTube Okta for developers!

An Illustrated Guide to OAuth and OpenID Connect