Json Web Token: the new invention for the user

authentication and authorization mechanism

ALEXANDRU TRIFU
IT&C Security Master
Department of Economic Informatics and Cybernetics
The Bucharest University of Economic Studies
Calea Dorobanti, no. 15-17, Sector 1,
Bucharest, 010552
ROMANIA
alexandru.trifu7@gmail.com

Abstract: In recent years, the development of web based applications increased significantly.
Because of this high demand for developing web applications, a lot of security leaks appeared,
mostly of these targeting the mechanism for access management. In this world of Internet, there are
many ways to secure the authentication process and one of the most popular standard used is called
Json Web Token (JWT). These methods for authentication and authorization prevent unauthorized
users from accessing data from a specific application. Since everybody wants to have a secured
process for authentication and authorization of users within an application, in this paper, we are
aiming to evaluate the integration of JWT with a web based application. This study shows the way of
granting permissions authorities between two parties since Json Web Token can provide default and
custom claims for this approach. By using this method, we concluded that the confidence level is
significantly increased when we are talking about authentication security and manageability. We will
discover how it is to have a powerful authentication mechanism using JWT and in addition we’ll see
what are the advantages and disadvantages of this standard.

Key-Words: security, web applications, access management, privacy, confidentiality,

authenticity
1 Introduction
The objective of JSON Web Token (JWT) is
to provide a secure mechanism for
authentication and authorization between
two parties.
There are multiple implementations of JWT
as an entry level for access control. This
paper presents the analysis of security
breaches and also the overview of how to
create and use a secured JSON Web
Token. Furthermore, we investigated the
way a hacker can steal or use an already
created JWT and also the things that should
be made in order to prevent this kind of
actions from untrusted persons.
The main topic of this article is the analysis
of how a JWT can be secured while in [1]
Jánoky described a few methods for token
revocation, comparing the characteristics in
different behaviors with the classic
solutions. Considering the fact that the
revocation of tokens is part of the
authentication process, we can say that it’s
more important to know how to create and
verify a secured token than revoking one.
As Mestre et al said in [2], JWT is a suitable
mechanism for stateless communication
between server and client which nowadays
it’s used almost all the time. To confirm this
assumption, we studied the way in which a
JWT is stored on the client side and also on
the server side.
To form a better view of this topic, we
developed a web-based application in order
to present the functionalities of a JSON
Web Token. The application is divided into
2 parts: the client side where the token is
stored and used for requesting resources,
and the server side where the token is
generated and verified for granting access
to requested resources.
This paper clarifies the role of JWT in the
development process of a secured
authentication mechanism.
2 Problem formulation
As we already know, each system or
application requires an authentication and
authorization mechanism that proves that
the user really is who they claim and
recognize the user rights and privileges.
Traditionally, the process of authentication
consists of providing a username and a
password that is verified by the system.
Recent evidence suggests that this
mechanism can be compromised by using
tools for brute force and guessing the
passwords [3].
However, there are a lot of username and
passwords known attacks and this topic will
always be an open gate for attackers. Many
studies show the weaknesses of this type of
authentication and also the tricks for
creating a strong password [4]. In the
purpose of securing the above method, we
chose the concept of token-based
authentication that allows a user to provide
his credentials (username and password) in
order to get a token which ensures them the
access into the system. Once the user is
successfully authenticated, the token is
obtained and the user can send that token
in order to get access to different resources.
The received token has been created on the
server side with a particular algorithm and
specific claims that shows the privileges of
the user.
As M.Jones et al present in [5], JSON Web
Token (JWT) is a representation of the
claim format which is intended for space
such as HTTP Authorization headers and
URI query parameters. JWTs encodes the
claim to
be sent as JSON objects that are used as
payload structure from Signature JSON
Web (JWS) or plaintext structure from
JSON Web Encryption (JWE), enabling
claims to be digitally signed/protected with
Message Authentication Code (MAC).
3 Problem Solution
To summarize the whole process, the end-
user which would like to access a specific
resource opens the application and the first
thing that should be made is to register in
order to have the possibility to get a
resource. During the registration process,
the user has to provide his name, a
username and a password. After the
account is successfully created, the user
needs to be authenticated in order to have
access to specific resources. In the
authentication process, the credentials
provided by the user are validated by the
server and if there is a match, a JSON Web
Token with that user details is created and
assigned to the user. Each request made by
the user will contain the JWT because the
user should be authenticated in order to
access any resource. These requests are
send over Secure Socket Layer (SSL) using
REST. After the validation of the JWT is
made, if the token is still valid, the user
receives access to the requested resource.
If the token is not validated, the user is
redirected to the login page to obtain
another JWT because the one that was
used in the previous request is expired or
was tempered during the process.
Figure 1. System Architecture
3.1 Proposed System Design
 to be validated on the server side. On each
