• Authorization and Authentication For Everyone
  • By Kim Maida
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Ashira97
  • Proofread with: PassionPenguin

Everyone can understand authorized access and authentication

Many of the applications we develop require authentication and authorized access. Perhaps you’ve already developed an application that does both by introducing a third-party library or using an authentication platform.

Even if you’ve done all the work, you don’t really know what’s going on behind the scenes of a sequence of actions or why a function is implemented the way it is. Read on if you want a deeper, more basic understanding of OAuth 2.0 and the OpenID connection specification

Identification is very difficult. Why do you say so? Although authentication standards are well defined, they can be challenging to use correctly. Well, we’re going to learn the whole process in a way that’s easy to understand. We will learn the concept of certification step by step and build our knowledge as we go further. By the time we’re done, you should have some foundation and know which bits of knowledge you’d like to dig deeper into.

This article should be read from beginning to end. Because we’ll start from the beginning of each concept down to the principle level, and then introduce new topics when appropriate. Remember what I said here if you want to skip something in the article

The preface

When I tell my family and friends “MY job is identification related,” they usually assume that I’m employed by a government agency that issues driver’s licenses or helps people solve credit-card fraud.

However, neither. I previously worked for Auth0, a company that manages digital certificates. I am now part of the Auth0 Ambassador program and a Google development expert in the SPPI (Security, Privacy, Payments, Authentication) direction.

Digital identity

Digital identity refers to a set of attributes that define an individual user’s identity within a method of a particular application.

What does that mean?

Let’s say you’re running an online shoe retailer. A user’s digital identity could be their credit card number, shipping address, or purchase history. The exact content of their digital certificates depends on your application.

Which brings us to identity.

The identity authentication

Broadly speaking, authentication refers to the process of verifying that users are who they say they are.

Once a system can implement authentication, we need to consider how to implement authorized access for it.

Authorized to access

Authorized Access Deals with the issue of whether to allow access to a resource.

standard

As you recall, I mentioned above that certification has a well-defined set of criteria. But where do these standards come from in the first place?

There are many different standards and organizations that govern the way things work on the Internet. Two organizations are of particular interest to us when discussing authentication and authorized access: the Internet Engineering Task Force (IETF) and the OpenID Foundation (OIDF).

IETF (Internet Engineering Task Force)

The Internet Engineering Task Force is a large, open international organization of web service designers, operators, suppliers, and researchers. These people pay close attention to the evolution of the Internet architecture and want to ensure that web services are used smoothly.

Seriously, it’s great to have dedicated experts collaborating on technical documentation to guide us in implementing functionality in a way that complies with the rules of the Internet.

OIDF (OpenID Foundation)

OIDF is a non-profit international organization. It consists of individuals and companies dedicated to implementing, optimizing, and maintaining OpenID technology.

Now that we know something about these specifications and their authors, let’s return to the concept of authorized access:

The 2.0

When we talk about Web specifications, OAuth 2.0 is one of the most mentioned Web specifications, and one of the most misunderstood. Why?

OAuth is not an authentication specification; it deals with delegated access. Keep in mind that authentication here refers to confirming a user’s identity, and authorized access refers to granting or denying access to a resource. OAuth 2.0 grants permissions to applications on behalf of users. (Don’t worry, we’ll get to the authentication part later.)

Before OAuth came along

To understand OAuth’s purpose, we need to look at its history. OAuth 1.0 was released in December 2007. Previously, if we needed to access a third-party resource, the following would happen:

Let’s say you’re using an app called HireMe123. HireMe123 wants to set up a calendar event (such as a job interview appointment) on your behalf. But HireMe123 doesn’t have its own calendar, so it uses another service called MyCalApp to add calendar events.

Once you’re logged in to HireMe123, it will request your login credentials for MyCalApp. You have to enter your MyCalApp username and password on the HireMe123 site.

HireMe123 will then be able to use your MyCalApp account login to access the MyCalApp API and create calendar events with your login credentials.

Sharing credentials is a bad thing!

This approach relies on sharing user credentials between two different applications, which is not a good approach. Why?

In one respect, HireMe123 has far less responsibility for protecting MyCalApp login information. If HireMe123 had not provided proper protection for MyCalApp’s credentials, they might have been stolen, and some people might have written nasty blog posts about the theft, but HireMe123 would not have faced the same accusations as MyCalApp.

