This article will detail two common ways to ensure API security: OAuth2 and JSON Web Token (JWT)

Assumptions:

  • You have or are implementing apis;

  • You are considering choosing an appropriate method to secure your API;

JWT vs. OAuth2?

To compare JWT and OAuth2? The first thing to understand is that these two things are not comparable, they are completely different things.

  • JWT is an authentication protocol JWT provides a method for issuing Access tokens and verifying the issued signed Access tokens. Tokens themselves contain a set of statements that applications can use to restrict user access to resources.

  • OAuth2 is an authorization framework on the other hand, OAuth2 is an authorization framework that provides a detailed set of authorization mechanisms (guidance). Users or applications can authorize third-party applications to access specific resources through public or private Settings.

    Since JWT and OAuth2 are not comparable, why put the two together? There are actually a lot of comparisons between JWT and OAuth2. Putting the two together in the title is indeed misleading. In many cases, the JSON Web Token is used as an authentication mechanism when discussing the implementation of OAuth2. That’s why they’re often seen together.

JWT and OAuth2

JSON Web Token (JWT)

JWT is defined in the standard as follows:

JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). -RFC7519 Tools.ietf.org/html/rfc751…

JWT is a safety standard. The basic idea is that the user provides the user name and password to the authentication server, which verifies the validity of the information submitted by the user. If successful, a Token (Token) is generated and returned that the user can use to access protected resources on the server.

An example of a token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cB ab30RMHrHDcEfxjoYZgeFONFh7HgQCopy the code

A token consists of three parts:

header.claims.signature

Copy the code

Securely used in urls, all parts are base64 URL-safe encoded.

The Header part simply declares the type (JWT) and the algorithm used to generate the signature.

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

Copy the code

Claims statement

The declaration section is the core of the entire token and represents the user details to be sent. In some cases, it is likely that we will implement authentication on one server and then access resources on another; Alternatively, tokens can be generated through a separate interface that is saved for use by application clients such as browsers. A simple example of a claim:

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

Copy the code

Signature Signature

The purpose of the signature is to ensure that the above two parts of the information is not tampered with. If you try to modify the decoded token using Bas64, the signature information becomes invalid. A private key is used to confuse headers and Claims using a specific algorithm to generate signature information. Therefore, only the original token can match the signature information.

There is an important implementation detail here. Only the application that has acquired the private key (such as a server-side application) can fully authenticate that the token contains the declared information. Therefore, never put private key information on a client (such as a browser).

What is OAuth2?

In contrast, OAuth2 is not a standard protocol, but a secure authorization framework. It describes in detail how different roles, users, front-end applications (such as apis), and clients (such as websites or mobile apps) can authenticate each other in the system.

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. – RFC6749 tools.ietf.org/html/rfc674…

Here’s a quick overview of the basic concepts involved.

Roles An application or user can play any of the following Roles:

  • Resource owner

  • Resource server

  • Client application

  • Authentication server

Client Types here refer to the users of the API. It can be of a type:

  • private

  • public

The OAuth2 framework also specifies a centralized Client Profile that represents the type of application:

  • The Web application

  • The user agent

  • The original application

Authorization Grants represent a set of permissions granted to a client application by a resource owner. Authorization Grants can take the following forms:

  • Authorization code

  • Implicit authorization

  • Resource owner password certificate

  • Client Certificate

  • Endpoints terminal

The OAuth2 framework requires the following terminals:

  • Certification of the terminal

  • Token terminal

  • Redirection terminal

As you can see from the above, OAuth2 defines a fairly complex set of specifications.

Use HTTPS to protect user passwords

Before going any further into the implementation of OAuth2 and JWT, it is important to note that both schemes require SSL security, which encrypts and encodes the data to be transmitted.

The secure transmission of private information provided by users is essential in any secure system. Otherwise, anyone could hack into private wifi and steal user names and passwords while logging in.

Some important implementation considerations Before making a choice, consider the following points.

OAuth2 is a security framework that describes authorization issues between multiple applications in a variety of scenarios. There is a huge amount of material to study and it takes a lot of time to fully understand. Even for some experienced developers, it will take about a month to understand OAuth2 in depth. That’s a big investment of time. JWT, by contrast, is a relatively lightweight concept. It might be easy to get started with a day of in-depth study of the standard specifications.

Risk of error OAuth2 is not a strict standard protocol like JWT and is therefore more prone to error during implementation. Although there are many existing libraries, each one has different levels of maturity and is equally prone to introducing errors. It is also easy to find security holes in commonly used libraries. Of course, these risks can be avoided if there is a mature and strong development team to continue OAuth2 implementation and maintenance.

Benefits of Social Logins In many cases, it is convenient to authenticate using a user’s existing account on a large social network. If you expect your users to be able to use Facebook or Gmail accounts directly, it’s much easier to use an existing library.

conclusion

Before concluding, let’s list the main usage scenarios for JWT and OAuth2.

JWT usage scenarios

Stateless distributed API

The main advantage of JWT is that it handles user sessions in applications in a stateless, extensible manner. The server can easily obtain the user’s session information through the embedded declaration information without having to access the user or session’s database.

This is very useful in a distributed service-oriented framework. However, if the system needs to use a blacklist to implement a long-term token refresh mechanism, this stateless advantage is not obvious.

advantage

  • Rapid development of

  • Don’t need a cookie

  • JSON is widely used on mobile terminals

  • Does not rely on social logins

  • Relatively simple conceptual understanding

limit

  • The Token has a length limit

  • Tokens cannot be revoked

  • Requires token to have expiring time limit (exp)

  • OAuth2 Application scenarios

There are two scenarios in which OAuth2 is necessary, according to the authors:

Outsourced Authentication Server

As discussed above, if you don’t mind relying on an external third-party authentication provider to use your API, you can simply leave authentication to the authentication service provider. This is commonly done by registering your app with a certified service (such as Facebook) and setting up user information that you want to access, such as email address, name, etc.

When users visit the site’s registration page, they see a portal connecting to a third-party provider. After the user clicks, it is redirected to the corresponding authentication service provider website. After obtaining the user’s authorization, it can access the required information, and then redirected back.

Spring Boot tutorial:

Github.com/javastacks/…

advantage

  • Rapid development of

  • Small amount of implementation code

  • Reduced maintenance work

Large enterprise solutions

If the API is designed to be used by different apps, and each App uses it differently, using OAuth2 is a good choice.

Given the workload, a separate team may be required to develop sound, flexible security policies for various applications. Of course, the workload is also relatively large! This is also pointed out by the authors of OAuth2:

To be clear, OAuth 2.0 at the hand of a developer with deep understanding of Web security will likely result in a secure implementation. However, At the hands of most developers — as has been the experience from the past two years — 2.0 is likely to produce insecure Implementations. Hueniverse – OAuth 2.0 and the Road to Hell

advantage

  • Flexible implementation

  • Can be used in conjunction with JWT

  • It can be extended for different applications