Introduction
Hello, Iām Mapdu, a Ruby on Rails developer at Money Forward.
I work on Money Forward ID development team, developing a web application that serves as the ID and authentication platform for Money Forward and its group companies.
Recently, I have taken some time to dive deeper into Digital Identity. This summary captures what I have learned from reading the book “Learning Digital Identity” and relates it to OpenID Connect and OAuth 2.0. I hope it will be useful to anyone curious about these topics.
Background and Context
Before getting started with OAuth 2.0 and OpenID Connect, I want to understand their context and history.
What is Digital Identity?
From Wikipedia:
A digital identity is data stored on computer systems relating to an individual, organization, application, or device. For individuals, it involves the collection of personal data that is essential for facilitating automated access to digital services, confirming one’s identity on the internet, and allowing digital systems to manage interactions between different parties. It is a component of a person’s social identity in the digital realm, often referred to as their online identity.
As I understand it, digital identity is a set of attributes that identify a user or entity within the context of a function provided by a specific application.
Examples:
- Logging into Facebook: When logging into Facebook, you provide your email or phone number along with your password. These attributes authenticate you, allowing Facebook to recognize your account and grant you access.
- Entering a cinema with an online ticket: You purchase a movie ticket online and receive a QR code. When you arrive at the cinema, the ticket inspector scans the QR code to verify its validity, granting you entry if it is not expired or fake.
- Gaining entry to an office building: Employees use an access card to enter the building. The card, when scanned, verifies the employee’s identity and grants access to authorized areas within the building.
From User Passwords in Every App …
As you can see, the digital identity in the examples above is highly context-dependent, varying significantly based on the service provider and the intended audience.
- As a ticket inspector at a movie cinema, I only need to verify the movie tickets and ensure that the number of people matches the number of tickets they have.
However, I think that doesn’t matter. From a designer’s perspective, it is digital identity. Therefore, we can say that a user’s digital identity is a set of attributes that confirm and identify who the user is, granting access to the service’s resources.
So, what is the simplest way to achieve this?
Now, we often hear the phrase “username and password”. Therefore, I think it is considered the simplest method of authentication.
- The user agrees to a certain secret, and the next time they return, they provide this secret known only to them and the app. The app then responds, “Okay, I know who you are,” and the authentication is successful!
We are discussing a user and a specific application, which is quite simple and not very costly.
But now let’s expand the context a bit. For instance, if you are an employee at Money Forward, you will need to use various services for tax reporting, meeting, communication, etc.
Imagine that each application requires you to create and remember an account for each service. Every time you need to update your information, you must do it separately for each application. Moreover, whenever you leaves the company, the administrator must manually check and disable your accounts across all these different applications.
It raises a lot of operating costs and hassle. You don’t like that scenario, right?
… to Cross-Domain SSO
So the problem we need to solve now is how to use multiple applications with a single account? At this time, a new protocol called SAML (Security Assertion Markup Language) was developed.
Basically, this protocol describes a transaction where a user can sign in at one location and then demonstrate that login at another location to gain access.
To close this transaction, we need to introduce another concept: Trust.
This represents a relationship of mutual trust between the identity provider and the service provider. If either partner does not trust the other, the relationship will be broken.
For instance, before boarding the plane, security staff will check your passport and ticket information to decide whether to let you board.
- This shows that the airline service provider trusts the government that issued your passport.
- If you only present a piece of paper with your name on it, the security staff will not let you board, because they don’t trust it.
Basically, if the ID Provider says, “This user is one of mine and was successfully authenticated”, the resource will trust that information based on the previously established relationship between the ID Provider (IdP) and Service Provider (SP/RP).
I won’t go into too much detail, but SAML has indeed taken the lead and made federated identity world.
However, it failed to make the process simple and understandable, something that OAuth2.0 and OIDC have done well.
OAuth 2.0 and OpenID Connect
OAuth 2.0 and OpenID Connect (OIDC) are protocols that define how a server authenticates a user and grants access to resources.
- The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
- OIDC builds on OAuth 2.0 by adding user authentication and Single Sign-On (SSO) functionality, allowing you to retrieve and store authentication information about end users. It also defines several OAuth 2.0 scopes to enable apps to access user profile information.
The OAuth 2.0 Authorization Framework
Before diving into details, let’s consider the following example:
Imagine I’m a professional blogger on Twitter. I’ve written numerous articles and want to avoid posting them all at once to maximize interaction. Instead, I aim to post them at 9 AM every day.
I discovered a third-party app that allows me to pre-write posts and schedule them to be automatically posted on Twitter. It was great š
However, this third-party application requires me to provide my Twitter account and password.
- I write articles on this third-party application and schedule them to post on Twitter.
- Then, I provide my Twitter account and password information to the third-party application.
- The third-party application uses this information to log into Twitter and post on my behalf.
Do you see a problem with this scenario?
- First of all, giving login information to a third party is always a bad idea.
- Second, providing third-party application with your login information gives them too much control over your account.
OK, this is where OAuth 2.0 jumps into the game. Simply, it enables a third-party application to obtain limited access to an HTTP service within the scopes permitted by the resource owner (user).
- The third-party application cannot perform any actions beyond what the user has authorized with their account.
This completely solves the problem of giving too much power and account control to third-party apps, as seen in the previous example.
OAuth Roles
OAuth defines four roles:
- Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
- Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
- Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term “client” does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
- Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Refer: https://datatracker.ietf.org/doc/html/rfc6749#section-1.1
Protocol Flow
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps:
(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.
(B) The client receives an authorization grant, which is a credential representing the resource owner’s authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
(D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid, serves the request.
Refer: https://datatracker.ietf.org/doc/html/rfc6749#section-1.2
In this article, I will not dive into detailed specifications; you can find them here (The OAuth 2.0 Authorization Framework – RFC 6749).
The OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.
It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
First, let’s back to OAuth2.0 briefly. OAuth2.0 does not address login-related issues because it is designed for authorization purposes, focusing on the concept of the access_token
.
- According to the OAuth definition, an access_token is an opaque string with no intrinsic meaning that the Client (RP) can understand. The RP should not attempt to interpret it, as it is a confidential agreement between the authorization server and the resource server.
- Therefore, if an application possesses an access_token, it will not know to whom that access_token belongs unless it sends the token to the resource server and retrieves the associated user information. Despite this, some people have attempted to use OAuth 2.0 for login purposes by this way.
To resolve this issue, identity experts introduced OpenID Connect, which includes the concept of an ID Token in JWT format.
OpenID Connect allows you to request an additional token, called an id_token, along with the access token at the token endpoint in the OAuth 2.0 flow.
The ID token is designed to be consumed by the RP (or Client) itself rather than being used to access resources. Its characteristic is that it has a fixed format that the RP can parse and validate on its own.
- This means that the RP can verify and validate it in a manner similar to how web applications are secured through SAML. These properties enable proper login implementation using OIDC based on OAuth2.
Conclusion
The above provides a summary of the timeline and context regarding OAuth2.0 and OpenID Connect. I do not dive into detailed explanations of their characteristics and concepts here, but I hope it offers some useful information for you.
If time permits, I will cover these topics in detail in future articles.
References:
- The OAuth 2.0 Authorization Framework – RFC 6749
- The OpenID Connect Core
- Learning Digital Identity Book
Thank you!