HireMe123 also had too much access to MyCalApp. Because they use your certificate to get those permissions, it basically has the same access as you. That means HireMe123 can read all of your calendar events, delete them, or modify your calendar Settings.

OAuth protocol was born

OAuth protocol came into being in this situation.

OAuth 2.0 is an open standard for enabling authorized access. As an instruction manual, it can guide us on how to grant third-party applications access to certain apis without exposing personal certificates.

Using the OAuth protocol, users can now delegate HireMe123 to access MyCalApp on their behalf. MyCalApp can control third-party access to the API without the risk of sharing login information or providing too much access. It works like this:

Authorized access server

An authorization server is a set of endpoints that interact with users and issue tokens. How does that help?

Let’s revisit the example of HireMe123 and MyCalApp using OAuth 2.0:

MyCalApp now has an authorized access server. We assume that HireMe123 is already logged into MyCalApp as a known third-party application, which means that MyCalApp’s authorized access server thinks HireMe123 has access to the API.

We also assume that you are logged in to HireMe123 through whatever method of authentication you use. Now HireMe123 wants to create an event on your behalf.

HireMe123 sends an authorization access request to MyCalApp’s authorization access server. In response, MyCalApp’s authorized access server allows the user to log in (if you haven’t already). At this point, you will have access to MyCalApp.

MyCalApp’s authorization server then prompts you to agree to allow HireMe123 to access MyCalApp’s API on your behalf. This prompt pops up in the browser and asks for your permission to allow HireMe123 to add calendar events (but no more).

If you agree and click OK, MyCalApp’s authorization server will then send an authorization code to HireMe123. This action lets HireMe123 know that the user of MyCalApp has indeed consented to it using MyCalApp on behalf of the user to add a calendar event.

MyCalApp then sends an access token to HireMe123. HireMe123 then uses the access token to invoke the MyCalApp API within your agreed permissions and use the API to create an event.

There is nothing to hide here! MyCalApp is asking users to log in to MyCalApp. HireMe123 did not request the user’s MyCalApp credentials. Shared certificates and excessive access are no longer a problem.

What is identity authentication?

Here, I hope that the fact that OAuth is an authorized access protocol is clear enough that it does not include authentication. No authentication is involved in any of these processes, and login is controlled by HireMe123 or a different login process on MyCalApp. OAuth 2.0 does not specify how this behavior should be done, it is only responsible for granting third parties access to the API.

So why are authentication and OAuth often mentioned together?

The login problem

After OAuth 2.0 establishes a way for third-party services to access the API, the next issue is that applications want users to be able to log in using accounts from other applications. Again, let’s say HireMe123 wants a user of MyCalApp to be able to log in to HireMe123 using his MyCalApp account, even if the user doesn’t already have one.

However, as we mentioned above, OAuth 2.0 is responsible for granting access, it is not an authentication protocol. But that doesn’t stop people from trying to treat two concepts as one, and that process creates problems.

Problems with using access tokens for authentication

Assuming that HireMe123’s successful invocation of MyCalApp’s API using an access token means that the current user is authenticated through HireMe123, we have a problem: we cannot be sure that the current access token belongs to a particular user.

Such as:

  • Someone may steal access tokens from others
  • The access token may have come from a third party other than HireMe123, and then injected into HireMe123

This is called a Confused Deputy Problem. HireMe123 does not know where the token came from or to whom it was issued. If we remember the original definition: authentication is about confirming that the user is who he says he is, then HireMe123 cannot get that information from accessing the API using that access token.

As we mentioned, this fact has not stopped people from continuing to misuse access tokens and OAuth 2.0 for authentication. It will soon become clear that we must build authentication protocols on top of OAuth 2.0 in order to ensure application and user security while allowing login using third-party applications.

OpenID connection

The next specification we’ll look at is called OpenID Connectivity, also known as OIDC. OIDC is a specification based on OAuth 2.0, which specifies how to authenticate users. The OpenID Foundation (OIDF) is the administrator of the OIDC standard.

OIDC is an authentication mechanism that uses an authentication server to authenticate user identities. Remember, authentication servers issue tokens, which are encrypted data used to pass information between entities (such as authorization servers, applications, or resource apis). In the case of identity authentication using OIDC, the authorization server issues the ID token.

ID tokens

The ID token provides information about authentication and identifies the user. ID tokens are used by third-party services. These tokens have a fixed format that a third party can parse and extract user identity information from the token, thereby authenticating the user.

