Introduction

In this article, we will explain the overview of Open ID Connect and briefly introduce its relationship with Okta. In the future, we will provide in-depth information on how to implement and utilize Open ID Connect for apps.

(The mention of OAuth in this article means OAuth 2.0.)

OAuth and Open ID Connect

I would like to start explaining Open ID Connect right away, but before that, I will touch on OAuth.

Open ID Connect is an extended specification of OAuth, so if you understand OAuth, it will be easier to understand Open ID Connect.

OAuth was originally established as a protocol for authorization, and Open ID Connect extended it so that it can be used for user authentication.

Authentication and Authorization

First, let's look at authentication and authorization. The difference between authentication and authorization is sometimes confused, but it's an important concept.

Authentication is the process of verifying whether the person claiming to be a certain individual is indeed that person.

Authorization, on the other hand, is access permission, which is the granting of access to the system by the owner of the system to an external application. In general, when you think of access permissions, you may imagine the scheme below, in which users are permitted to access the system (in the diagram below, access is permitted if they have a ticket).

In practice, in order to realize this mechanism, it is necessary to have an institution that issues tickets and a person who authorizes the issue of tickets. As shown in the red part in the figure below, if the "system data owner" is ① and the "person who accesses the system" is ②, ① will respond to the "ticket issuer" by saying "② can be issued.' ② receives the ticket from the "person issuing the ticket" and accesses the system.

Overall, ① allows access to the system to ②. This act of permission is "authorization" in OAuth.

In addition, since the information owned by ① is stored in the system, it means "permit ② to access the information of ①".

In an IT environment, ① is a human being, and everyone other than ① is an application.

Let's consider a concrete example.

Suppose Mr. A forgets something at home and asks Mr. B to come and pick it up for him. Mr. A asks the landlord, "Please give the key to my house to Mr. B." This is the approval (Mr. A approves for Mr. B).

In the first place, the landlord needs to confirm that Mr. A is the person himself, and there are many cases where authentication is also performed here.

Mr. A's house is the access destination system, and Mr. A allows only the person he trusts (Mr. B) to access his house.

How OAuth is used in a real IT environment

Now that we understand authentication and authorization, let's look at how OAuth is used in a real IT environment.

Why did the mechanism of OAuth appear?

For example, let's assume a scene in which Mr. A registers as a user for a certain web service.

Here, it is troublesome for Mr. A to register information such as his name and e-mail address, and it is even more so when there are multiple web services.

If Mr. A has an SNS account, it will be convenient to link the user information of the SNS service well.

Therefore, the API is executed from the web service to the SNS service to obtain Mr. A's user information. must be registered with the web service. There is a risk of ID/PW leakage from this web service, and when the PW is changed on the SNS side, it is necessary to change the PW registered on the web service side as well. These disadvantages increase as the number of web services used increases.

Therefore, the concept of OAuth is to use an access tone that can be used temporarily instead of ID/PW to execute APIs.

This is exactly the authorization structure introduced in the previous chapter. The access token plays the role of a ticket, and the institution that issues the access token is called the authorization server.

OAuth is a generalization of the access token issuance process, and the overall flow is shown below.

When Mr. A applies for access permission to the authorization server, it is desirable for the authorization server to verify Mr. A's identity, and inevitably it will also perform user authentication.

In fact, the server that stores user information often also serves as the authorization server.

Extensions to Open ID Connect

As in the previous chapter, OAuth often implements user authentication as well, so Open ID Connect is an extension with the main purpose of using this as a mechanism for user authentication as well.

The main differences between OAuth and Open ID Connect are:

The Open ID Connect flow is the same as OAuth.

As with OAuth, the server that stores user information often doubles as an authorization server, and ID tokens contain basic user information. In some cases, it is not necessary to execute the information acquisition API.

Features of Okta

In Open ID Connect, the organization that performs user authentication and authorization is important, and it is used for both business use and consumer use.

Okta has the roles of user information storage server and authorization server, and has four features.

• Okta Offers SDK for Open ID Connect
• Flexible authentication controls when authenticating users with Okta
• Flexible customization of information to be included in tokens
• Social login integration

Summary

We introduced the mechanism of Open ID Connect based on authentication, authorization, and OAuth.

Open ID Connect enables single sign-on for multiple web services while managing user authentication information (ID/PW, etc.) in one place. I hope you have understood that it is useful as an authorization mechanism.

Okta can maximize the value of Open ID Connect integration, including flexible authentication control functions. Please use all means.