All You Need to Know About User Authentication

User Authentication is becoming more and more challenging in today’s SaaS space due to the fluctuating usage patterns and scaling of companies. This crucial user management aspect needs to be implemented smoothly and seamlessly, with zero impact on the user experience. Let’s learn more about the ins and outs of this key SaaS component. 

This article will cover all the key aspects of User Authentication – access tokens, ID tokens, refresh tokens, and the authorization code. We also recommend you check out our detailed User Authentication vs Authorization comparison.

What are Access Tokens?

Access Tokens are important components of the User Authentication mechanism. These tiny pieces of code contain crucial data like usernames, permissions, groups, and time-frames. All of this is embedded into tokens that are transferred from servers to user devices when needed. For example, the JSON Web Token (JWT) is made up of just three Base64-URL strings.

The Access Token has three main elements:

1. Header: The header holds data about the token’s exact type and also the algorithm that has been used to make it
2. Payload: The payload holds user information. This includes permissions and expirations, both crucial User Authentication parameters. Also known as the “claims section”, the payload is crucial to the success of the token because inadequate or improper permissions will simply block any access
3. Signature: Last but not the least, the signature includes verification data for the recipient to ensure the authenticity of the token

As you can see in the code snippet below, no personal information is involved except the User ID in the sub claim. However, you can retrieve additional user information by calling the user info API endpoint with the Access Token.

Access Token types can vary based on use cases. There’s the User Access Token for when the SaaS app calls on an API to access, write, and modify data. The user needs to approve this token’s usage. Likewise, the App Access Token allows the user to make changes in app settings. There are also Client Tokens that can be embedded into the app as identifiers to access app-levels APIs.

Access Tokens can also be used in Single Sign-On (SSO) flows. Once authorized, the user’s credentials from one SaaS application or service can be used to access other linked apps. The Access Token is stored in the browser.

Related: SSO Solutions: Key Features and Top Vendors

What are Refresh Tokens?

Refresh Tokens are credential artifacts that are valid only for a few seconds. Once they expire, SaaS apps can use Refresh Tokens to renew them without the user logging in again. Besides reducing in-app friction, Refresh Tokens help secure the User Authorization. Single-Pages Apps (SPAs) usually don’t use Refresh Tokens as they use implicit flows.

The authorization server issues Refresh Tokens to the client. They are then used to obtain new access tokens when the current ones expire. Refresh Tokens also help obtain additional access tokens with narrower scopes.

Refresh Tokens come with the Access Token when used:

What are ID Tokens?

Identity (ID) Tokens are performance enhancers. They cache crucial user information (profile data) and send it to the client SaaS app, which can then use it for many purposes after the user authenticates. This improves the user experience. Unlike the aforementioned Access Tokens that are OAuth based, ID Tokens are defined in OpenID Connect, commonly known as OIDC.

ID Tokens can’t be random strings like Access Tokens. They are all JSON Web Tokens (JWTs) that should never be sent to APIs or used to make User Authorization decisions. ID Tokens are only meant to be read by OAuth clients.

Here’s how the claims within the ID Token look:

• iss – The issuer of the token
• aud – The audience of the token
• sub – The subject identifier of the end user
• exp – The expiry information of the token
• iat – The time at when the token was created

Now let’s take a look at an example:

{
  "iss": "https://my-domain.frontegg.com", 
  "sub": "frontegg|212121", 
  "aud": "1111abcabc", 
  "exp": 1311281980, 
  "iat": 1311280980, 
  "name": "Jack Daniels", 
  "given_name": "Jack", 
  "family_name": "Daniels"
}

While the code above has identity claims, it’s recommended to use them as seldom as possible. This is because identity claims cause bloating and increase the risk of compromise. Utilize user info endpoints instead.

What is the Authorization Code?

Authorization Code is what drives tokens in the whole process of User Authentication in SaaS apps that possess server-side components. With this code, you can keep the authorization server client secret to stay confidential. Not using the Authorization Code will lead you down the Implicit Flow (OAuth 2.0) path, where you’ll only get your hands on the Access Token. 

The server-side component of the web app can then seamlessly manage the user’s session upon authenticating with the authorization server, without revealing anything about the it’s response ( like refresh token information or other personal data) to the end-user. This code helps to isolate the token from the user client and prevents it from being exposed to unauthorized agents.

User Authentication vs User Authorization

Authentication should not be confused with Authorization. User Authentication is based on “factors”, which are basically things that users possess or parameters that they can present to prove their identity.

• Knowledge factors— These are some factors that the user surely knows. The factors can include access codes, Personal Identifications Numbers (PINs), or passwords). Knowledge factors are considered to be the least secure because attackers can easily crack them relatively easily.
• Possession factors— These are factors that the user has. Possession factors include physical identity documents, keys, hardware access tokens, mobile phones, digital certificates, software tokens, or anything else a user or entity possesses that proves their identity.
• Inherence Factors— These are factors related to the user’s identity – face images, live video of a user, fingerprint scans, or any other biometric reading. Many consider inherence factors to be the most secure, but sophisticated attackers can compromise them by faking biometric readings.

User Authorization is essentially based on what is commonly known as  “permissions”, which involve the definition of what an authenticated user can and cannot do within a SaaS application or service ecosystem.

• Role-Based Permissions— Permissions given to a group of users that share business roles. They specify the resources that this group is allowed to access, supporting the least privilege access principle, which means users are granted the minimal resources they need to perform their business role.
• Device Permissions— Permissions based on the specific computing machine that is requesting access. This model can grant different permissions for trusted devices such as corporate laptops or non-trusted devices like personal smartphones or tablets. 
• Location permissions— Permissions based on the user’s geo-location. With remote work becoming the norm during the pandemic, authorization systems are now using this type of permission to limit access to sensitive resources to achieve sustainable compliance and reduce the attack surface.

User Authentication with Frontegg

Frontegg is a self-served and PLG-centric User Management platform for SaaS businesses that are looking to cover both Authorization and Authentication bases with one centralized solution. There’s no need to worry about coding and implementing changes. Just manage your roles and permissions, create strong Authentication flows, and customize your Login Box, all via one dashboard. 

START FOR FREE