Jakarta Security and REST on Cloud: Part 4 Combining JWT With OAuth2

DZone 's Guide to

Jakarta Security and REST on Cloud: Part 4 Combining JWT With OAuth2

OAuth2 is undoubtedly one of the most famous security protocols today. This post will talk a little about how to integrate OAuth2 with JWTs.

· Java Zone ·
Free Resource

OAuth2 is undoubtedly one of the most famous security protocols today. One of its advantages is the non-exposure of sensitive information, such as user and password, consistently, as done by the BASIC mechanism. However, there is an increase in its complexity, especially when we talk about exchanging tokens, which do not have much use since it does not contain any information. However, we can make them have a little responsibility, such as transporting information safely. This post will talk a little about how to integrate OAuth2 with JWTs.

In part 3 of this series, we talked about the Oauth2 mechanism and the costs and benefits involving complexity and the possibility of not overexposing login and password data. One of the outstanding characteristics of this mechanism is found in the security communication from the token. Until then, it has only one use: Reference. This pointer works like a link. However, it does not have the information itself. It works as an Oauth2 mechanism. We send a token, which in turn is checked for existence in the database so that the user's authentication information and respective credentials are searched. That is, the user's entire state is in the bank.

This approach can cause performance problems, since we need to verify the authenticity of such a token, being necessary to search the information in the database in every interaction. That is, if a service needs to integrate with four others within the same authentication and authorization mechanism, it will need to seek the same state of the user all four times.

A new strategy would be to use the token in a complete way instead of just as a pointer. This means that if we were able to store user information with the symbol itself, we would have a performance gain. This is possible thanks to JSON Web Tokens, an open industry standard for representing secure communication between parties. With JWTs, we have the option to sign and/or encrypt the information we want; in this case, it would be the user and the roles to be used. The focus of the article is not to talk about JWT, but about the integration with Oauth2. If the reader wants to know more information about the subject, there is a very cool Handbook about JWTs.

Let's start by getting hands-on using the design of part 3, so we don't have to start from scratch. The first step will be to add the JWT to the dependency. This library will be responsible for reading and writing the JWT.


With the dependencies defined, the next step will be to modify the code itself. In entities, AccessToken will be modified, as we will change the ID so that it can receive the JWT as String, in addition to storing the secret. This secret will be unique and randomly generated for each entity and will be responsible for confirming the signature and for verifying the authenticity of the JWT. It is worth noting that the signature is responsible for verifying the authenticity of the JWT and for confirming that it has not been modified, that is, the signature does not mean encryption. For more information on JWT and cryptography, we can access the link for JWE.


To facilitate the reading and manipulation of the JWT, the UserJWT will be created. This class will generate the JWT in text format. It is interesting to note that there is a check on creation in the UserJWT factory method. This verification is done by the signature, previously explained, and also by the expiration date.


Once the modeling has modified, the next step is to change the OAuth2 service. The interesting point is that in addition to the existing TTL, the JWT also checks the data expiration. That is, there is a double check of data consistency in this signal.


The last step will be to change the mechanism. In general, user information will not be retrieved from the database, but from the JWT itself.


Moving to the Cloud

As there was no change in services or structure of the containers, the structure and configuration for sending the application to the cloud with Platform.sh will be maintained in the same way.

There, the mechanism was refactored not to use the information in the database, thus reducing the number of requests. However, we have a big problem with data consistency, since there is still the possibility of a change in the database that will be reflected only when the token expires. The user would need to update their tokens with the refresh token. There is a strategy to work with this, which would be to launch events to make the current token unfeasible, forcing the user to do the refresh token process early.

The critical point is that there is always a disadvantage between data consistency and availability, and it is up to the architect to understand each case and choose the best strategy. The main objective of this series of articles is to know how the security API works. However, every line of code we write is code that will need to be maintained, so using an existing solution may be the best option. There are security solutions that already exist and are worth taking a look at, like Okta and Keycloak.

As always, the code example is from GitHub.

cloud (add topic), jakarta, jakarta ee, java, jnosql, paas, security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}