| title | author | image | tags | |||
|---|---|---|---|---|---|---|
Why JWT? |
iviczl |
/img/posts/lock.jpg |
|
A way to make users prove their identity is an inevitable task for everyone who gets his head around making a content managements system. sensenet offers a new method for you to achieve this, that uses tokens, namely JWTs.
However sensenet has been supporting authentication through NTLM and Basic for a long time, neither of them is a good choice for some scenarios. NTLM can be used only, if the authenticating user is a Windows domain user as well, Basic authentication on the other hand requires to send your user's credentials with every request. We decided to implement a modern and easily usable and secure enough means to authenticate a user in the sensenet environment.
There were a plethora of authentication methods in the wild, but we needed only one. We were sure about a token based solution, so we just needed a closer look to rule out those, that would not do. Token based solutions have the following advantages in common:
- stateless
- transfers claims between two parties
- scalable and decoupled
- scalable: you can extend the data stored in the payload
- decoupled: you have the choice to delegate the authentication tasks to a separate server
As we narrowed the list, only the following choices remained: Simple Web Tokens (SWT), Security Assertion Markup Language Tokens (SAML), JSON Web Token (JWT).
We have chosen JWT and that was not by chance. Here I collected some of the features, that made us determined about it:
- industry standard (RFC 7519)
- can be digitally signed and/or encrypted
- compact and self-contained
- compact: JSON is less verbose than XML, so because of their small size, JWTs can be sent through the line as a POST parameter, or inside an HTTP header. The smaller size also results in faster transmission
- self-contained: the payload can contain every required information about the user and the scope, eliminating the need to query the database again an again
- works seamlessly with CORS and Single Sign On
- JSON is easy to sign with a digital signature, however SAML tokens can use a public/private key pair in the form of a X.509 certificate it would make the signed token huge in size
- JSON parser is already in JavaScript and it maps directly to objects. JS does not have document-to-object mapping for XML
- JWT is used at Internet widely, because the ease of JS processing of the JSON Web token on many platforms, particularly mobile.
Not really, because JWT is only a format for the information to get through.
It contains claims in its payload, but tells us nothing about the communication between our client and service.
The illustration above depicts the logical architecture of the authentication. The physical one however contains some simplification, so you do not need to set up a separate authentication server, it is an integral part of the sensenet service layer.
We need to sign the JWT to make it easy to prove its thrustworthiness. A signed JWT is known as a JWS (JSON Web Signature). In sensenet 7.0 we use HS512 algorithm (HMAC with SHA-512 hash) to sign the token, that is a symmetric key digital signature.
Because we have been aware that the formerly used cookie based authentication has some advantages to the clear token authentication, decided to blend them and created a hybrid method, that remains stateless on the server. This also means you do not have to implement anything on the service side, only on the client side. We put the JWS partly in the response header, partly in a cookie. It came with a price of course: with this we lost the exceptional treats by HTTP proxies of the "Authorization: Bearer" headers. For further details on the protocol and how to use it, please, read the Configuration of Web Token Authentication article.