OIDC declares a fixed format ID token as follows:

JSON Web Token (JWT)

JSON Web Tokens, or JWT (sometimes spelled “joT”) consists of three string Tokens that can be used in urls. Connected together.

The head piece

The first paragraph is the header, which might look something like this:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

The header segment is a JSON object containing the signature algorithm and token type, encoded in base64URL (byte data is represented in a form that can be legally used in urls and file names)

After decoding, it looks like the following:

{
  "alg": "RS256",
  "typ": "JWT"
}

Copy the code
Load segment

The second segment is the payload segment. It looks something like this:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

This is a JSON object containing data declarations that declare fields about user and authentication events, such as:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Copy the code

Base64Url encoding is also used.

Encryption section

The last segment is called an encryption segment, or signature. JWT are signed, so you cannot tamper with them in transit. When the authorization server issues the token, it uses the key to encrypt the token.

When a third party receives an ID token, the third party also uses the key to verify the signature. (If asymmetric encryption algorithms are used, different keys are used for signature and verification, and if so, only the authorization server can encrypt the token.)

If you’re confused, don’t worry. The details of the above work should not confuse you or prevent you from using token-based authorization servers effectively for authentication. If you are interested in these concepts, terminology, and the details behind JWT, please refer to my articleJWT signature and validation that everyone can understand

field

Now that we know the components of JWT, we are going to look at fields. Fields are a series of declarations carried in the payload section. As their name suggests, ID tokens provide authentication information in the field.

Identity field

We’ll start with the authentication fields. Here are a few examples of such fields:

{you} {" iss ":" https://, authz-server.com, "and" aud ":" RxHBtq2HL6biPljKRLNByqehlKhN1nCx ", "exp" : 1570019636365, the college "iat" : 1570016110289, 
 "nonce": "3yAjXLPq8EPP0S",... }Copy the code

It declares some fields that must be included in authentication and includes an ID token:

  • iss (Issuer): The publisher of the JWT, such as the authorized access server.
  • aud (Receiver): Target recipient of JWT; For ID tokens, this field must be the ID of the application receiving the token.
  • exp (Expiration time): Expiration time; The ID token is no longer valid after this time.
  • iat (Release time): The time when the ID token is issued.

A nonce field binds the authorization request from a third party to the token it receives. A nonce is an encrypted random string created by the client and sent along with the authorization request. The authorization server then places the Nonce in the token returned to the application. The application checks whether the Nonce in the token is the same as it is carried in the authorization request. If the same, the application can confirm that the token is from the authorization server originally specified.

Id field

The field also contains a description of the end user. Here are a few examples:

{ "sub": "google-oauth2|102582972157289381734", "name": "Kim Maida", "picture": "https://gravatar[...] ", "twitter": "https://twitter.com/KimMaida", "email": "[email protected]", ... }Copy the code

The standard description in an ID token includes the following fields:

  • sub** (theme) **: unique identifier for the user; mandatory
  • email
  • email_verified
  • birthdate
  • And so on…

Now that we’ve quickly learned the important specifications (OAuth 2.0 and OpenID Connect), it’s time to see how we can put what we’ve learned into practice.

Authentication using the ID token

Let’s see how OIDC identity authentication works in practice.

Note that this is a simplified description. Depending on the architecture of your application, there are several differences.

The entities we’re talking about here are: a browser, an application that runs on the browser, and an authorization server. When a user wants to log in, the application sends an authorization request to the authorization server. The authorization server detects the user’s credentials and, if verified, issues an ID token to the application.

The client application decodes the ID token (which is a JWT) and validates it. This process involves validation, and we must validate fields. Some examples of validation fields are as follows:

  • issuer (iss) : Is the current token issued by a specific authorization server?
  • audience (aud) : Is our application the designated recipient of this token?
  • expiration (exp) : Is this token within the available time period?
  • nonce (nonce) : Does this token match the authorization request our application created?

Once we verify the authenticity of the ID token, the user is authenticated. We also get the identity statement and we know who the user is, right?

Now that the user is real, we can interact with the API.

Use the access token to access the API

We talked a little bit about access tokens earlier, and at that point we looked at how OAuth 2.0 and authorization servers authorize access to work. Let’s take a look at the details of how they work, returning to our scene from HireMe123 and MyCalApp.

The access token

Access tokens are used to authorize access to a resource. Using an access token issued by MyCalApp’s authorization server, HireMe123 had access to MyCalApp’s API.