We developed a Java web-based request, the token is validated against many
application with Spring MVC and Spring criteria to see if the user that is making the
Security on the back-end side and we used call has authority to get that resource and
Thymeleaf on the front-end side. The also to see if the token is still valid and is
communication is made via REST calls over having the claims that were created in the
SSL in order to have a secure way of authentication process.
transporting the information. Firstly, we
need to create a database in which the
users and tokens will be stored. This
database will contain two tables, one for the
users and the other one for the revoked
tokens. The administrator of the application
has authority to revoke tokens if someone
intercept, modify or is trying to access the
application with an unauthorized token. In
this way, we secure the application and
prevent some malicious attacks.
We used MySQL for database together with
Apache Server because is easy to use and
is coming with a high-security level. The
user must navigate to a specific URL in Figure 2. JWT as Authorization header
order to access the Home page of the
application. 3.2 Implementation
We focused on the authentication and
authorization processes because we For the development of the web-based
wanted to show how to secure these two application, we’ve used IntelliJ IDEA 2018
mechanisms with JWT. When the user and Spring Suite tools.
clicks on the Registration button, a new On the server side, technologies like Spring
window is opened and the registration MVC, Spring Boot and JAX-RS were used
process starts. The end user should provide to create the functionalities of the
the requested information from the application.
registration form like the last name, first For the client side HTML5, CSS3, JQuery,
name, username, and password. After the JavaScript and Thymeleaf were used to
form is fulfilled, the account for that user is create the design of the application and also
successfully created and saved into the for creating the communication between the
database. client and server side. The connection with
The most important part is the the database was made using Spring Data
authentication of a user because, in this JPA with Hibernate.
point, we create a specific JSON Web Regarding the security of the application,
Token for that user. After the user is Spring Security was used to secure the
successfully authenticated, one token with a exposed endpoints and the communication
specific validity is created and assigned to was encrypted between the server and the
the user. This token is stored on the browser using SSL.
sessionStorage of the browser from where
the user was connected to the application
and each request will contain the value of
the token as authorization header in order
3.2.1 Create JWT
One of the two methods used in the
application is to create the token. After
successfully authenticating a user, the
process by which a user receives a unique
token starts. NONE hashing algorithm,
Token sidejacking, Token explicit revocation
by the user and Token information
disclosure [6] are the issues that we cared
about when we developed the application.
The first issue occurs when someone sends
a token with the “none” keyword as an
algorithm of signing. Some of the JWT
libraries accept and validate tokens with the
keyword mentioned above. To avoid this
potential security breach, during the
validation process of the token, we explicitly
request that the signing algorithm should be
the same with the algorithm used in the
creation phase.
Figure 3 JWT algorithm verifier
The second concern is about intercepted or
stolen tokens. An attacker can use an
intercepted token to gain access to the
application by using the identity of the user
which belongs to that token. A way to verify
that the token is not stolen is to add user
context in the token. The first part of the
context contains a randomly generated
string during the authentication process that
will be included in the token and also
attached to a cookie that will be sent to the
client. The second one it’s a SHA256 hash
of the random string that will be stored in
the token in order to prevent any XSS
attacks.
Figure 4 Add user context in token
Regarding the token information disclosure,
we saw that can occur when a token or a
set of tokens are intercepted or stolen by an
attacker. In most cases, the attacker wants
to get access to a token in order to extract
the information stored into it. In the first
place, the JWT is created and then the info
is Base64 encoded and it’s easy to access
them.
Usually, information about the system,
security roles, and user details are stored
inside the token. Since this information
should be protected against untrusted
persons, we used the algorithm AES-GCM
for ciphering the token and the
encapsulated data and also to protect the
data against cryptanalysis attacks. This
algorithm is using Authenticated Encryption
with Associated Data that provides the
functionality of symmetric authenticated
encryption. Implementations of this primitive
are secure against adaptive chosen
ciphertext attacks. When encrypting a
plaintext one can optionally provide
associated data that should be
authenticated but not encrypted.
Figure 5 Encrypt JWT
That is, the encryption with associated data
ensures authenticity (ie. who the sender is)
and integrity (ie. data has not been
tampered with) of that data, but not its
secrecy. [7]
The ciphering process is mainly used to
hide internal information but the first and the
most important protection against tampering
of the JWT is the signature.
The last things that should be taken into
consideration are about the storage of the
token on the client side. In some situations,
the token is stored into a cookie and is sent
automatically by the browser, stored on the
localStorage of the browser and could be
retrieved even If the browser is restarted
and sometimes the token could be retrieved
using XSS attacks using JavaScript in order
to gain access to the token. To minimize the
possibilities of encounter one of the above-
mentioned situations, we stored the token
using the browser sessionStorage
container, send the token as a Bearer
header using JavaScript for each request
and add the fingerprint inside the token. Of
course, we’ll have a problem in case we
add the token to the sessionStorage
because the token will be exposed to XSS
attacks but, because of the added
fingerprint, the risk for a token to be stolen
decreases significantly.
Figure 6 Add JWT as Bearer
3.2.2 Validate JWT
The second most important method
developed is the validation of the token.
This method is used in the authorization
process in order to validate the token that
was created in the authentication phase. As
we mentioned above, each request is
secured and should have the JWT included
an Authorization header. For each request,
if the token is present the validation process
starts and if the token is expired, tempered
or doesn’t exists the user is redirected to
the login page to authenticate again and get
a new token. In this way, we are making
sure that the person that is trying to access
the resources of our application is
authorized and has rights for that.
Each request is going firstly through
JwtAuthorizationTokenFilter. This filter
extends the OncePerRequestFilter filter
where each request is caught before hits
the controller. In this phase, we validate the
token against all the above-presented
concerns in order to see if the user has a
valid token and if is authenticated. First of
all, the token is taken from the Authorization
header and is checked to see if is revoked
or not. After that, the user fingerprint is
taken from the __Secure-Fgp cookie which
should be present on the request. We
validate the fingerprint and token
parameters content to avoid malicious input
and after that, we compute the hash of the
fingerprint using the SHA-256 algorithm.
Figure 7 Compute hash of the fingerprint
As we already explained in the
authentication phase, we created a
fingerprint that contains user context and
was added as a claim into the JWT. In the
validation phase, using the computed hash
of the fingerprint, we checked that both
hash results are the same. In this way, we
know for sure that the token was not
tempered between the time of creation and
validation. In this point, our token is half
validated because we still have to validate
the algorithm used for the signature, the
time of creation and expiration and the
token claims If all the validation steps from
above are successfully passed. At the end
of the validation process, the authentication
token is created and is assigned to the
Security Context of the application. In this
way, Spring Security knows that the user
has rights and is authenticated.
4 Conclusion
In this paper, the usage of JWT was
examined in its support for creating a
secure process of authentication and
authorization. The main concerns about the
vulnerabilities of a token were identified, the
rules that should be followed in order to
have a secure token were explained and
the best-practice implementation templates
were provided. This implementation and the
methodology can be used as a starting
point for other projects that are designed to
use the advantages of JSON Web Token.
The proposed solution minimizes the risks
of getting hacked by protecting the
application against malicious attacks and
unauthorized people who want to obtain
information about the user or the content.
Additionally, even if a hacker seizes the
JWT, the implementation presented above
has proved secure against attacks by
preventing untrusted persons from changing
tokens by signing the token using a secret
key, adding a user context inside the claims
of the token and also by ciphering the token
in order to decrease the chances of the
token being stolen.
References
[1] L. V. Jánoky, J. Levendovszky and P.
Ekler1,"An analysis on the revoking
mechanisms for JSON Web
Tokens," International Journal of
Distributed
Sensor Networks, vol. 14(9), pp. 2-4, 2018.
[2] P. Mestre, P. M.-P. Rui Madureira and
C.Serodio, "Securing RESTful Web
Services
using Multiple JSON Web Tokens,"
Proceedings, vol. I, pp. 1-2, 2017.
[3] M. S. Farash and M. A. Attari, "An
efficientclient–client password-based
authenticationscheme with provable
security,"
The Journalof Supercomputing, vol. 70,
pp.
1002-1022, 2014.
[4] A. Adams, M. A. Sasse and P. Lunt,
"Making Passwords Secure and Usable,"
People and Computers, vol. XII, pp. 1-19,
1977.
[5] M. Jones, J. Bradley and N. Sakimura,
"JSON Web Token (JWT)," 2015.
[Online]. Available: https://www.rfc-
editor.org/info/rfc7519.
[6] J. Manico, D. Righetto and P. Ionescu,
"JSON_Web_Token_Cheat_Sheet_for_Ja
va, "[Online].
Available: https://github.com/OWASP/
CheatSheetSeries/blob/master/cheatsheets/
JSON_Web_Token_Cheat_Sheet_for_Jav
a.md.
[7] "Tink Primitives," [Online]. Available:
https://github.com/google/tink/blob/master
/docs/
PRIMITIVES.md#deterministic-
authenticated-encryption-with-associated-
data.