While an increasing number of people are gaining access to the world wide web, it’s becoming more and more important for web- and app developers to provide a safe and secure digital environment for its users. One way to establish a secured use of an application is by the means of so-called authentication or ID tokens. These are digital protocols that identify individual users and some specific user information. This blog dives deeper into the world of authentication tokens and JSON web tokens for web applications in particular.

Authorization or authentication?

Authorization and authentication are two core terms within the world of digital access and identity management. In order to avoid confusion, as both terms are similar, let’s have a look at their respective definitions first.

Authentication

The term authentication refers to the process of identifying individual users and validating who they say they are. Probably the most common example of digital authentication is the use of a password. The user fills in their username and password credentials and if they match, the person is authenticated as a trusted user and has been granted access to the application or website. With continuous advancing technologies, authentication is becoming increasingly secure and personalized, for example with the use of facial recognition technologies or fingerprint readers.

The more complex the authentication process, the more difficult it is for hackers to break into an account. One way to make the authentication process more secure is by implementing multi-factor authentication (MFA), which requires users to provide additional input for authentication, aside from just a username and password. Think of, for example, a personalized code you receive via SMS or email after entering your username and password credentials. These added steps in the authentication process provide more protection.

Authorization

Authorization happens after the process of authentication. Once a user’s identity is authenticated, authorization comes in to request more access rights to resources such as databases or other additional personal information. So, authorization refers to the validation of roles, permissions and privileges that are assigned to a specific user.

To summarise, the main difference between authorization and authentication can be best described with the analogy of airport customs. Whereas authentication can be seen as the passport check to see if it’s really you, authorization is the following permission to walk to the gate, buy duty-free products, and eventually board the correct plane.

Access token or ID token?

Generally, we can speak of two different main types of tokens; the “identification (ID) token” and the “access token”. ID tokens are used to authenticate a user, collect information about this user and send it through to the application they’re using. With this information, the app can provide a personalized and optimized performance and user experience. When you allow your users to log into your web app with their Google account, the ID token collects the information stored in that account and uses it, for example, to showcase your personal avatar in the top right of every Google page. The information from this avatar comes directly from the ID token.

Whereas ID tokens are used for identifying a user and containing their user data in order to provide a personalized experience, access tokens are used to inform APIs that the person trying to access the app has been authorized and granted access. If a user logs into your application with their Google account and gives the app consent to access their Google Calendar, Google will send an access token to the app. Every time the user logs into your app, the app sends an access request - including the access token - to the API of Google Calendar. Once the request is authorized, your app can interact with that user’s Google Calendar.

JSON Web Token (JWT)

An example of a commonly used access and ID token is the JSON Web Token, also known as a JWT. A JWT is a generally used standard for securely transmitting information between parties by packing the information as a JSON object and hashing it alongside. Essentially, all JWTs are tokens, but not all tokens are JWTs. In other words, all ID tokens are JWTs, but not all access tokens are JWTs. The information within a JSON object can be trusted on its authenticity as it’s digitally signed.

JWTs are unique in the sense that the authenticating party does not need to be the authorizing party. Imagine an all-inclusive resort in which the restaurants look at the bracelet you got after checking in to make sure you are really a guest. However, some guests pay for only one bracelet and then share it among a group, effectively eating and drinking for many people while paying only for one. In the case of a JWT, the person that paid for the bracelet is the JSON object and the hash is the bracelet itself containing the same data, but you need a key to read it. So if you were to order a drink with your bracelet, the waiter - who has the secret key - would see you, reads the bracelet and can confirm that the bracelet is indeed yours. But when you give your bracelet to your friend the waiter can immediately confirm that the person wearing it is not the person it belongs to. Now the waiter can notify the hotel management, the person is no longer granted access to the restaurants, and the bracelet is revoked.

Extra security with SSL

Any person that can intercept a JWT or read it from the user’s machine, will be able to find out the user’s identity. Similar to the guest that walks around in the resort being recognizable and the only way to prevent this would be by wearing a mask. In real life, it’s not convenient to have your breakfast with a bag over your head, but on the Internet we can make sure to encrypt everything over an SSL connection, basically putting a bag over all the other guest’s heads. However, there are still concerns in terms of security.

Hackers might not be able to read what you send and receive to and from servers, but they might hide on your machine, observing what you are going to send and what you received, or even steal your JWT to authorize requests as if they were you. It’s like someone sneaking into your hotel room ordering room service to your room and consuming it before you even know it. These kinds of hacks are commonly found in malware. Of course, there’s only so much JWTs can do to help fix this, so it’s very important to always have an up-to-date virus and malware scanner running on your computer. Even though JWTs can’t prevent this from happening, there is a mechanism that will limit the damage when it happens.

HTTP Cookies

A JWT has an expiration time, usually very short, think of between 1 and 15 minutes. This time is packed into the JSON object and thus into the hashed token. Whenever a service receives a request it will look at this timestamp and will deny the request if it’s expired. The application will have to renew the JWT every time it expires and has to go back to the authentication service to do this. Of course, passing username and password and even performing MFA every minute wouldn’t be convenient. Instead, the authentication service plants an HTTP cookie in your browser. This is a unique cookie that cannot be read by anyone or anything other than the service itself. Not even you, as the owner, can read it. The authentication service can read the cookie, verify its origin and, in turn, provide a new JWT which minimises the time of exposure due to malware to the expiry time.

JWTs are very convenient. Everything happens behind the scenes and the user is totally unaware of all the security measures. But it’s not waterproof, hence, not all features should rely on its security. If a specific functionality is too important, a roundtrip to the authentication service is needed. A good example of this necessary roundtrip is a bank transfer. You can log into your bank’s portal and after signing in once, you can freely check your account, mutations, etc. But once you are performing a bank transfer, the portal will request you to reauthenticate, probably even verifying the transfer itself with a token through a TAC, OTP or an external authentication device.

Lizard Global ensures secure data handling

At Lizard Global, the secure handling of your data is our number one priority. No matter the complexity of the authentication processes in our (web) applications, we make sure that all data is being transmitted efficiently and securely. Read more about our data protection protocols and methodologies in our secure solutions documentation. Want to know more about JWTs, SSLs or other information security technologies? Get in touch with one of our experts on our social media channels or with a quick WhatsApp message.