Unlike ID Tokens, which declare OIDC as JSON Web Tokens, access Tokens have no clear, fixed format. They don’t have to be, or need to be, limited to the JWT format. However, the JWT format is used in many authentication solutions to access tokens because it facilitates validation.

The client has difficulty understanding the access token

Access tokens are primarily used for resource API calls and, importantly, they are opaque to the client. Why is that?

The access token changes over time. They should have a short expiration time, so a user might often get new tokens. They can also be reissued to access different apis or request different licenses. Third-party applications should not contain anything that depends on access tokens. Because that code is fragile, and it almost certainly has bugs.

Accessing resource APIS

Suppose we now wanted to invoke the API from a single page application using an access token?

W We have discussed authentication above, assuming that the user is now logged in to our JS application through a browser. The application sends an authorization request to the authorization server to invoke an API’s access token.

Later, when our application wants to interact with the API, we add the access token to the request header like this:

# HTTP request headers Authorization: 'Bearer eyj[...] 'Copy the code

This authorized request is then sent to the API, where third-party middleware is used to validate the token. If this validates, the API returns the data to the application in the browser.

That’s great, but there could be problems. Earlier we said that OAuth solves the problem of too much access. So how is this problem solved?

Scoped authorization

How does the API know what level of permission it should give to the application making the access request? We introduce a concept here called scope.

A scope “limits what an application can do on behalf of the user.” During authorization, do not assign permissions that do not exist to users. For example, if the user of MyCalApp does not have permission to create a business account, the scope granted to HireMe123 naturally does not allow the user to create a business account.

Scope grants access to an API or resource. This API is then responsible for combining the incoming scope with the actual user permissions to ensure that appropriate access control decisions are made.

Let’s continue with this example.

I am using HireMe123 and HireMe123 wants to access the API of the third-party program MyCalApp to create an event on my behalf. HireMe123 has requested an access token from the authorization server from MyCalApp. This token contains some important information, such as:

  • sub(My MyCalApp user ID)
  • aud:MyCalAppAPI(The audience field indicates that this token is the API used to access MyCalApp)
  • scope:write:events(Scope description HireMe123 has permission to use the API to write events in the calendar)

HireMe123 sends a request to MyCalApp’s API that includes access to the token in the authorization header. When MyCalApp’s API receives this request, it knows that the token contains a scope such as Write: Events.

But MyCalApp manages calendar events for hundreds of users. In addition to looking at the scope in the token, MyCalApp’s API also needs to check the sub field identifier to make sure that the request from HireMe123 is only able to create events on my account using the permissions I already have.

In the context of authorized access, a scope expresses what an application can do on behalf of the user. It is a subset of all user permissions.

licensing

Remember when the authorization server asked HireMe123’s users for their consent to allow HireMe123 to access MyCalApp using the user’s permissions?

The agree dialog might look like this:

HireMe123 may seek a number of different scopes, such as:

  • write:events
  • read:events
  • read:settings
  • write:settings
  • . And so on.

In general, we should avoid using too many scopes to specify user permissions. Scope is used to license an application. However, if your authorization server provides role-based access control (RBAC), it does make sense to add different scopes for individual users.

With RBAC, you can assign specific permissions to user roles in the authorization server. Then, when the authorization server issues an access token, it can include a specific user role in scope.

Resources, what’s next?

Although we have looked at a lot of the material, we are far from knowing all the details. I hope this article will be a helpful crash course in identity, authorization, and authentication.

To further understand JWT, please read my article on JWT signature Verification that everyone can understand

If you want to learn more about this topic, here are some great resources for you to learn more about:

To learn more

The authentication video series in Auth0 documentation is a lecture created by lead architect Vittorio Bertocci to train Auth0’s new authentication engineers. If you want to learn identity according to Auth0’s criteria, this is the completely free and easiest learning material to get, and you don’t even have to pay for it with a Tweet or email.

OAuth 2.0 and OpenID connection specifications are a lot of stuff, but once you’re familiar with the terminology and have a basic understanding of authentication, they’re very helpful, informative, and understandable material. Click here: OAuth 2.0 Authorization Framework and OpenID connection specification.

Jwt. IO is a JSON Web Token resource that provides debugging tools and JWT signature/validation third-party libraries in various languages.

OpenID Connection Training ground is a debugger that allows developers to debug OIDC calls and responses step by step.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.