Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
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.
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:
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
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:
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:
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.
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.
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.
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.
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
The Complete Guide to SaaS Multi-Tenant Architecture
Looking to take your User Management to the next level?