Frontegg https://frontegg.com Platform for SaaS Applications Mon, 12 Apr 2021 19:00:47 +0000 en-US hourly 1 https://frontegg.com/wp-content/uploads/2020/06/favicon.png Frontegg https://frontegg.com 32 32 What Are the Security Measures to Prevent Authentication Attacks https://frontegg.com/blog/what-are-the-security-measures-to-prevent-authentication-attacks https://frontegg.com/blog/what-are-the-security-measures-to-prevent-authentication-attacks#respond Mon, 05 Apr 2021 17:57:36 +0000 https://frontegg.com/?p=4805 Authentication is quite often misunderstood. Many believe authentication practices are purely for identification — but that is simply not the case. Authentication processes are put in user management systems to verify the identity of a user so that the system is sure that the user logging in will have access to the data that concerns […]

The post What Are the Security Measures to Prevent Authentication Attacks appeared first on Frontegg.

]]>

Authentication is quite often misunderstood. Many believe authentication practices are purely for identification — but that is simply not the case. Authentication processes are put in user management systems to verify the identity of a user so that the system is sure that the user logging in will have access to the data that concerns them only. 

Authentication is the boundary between the user & data, it needs to be as secure and strong as possible. This is especially true in industries like finance or health; it is crucial to make sure nobody can accidentally (or purposely) log into a different person’s account. 

This is exactly why many platforms implement rigorous authentication processes.

Unfortunately, that doesn’t mean authentication attacks are rare… Many systems are still at risk of falling prey to various kinds of attacks. Therefore, to spread awareness about this, we’ve created this list of top security measures you can implement in your user management systems to protect yourself & your users against authentication attacks.

2FA or MFA?

In user authentication, using more than one authentication mode can provide better security.

Two-factor authentication gives developers the freedom to implement a variety of options to act as a second layer of security. Most commonly you will receive a one-time password (OTP) for additional verification. 

one-time password (OTP) for additional verification
Image Source

While registering for a new account on a website, users are prompted to add and verify their email address or mobile number. So, when there is a login attempt to that account, the backend will send an OTP to the registered mobile number or email address, and it will grant access only if both password and OTP are entered correctly.

At times, some extremely secure websites and services will enact multi-factor authentication where the user must provide more than just a password and an OTP. The more factors you add to the system, the safer it can be.

The biggest challenge when implementing the two-factor authentication is making sure users register their email address / mobile number to sign up for the two-factor authentication.

While many websites provide two-factor authentication, most users are not aware that it exists or just choose not to opt for the additional hassle while logging into the website.

Passwords Strength Validation

Passwords Strength Validation
Image Source

Developers face many challenges while implementing a secure and user-friendly authentication system. One that comes to mind right off the bat is the dreaded weak password. While passwords provide a reasonable amount of security, they are only as good as their complexity, which depends on the user. If a password is not complex enough, attackers can simply perform a brute-force attack to try and guess the password. 

Even in 2021, users tend to select weak passwords, which end up with users getting their sensitive data and access compromised. In 2020, some of the most common weak passwords were abc123, 123456, and 1234567890, which is equivalent to writing the password on a post-it note and leaving it on the office desk.

One solution to this problem could be implementing a policy to check whether the user’s password is strong enough. Many services, especially those to do with finances or deeply personal data, impose checks on your password to ensure that it is secure. Using special characters and avoiding common patterns while formulating passwords is highly recommended. 

Secure Password Storing

Secure Password Storing
Image Source

Another big mistake while implementing user authentication is storing and working on the users’ plaintext passwords. Most websites take the user’s password and store them directly into their database to compare when they log in next.

One big drawback to this is that if the website suffers a data breach, all users can have their passwords leaked to the attackers. Additionally, most users reuse the passwords, so it is likely a user with the leaked password would have used the same password on other websites as well.

A solution to this problem is to store hashed versions of the passwords, instead of keeping the password as a whole. When a user enters the password on login, the backend should calculate the hash of the entered password and compare it with the stored version of the hash, then grant the access if both are equal. 

Due to the one-way property of a secure hash, if the hash were to be stolen, it would take years for an attacker to find a password from the hash because they don’t have the decryption key.

Compromised Attack Detection

Suspicious and abnormal behavior controls

In the past decade, machine learning apps & artificial intelligence have increased ten-fold. Artificial Intelligence models can be used to build applications that can detect if an authenticated resource is being used differently than normal. 

Anomaly detection techniques are already implemented in the banking industry. An anomaly detection algorithm learns from a user’s purchase pattern. If someday abnormal purchases are made, the bank can flag the transaction as possible fraud and stop that transaction resulting in the detection of a compromise at an early stage. This saves both the user and the bank from the implications of credit card theft.

IP Tracking

IP Tracking
Image Source

Most websites maintain a database of user IP addresses and locations. This data is generally used to deliver targeted advertisements to the user. Still, you can also use this to provide a secure and safer experience for the website members.

Websites can keep track of an IP range from which a user logs into the account. If a drastic change is detected, the account may be compromised. Most authentication systems serving internal organization applications can specify in the authentication scheme to allow only the corporation IP range attempts. Authentication systems can also log geographic details of the IP address, such as longitude, latitude which can help if any breach happens.

“Too-fast-too-travel” detection

It is common for a user to access the same account from the exact location often. So, websites can store the location from which the user generally accesses the account. If someday, all of a sudden, the user account is accessed from a location that they could not have possibly traveled to in the given time, then there are high chances that the user account has been compromised.

Roles and Permissions Handling

Roles and Permissions Handling
Image Source

Roles & permissions-based authentication is essential in any organization that has many users requesting an array of permissions. 

In a typical scenario, users are given various permissions.

Role-based permissions are a burden for system administrators, managing permissions from user to user. 

There are usually various teams within a company that need various permissions. Software developers often require access from multiple sources like the Internet, Cloud storage, cloud instances, firewall, Microsoft Office, etc. While our lovely developers may need all this access, other teams do not. For instance, the accounting team needs access to the accounting software — not the marketing software.

By implementing proper role-based permissions, system administrators can divide the users into two categories. The enterprise will make each user a member of one of two roles, either software developer or accounting. So, if a user is a member of an accounting role, he would have permission to access only the accounting software. In contrast, a member of the software development team would have access to a variety of permissions. This way, the principle of least privilege is implemented where only the needed permissions are provided. So, if a compromise occurs, it would be easier to triangulate and pinpoint a specific role as a possible entry point.

Device Policy Enforcement

In many applications where security is of the highest importance, a user must be logged into the account from only one device at a time. If multiple logins are detected, it should not be allowed. This strict device policy enforcement deems useful when even after credentials for an account are compromised; attackers still need to get the device authorized to get into the account. This provides a second layer of security from a possible breach. Even if attackers manage to get their device authorized, app developers can take several pieces of information such as IP address, device location, etc., to make it easier to take possible actions in the case of actual compromise.

Conclusion

In most computer systems, authentication is the primary line of defense against cyber attacks. 

User authentication, if properly implemented, can be the basis for most types of access control and user accountability. While it may be time-consuming to ask users to verify their identity through various authentication layers, these security measures ensure a secure user experience, which is crucial for a successful product or platform.

The post What Are the Security Measures to Prevent Authentication Attacks appeared first on Frontegg.

]]>
https://frontegg.com/blog/what-are-the-security-measures-to-prevent-authentication-attacks/feed 0
Common Security Pitfalls of User Management: What You Need to Know https://frontegg.com/blog/common-security-attacks-on-your-user-management https://frontegg.com/blog/common-security-attacks-on-your-user-management#respond Thu, 01 Apr 2021 13:27:35 +0000 https://frontegg.com/?p=4776 Introduction When creating applications that require rigorous user management, it’s important to consider all aspects of implementation. It should be easy-to-understand for the user, easy-to-navigate, but most importantly, it should be as secure as possible. Data leaks and breaches have become extremely common in the 21st century, users are catching on as well, taking SaaS […]

The post Common Security Pitfalls of User Management: What You Need to Know appeared first on Frontegg.

]]>

Introduction

When creating applications that require rigorous user management, it’s important to consider all aspects of implementation. It should be easy-to-understand for the user, easy-to-navigate, but most importantly, it should be as secure as possible. Data leaks and breaches have become extremely common in the 21st century, users are catching on as well, taking SaaS application security measures. 

Many attacks take place on your authentication service. Authentication is one of the most critical components of any application. As the first line of defense, it provides the way for applications to identify if the resource requested is indeed authorized to be accessed by a specific user.

A tech company must constantly evolve with new authentication and user management technologies so that their users’ data is always safe and secure. In this post, we’ve gathered the most common security attacks you should guard against when selecting a user management system or figuring out your SaaS authentication processes.

So, let’s talk about some common attacks on authentication…

Phishing

As per this FBI report, phishing was the top committed cybercrime in 2020, with 241,321 reported incidents. Phishing campaigns can be targeted to a specific person of interest to compromise access to a particular resource. It can be targeted to a mass scamming them to compromise access, leak their data, or just earn money from scamming.

Phishing’s main purpose is to convince unassuming users that they are entering their details for a legitimate purpose but by faking that interface. One of the most common phishing attacks is the attack on the most popular social media platform, Facebook.

what is phishing
Image Source

To compromise access to a Facebook account, attackers set up a page looking exactly like the authentic login page of Facebook with username and password fields. Link to the phishing webpage is then sent to targets; when a user opens the link and enters their login details, instead of sending the details to the login, attackers get the login details and divert the victim to the original webpage.

Generally, this can be prevented by two-factor authentication. Still, some attackers are willing to go to the next level to bypass the two-factor authentication via reverse proxy tools such as Modlishka and use that to phish users to share their one-time passwords.

Phishing can also be seen in the banking industry, where attackers send the webpage looking precisely like the bank page and steal the various sensitive details such as login and credit card details.

MFA spoofing

MFA spoofing
Image Source

We know two-factor authentication provides better security for the user. Attackers have already come up with various ways to compromise the access secured with the two-factor authentication, via exploiting the weakest link in the security chain, i.e., humans.

After getting the target user account’s password via various methods such as brute-force, phishing, or exploiting the application vulnerabilities, attackers need to know the one-time password sent to the user’s mobile number/email address. To do this, attackers spoof a message to trick users into sending one-time passwords to the attackers.

The message sent by the attacker will imitate a legitimate website or service you use so that it doesn’t look fake. In the message, they will include a link or a file that, upon downloading, will attach malware to your phone. This malware will effectively transmit all of your SMS messages to the attacker, so that any OTP they generate using your details will also be accessed by them through the malware.

General Web Attacks

There is also a possibility of website developers not implementing various security services and protocols, resulting in vulnerabilities left behind in the website, which an attacker can later exploit. Typically, the impact of a website attack can be from the website being down for a while, to compromising all users’ data.

One of the most common website attacks is SQL injection

SQL injection
Image Source

While authenticating the entered username and password, the backend forms a SQL query (in a website that uses SQL for the database), which queries the database to check if there is an account with the username and password of the user. 

Here, suppose the backend does not sanitize the users’ details and directly processes them into the SQL query. In that case, attackers can modify the input to get the SQL server to execute the SQL queries of the attacker’s choice. This could result in the complete compromise of the website’s database storing user data.

Another example is cross-site scripting (XSS).

cross-site scripting (XSS
Image Source

In XSS attacks, the attacker attempts to attach malicious code to a legitimate site in the expectation that an unsuspecting user will fall victim to it when they load the site. The code is often attached at the end of the URL or pasted to a page that contains user-generated content. It is effectively a client-side code attack. 

This sort of attack can be detrimental as it can access a user’s cookies and extract login credentials for important websites, or help attackers gain access to geographical locations, webcam data, or other such sensitive information.

To avoid this sort of attack, one way is to introduce validation checks for user inputs to make sure only the correct type of data is being entered. 

There are other types of web attacks as well, like Cross-Site Request Forgery (CSRF) or Denial of Service attacks. OWASP goes further in-depth for these types of attacks and more.

Conclusion

Securing client-facing applications is a complex task, but complying with industry standards and preparing against the worst-case scenarios makes it possible to provide a completely secure experience to the users. In this article we’ve described some of the popular attacks that could be performed on your user management and identity infrastructure. Ultimately, your choice of user management tools and services along with a definitive action plan for how you want to secure your data will help you create a workflow that is secure and not inconvenient for your users. 

Frontegg provides an end-2-end user-management solution that contains the most secure and granular security policies, features and measures so that the risk for a successful attack on your users infrastructure is minimized to zero.

The post Common Security Pitfalls of User Management: What You Need to Know appeared first on Frontegg.

]]>
https://frontegg.com/blog/common-security-attacks-on-your-user-management/feed 0
Top 8 User Management Features Within Your App https://frontegg.com/blog/top-8-user-management-features-within-your-app https://frontegg.com/blog/top-8-user-management-features-within-your-app#respond Thu, 25 Mar 2021 10:29:40 +0000 https://frontegg.com/?p=4723 Every app has an Admin Portal where the end-user can manage each aspect of their personal profile and where the more privileged admins can also manage their organizational account settings. One of the main screens within this Admin Portal would usually be User Management (a.k.a “team management”, “users”, “members” etc). In the age of self-service […]

The post Top 8 User Management Features Within Your App appeared first on Frontegg.

]]>

Every app has an Admin Portal where the end-user can manage each aspect of their personal profile and where the more privileged admins can also manage their organizational account settings. One of the main screens within this Admin Portal would usually be User Management (a.k.a “team management”, “users”, “members” etc).

In the age of self-service and PLG (Product-Led Growth), SaaS user management capabilities are becoming one of the most important features within your SaaS application for guaranteeing your users happiness. You want to ensure an easy experience for your users in order to increase the usage of your SaaS application within the organization. In most cases, when you start to notice accounts moving from single-user usage to the inviting of more team members within the organization, this is a sign of stickiness and true adoption of your product.

That is exactly why creating the ultimate experience around your users’ team management is crucial. We can learn about those necessary features by looking at some examples of products that have done it right. 

List of Users

For starters, seeing a list of members in the organization (or tenant, or account, etc.) is basic. The list should be clear and, for every user, at least include these properties:

  • Name of the user
  • Email
  • Profile picture (or gravatar)
Members screen in Notion. Credit: Notion.

Last Login

A good practice is to show your users the “last login.” In some product cases, one can interact with the system “offline”, e.g. through APIs, in which case we would want to call it “last activity” instead.

This capability provides your customer’s admins with a full picture of the “inactive users” within their account. This information is crucial for two main reasons:

  1. Security  and access management —  Your customers are wary of unwarranted access to their accounts since it could (a) increase a potential surface attack by hackers (b) expose their information to users who no longer have access rights or authorization.
  2. Billing — In cases of “seat-based pricing” your customers don’t want to pay monthly fees for users that are no longer active within their organization.
Last Active column in “Seat Based” ClickUp. Credit: ClickUp.

Roles Management

Allowing your users to assign roles for other users is not just basic, it’s critical. The most basic approach would be to assign each user a specific role within your SaaS application. There are also several more advanced approaches for handling assignment of roles for your users:

  1. Multiple Roles — Some apps allow you to add multiple roles for users. In case those roles include a set of permissions, then the user would be allowed to perform any of the actions that exist in any or all of the roles assigned to them.
  2. Custom Roles — More advanced, enterprise-facing apps will allow admins of customers, to create their own custom role sets and even override existing, pre-defined roles.
  3. Specific Access — Some apps let you choose the specific module/section access for each user. This can be achieved by taking a pure role-based access approach as well, although it sometimes allows for higher granularity on the allowed actions within the product.
Access-based role management in Hubspot. Credit: Hubspot.

Invite Members

The most trivial of functions you must have within your user management is the ability to invite new members. This is important in order to enable full self-service in today’s Product Led Growth movement. There are a lot of mini-features you will need to provide in this seemingly basic functionality. There are also a lot of variations in the user-experience aspect:

  1. Single user invitation —Permission to add one user at a time (usually can add emails and some info on the user, like the assigned roles)
  2. Bulk user invitation — Allowing you to add multiple users at a time. This is usually done by adding a single user email per row or with a separated comma.
Multiple Users invite in Asana. Credit: Asana.

The full flow of new user invitations will be covered in a future post since there are a lot of nuances to take care of from the moment a user is invited, to the moment they are able to login to their accounts.

Shareable Invite Link

A popular approach is to allow users to easily invite other users to their account. Simply publish a link through which new users will be able to connect to an account, or to specific resources within the account. This new feature is becoming  quite popular, mainly due to the increase of popularity for seat-based revenue models. Instead of needing to invite specific members to an organization, just share the link and anyone holding this link will be able to join the account. If you choose this path, there are two important aspects you should consider:

  1. Do the users joining need to be approved? In this case, the link will be used to allow users to request access to join but will not immediately provide them with the final authorization to join.
  2. Don’t forget to allow revocation of the links. For security matters, you should always allow admins to revoke those links to prevent “lost access passes” to your users. I would even advise taking extra security measures here and automatically revoke those links every short period of time.
Invite link feature within Notion. Credit: Notion

Adding Guests

The ability to add temporary users to accounts is becoming very popular these days. Guests are users that have very limited access to an account and your customers will not need to pay for them as part of their seat-based pricing. Usually, you would allow these users to access only specific parts of the account. 

Guests on Monday.com. Credit: Monday.com

There should be a convenient user experience that allows converting guests into normal users in case they need or decide to. You might want to add an automatic expiry timeline for a guest user in order to avoid having forgotten guest users that continue to have access to your customer’s account.

Groups

The ability to assign users to groups and teams is becoming more and more popular these days. Usually, there are two reasons for adding this capability within your SaaS product:

  1. Teams — Some products would want to enable certain product features around teams that were created by their users. Take an example of a developer-platform product that wants to allow users to simulate a real-life mirror of the teams within an R&D organization. Then provide different teams with different views and metrics based on that segregation.
  2. Privileged groups — In many cases certain groups would have predefined roles assigned to them and members that are assigned to a group would automatically inherit the roles assigned to that group. Of course, a member could usually be assigned to multiple groups at once.
Group management in Zoom. Credit: Zoom.

Associated Devices

Another advanced capability that is getting more and more popular, especially in enterprise-facing products is the ability to control the devices connected to each and every one of the users. Besides having the user control the devices they are connected to, in some cases, we would want to allow the admin to control which devices have access to the organizational accounts and have information on the activity from each one of the devices.

Device management in Google Suite Admin. Credit: Google.

Summary

Allowing a full self-service experience within your SaaS product includes having many capabilities you would want to enable for your end-users. The ability for powerful user-management is important to all aspects of making your product enterprise ready; starting from being a great growth-driver for Product-Led Growth, to becoming a crucial-self-service enabler. 

Frontegg provides a full user-management experience with the most advanced & powerful capabilities for end-users. The kicker? Takes only a few minutes to integrate!

The post Top 8 User Management Features Within Your App appeared first on Frontegg.

]]>
https://frontegg.com/blog/top-8-user-management-features-within-your-app/feed 0
A Complete Guide to Implementing Single Sign-on https://frontegg.com/blog/a-complete-guide-to-implementing-single-sign-on https://frontegg.com/blog/a-complete-guide-to-implementing-single-sign-on#respond Thu, 18 Mar 2021 13:10:24 +0000 https://frontegg.com/?p=4695 The way users have logged in over time has largely remained the same. Only the internal workings of this mechanism have been updated to become more robust and secure. From the user’s point of view, they still have to remember some kind of credentials and enter them every time they want to access an application. […]

The post A Complete Guide to Implementing Single Sign-on appeared first on Frontegg.

]]>

The way users have logged in over time has largely remained the same. Only the internal workings of this mechanism have been updated to become more robust and secure. From the user’s point of view, they still have to remember some kind of credentials and enter them every time they want to access an application.

In recent years, another type of authentication has become increasingly popular and has been adopted by more and more applications—SSO or single sign-on.

What is SSO?

From a developer’s point of view, SSO is when an application (service provider) relies on a third-party trusted application, known as an identity provider, to authenticate users. It works on the basis of a relationship of trust between the two parties in which the identity provider takes care of all authentication for the service provider and only passes on information the service provider needs.

This makes obsolete the need for the developer to implement an authentication system and also to manage and secure any private information of the user. 

From a user’s point of view, SSO is when a user logs into an app once and is then automatically logged in to all the other apps that make use of the same SSO authentication mechanism.

How does SSO work?

How does SSO work

SSO can be implemented with different protocols, like OpenID Connect, SAML and so on. Although the implementation works differently across different protocols, behind the scenes, the main idea is the same.

This entire process can be described step-by-step as follows:

On first login:

  1. Your application redirects the user’s request to the identity provider.
  2. The identity provider checks to see whether there is an existing SSO cookie.
  3. Because this is the user’s first visit to the app and the identity provider’s SSO cookie is absent in the user’s browser, the user is requested to log in using one of the connections configured by the identity provider.
  4. Once the user has logged in, an SSO cookie will be set and the user will be redirected to the application, with a token containing the relevant identity information of the user.

On subsequent access:

  1. Your application redirects the user to the identity provider’s page.
  2. The identity provider checks to see whether there is an existing SSO cookie.
  3. The identity provider finds the SSO cookie and checks if it is still valid or it has expired.

4.1  If it has expired then the user is redirected to the login page.

4.2 If the SSO cookie is still valid, the user is redirected to the application, with a token containing the relevant identity information of the user.

In both cases, the user’s first login and subsequent access, there can also be a step 5. The target application can use the token to retrieve the user information on its own or it can send a new request to the identity provider that contains the received token. The identity provider will then decrypt and send the user information.

What are the advantages of SSO?

To quickly spot one of the top advantages of the SSO system, imagine this scenario:

You are a customer who has been admitted to a bar but you are asked to show ID to prove your age every time you try to buy another alcoholic beverage.

This would be irritating for anyone because you understand that what you are doing is a repetitive process, which does not make much sense.

Now imagine that your friend was admitted to another bar that checks a patron’s id just one time and then serves the patron multiple alcoholic beverages throughout the day.

You can equate the second bar to a system that is based on authentication through SSO; rather than verifying the id several times, the user needs to verify their identity just one time and thereafter, they can access a variety of services.

Aside from being simplified and user-friendly, SSO is a great option because it is secure. 

It’s a win-win scenario.

Same sign-on vs single sign-on

Same sign-on vs single sign-on

An SSO mechanism is called single sign-on only if, once you’re logged in, you can access all company-approved applications and websites without having to log in again. Apart from single sign-on, SSO can also mean same sign-on, which works more as a credential vaulting or password manager mechanism. With this mechanism, you may have and use the same credentials, but they must be provided each time you access a different application.

Why should you use SSO?

SSO is a great solution, but only for those who really need it. 

This mechanism is a perfect solution when as an organization you have the same user base for multiple or even all your applications. This will not only give you speed, will also make the system easier to manage and secure because everything is centralized.

Imagine you are an organization, small or big, and you have different internal applications that are meant to be used by all of your employees. Instead of having separate authentication systems on each of these applications, you can have just one central system that will handle the authentication for each of your application.

Code Implementation

If you want to deepen your understanding of an SSO system, here is how a basic one might be implemented at a core level.

We’ll write the code in NodeJS and it will use JWT as a mean of identifying users.

The mechanism will consist of two applications, the identity provider service and an adapter that can be used by back-end clients as a middleware.

Earlier, we saw that this authentication process is done based on some redirects that go back and forth between the two parties and the identity provider returns the information back to the target application.

To do so, we need to be able to send information along these redirects. The convenient way would be to use request headers, but this is not possible in the case of redirects as headers from the previous response are not added to the new request for the redirected location.

Therefore, we are left with two options:

  1. Place the information in the query string for the redirected URL as a parameter. 
  2. Set a cookie. 

In our example, we will use only the first option.

The Identity Provider

A simple setup for this service would look like this:

We have a basic express server that uses cookie-parser module to set and read cookies. We have also included the jsonwebtoken package as it will be used for creating JSON web tokens.

The identity provider must have access to our user base but, for the purpose of this example, we have hard-coded a user on the server. In a real-life scenario, this user would be replaced by a connection to the database from which users are retrieved. Also, the password would have been hashed🙂 .

Because this service will only take care of the authorization, the user information is brief. We only need to have access to the user’s credentials.  If we are an organization and we want to easily identify users we can also assign each of them a unique identifier, a user id that will also be included here.

Login functionality

Users are redirected to a login page if they are not authenticated. The login system can vary based on the needs.

To keep things simple we used a classic email & password combination, which can be sent over a GET request.

Once the user is authenticated against the identity provider service, a request with his credentials are sent to the server along with a redirectUrl. This redirectUrl is the application that the user previously tried to access.

If the credentials match, then a long life token (1d, 12h) is issued that is stored in a secure way. This can be done using several cookie options, like httpOnly in our case, which will make it available only for the back-end code.

In our scenario, this token is valid for 1 day, meaning that once a user has authenticated against an application, he can use any other application that shares the same SSO mechanism for 1 day without being required to re-authenticate.
Handshakes

To complete this service, we need to add two more requests:

  • the main request that will be used by the client to authenticate their user and emit a short life token that contains the user information
  • another optional request that can be used by the client to decrypt the token and get the user information 

The first request /auth will check if the SSO cookie was set. In case it was, the identity provider will emit a short live token that will be sent to the target application (consumer). Otherwise, it will redirect the user to the login page.

The second request /get-identity will decrypt the short live token and return the user information back to the target application.

The client adapter

The client adapter can be used as a middleware to protect the desired resources. This adapter will do the handshake with the identity provider where it will perform a redirect to the /auth endpoint to get the short live token with the user information and then it will do a GET request to decrypt that token and extract the user information.

Wrap up

This was a demo of a basic SSO system implementation to help you better understand this service. In a real-life scenario, SSOs can become more complex as other things need to be added to strengthen the security

If you want to incorporate SSO into your application, you can start by looking at basic examples like this one and build on top of it. Alternatively, if you don’t want to have a dedicated solution, you can look at open source solutions like Keycloak or Shibboleth.

The post A Complete Guide to Implementing Single Sign-on appeared first on Frontegg.

]]>
https://frontegg.com/blog/a-complete-guide-to-implementing-single-sign-on/feed 0
The Full Guide to API Token Generation https://frontegg.com/blog/the-full-guide-to-api-token-generation https://frontegg.com/blog/the-full-guide-to-api-token-generation#respond Thu, 11 Mar 2021 15:48:48 +0000 https://frontegg.com/?p=4539 Why do we use Authentication?To protect our users of course!  All yolks aside, an easy example of Authentication could be email+password authentication.  Our users want to access our product.  We prompt them with an email+password form.  We generate a secure session for them to work with the product. This is all lovely but the rise […]

The post The Full Guide to API Token Generation appeared first on Frontegg.

]]>

Why do we use Authentication?
To protect our users of course! 

All yolks aside, an easy example of Authentication could be email+password authentication. 

  • Our users want to access our product. 
  • We prompt them with an email+password form. 
  • We generate a secure session for them to work with the product.

This is all lovely but the rise of microservices, as well as CI/CD, introduced new challenges. 

We need to be able to authenticate without user presence. This is where API tokens come into play.

There are few use cases that come to mind when discussing API tokens:

  • 3rd party services — every 3rd party that wants to communicate with our service needs to be authenticated
  • CI/CD flows — Another 3rd party use case is when part of the services which run as part of the flows are externals (such as code scanners, deployment tools, etc)

So how do we generate sessions for non-humans and what do we need to pay attention to?

This guide will provide you with most of the “how-tos” in terms of generating and securing machine-to-machine sessions using API tokens.

The OAuth token flow

So we understand that in order to authenticate using API tokens we need to generate them. But which kind of token should be generated? Which flow of authentication do we want to support here?

The OAuth flow is the most common one when it comes to authentication.

The idea is simple.

The unauthorized client gets a ClientID and a Client Secret 🤫
This pair is sent through the Authorization Server 🚫
The client, yet to be authorized, receives an Access Token 🔑
The client uses that access token to access the resource 🙏
Upon validation of the token, the client becomes the resource owner 😎

OAuth token flow

The single token flow

The single token flow basically means that instead of generating client id and client secret, we will be authenticating using a single token.

The idea is to simplify the authentication flow where the client is using a token that doesn’t need to be swapped with a valid JWT through the authorization server.

There are several approaches for this method:

Grant the client a JWT token without expiration during the generation phase, which will then be used as the access token. 

||

Grant the client a token in the generation step, which will then be validated against the central token store.

single token flow

Token types (account / personal)

On B2B SaaS applications, we would find the “tenant” term as the center of the application. Every flow our application is handling, as well as most of the data in the application, will always be in a context of a “tenant”

In this context, when the user logs in to our application, he logs in to a specific tenant, sees data related to that tenant, and manages the configuration of this exact tenant.

Sounds familiar right?

Usually in cases of the tenant-related token, as there is no user context, we would like to be able to have roles/permissions associated with that token as well.

We can a great example on SendGrid when generating a new token:

SendGrid new API token

We generate an API token, which has specific permissions and is on the SendGrid account level (not related to any user)

That means that as long as we are maintaining the SendGrid account, we can use the API token (regardless of the identity of the users who are members of the account)

However, in some of the cases, we would like to allow our users to generate personal tokens in order to perform machine-to-machine operations on behalf of a user and not a tenant.

We can see an example for it on GitHub:

Gitgub new API token
Githu

Or npm:

npm new API token
npm

The token is created on the users’ personal account including specific scopes (permissions).

Important to highlight that with personal tokens, once the user is deleted the token should be deleted as well.

The token repository

So now that we understand the tenant / personal tokens difference and have a high-level view of the authentication flow, we can start and taking a look at the generation of the token.

How should we generate the initial token? Where should we save it? How should we authenticate it?

Generating the initial token (OAuth flow)

Using the OAuth flow, we need to generate clientId and secret. These will be saved to the DB so they can be used on the authentication flow.

Few things to pay close attention to when we design this solution:

  • We would like to generate the client id and secret as 128 UUID (version 4 is preferred to reduce the probability of duplicates — for more info, you can read on Birthday Paradox)
  • Client secret = password(!!!). It has to be saved salted and hashed on the database so it cannot be reversed in case of DB hijack. That means that using the generation process, we will show the secret ONLY ONCE to the user and we will not be able to show it again
  • Token pair association — When storing the token on the DB, we must retain (as in any multi-tenancy / multi-user product) the relation of this token to this tenant/user so we make sure that when generating the JWT for it we sign it for the relevant customer

A lot to think about…

So let’s take a look at how a tenant API token looks like from an entity point of view:

On top of the clientId and secret, we are storing the tenant relation, as well as the scope. In some of the cases, we would like to store the ID of the user who created this token.

So let’s take a look at how a user API token looks like from an entity point of view:

Not much has changed, but now we are saving the user ID instead of the tenant ID (which means we don’t have to store the createdBy anymore)

Cool…

So we know how to create an API token. Good!

Do we allow to change? modify?
Well… No…

By nature, API tokens are immutable objects. In most of the cases, we don’t want to allow modifications on the tokens in terms major changes (updating the display name of the token can work). We won’t let the creator of the token change it’s scopes / clientId / secret etc.

Why? Security first approch…

We want to make sure that once a token is created it is safe to provide it to a 3rd party application without the risk of scopes changing (by mistake OR not) exposing our service to elevated permissions for this 3rd party application…

OK… So we know how to create tokens and save them.
We know how to authenticate it and generate JWT from it.
But how do we handle different permissions and scopes?

Authorization with API tokens

We know that authentication is not enough. We would like to maintain a list of permissions (aka scopes) on the signed JWT so we can work with this list on each of the microservices we would call in order to perform authenticated call

General flow is simple:

Authorization with API tokens

The resource owners’ responsibility in this case is to validate the authentication (using the authentication service public key) and validate the scopes required for accessing the resource (decoded from the JWT token)

Looks simple right?

Well, it is. Even when looking at it from code perspective:

The middleware above is validating the authentication header, extracts the scopes and matches them to the requested scopes by the caller.

The revocation

So we are getting close!

We have a full flow working end to end from the generation, through the authentication and even through validating the authentication and authorization!

By how do we revoke access token?

Let’s say we created a token with default JWT expiration of 7 days.
We would like to revoke it after a day… Looking at the flow above, once the 3rd party application got hold of JWT, it lives for that 7 days and now the resource service has no way of knowing this JWT is not valid anymore.

Few potential solutions here:

Shorter JWT tokens + longer refresh tokens

Using shorter expiration tokens on the JWT + longer refresh tokens will allow to shorten the exposure window from the revocation of the token. The 3rd party application in this case is required to constantly refresh the token (using the refresh token) in order to retrieve a new JWT

Using shorter expiration tokens on the JWT

Centeral token repository

Implement Central token repository which holds the deny list (aka as CRL). In this use case for each revocation of token, we would like to update the deny list that this token is revoked. Now we are passing another responsibility to the resource service to verify the validity of the token.

2 possible approaches here:

API-GW first:
The recommended flow is to hold the CRL on the API-GW and update the list on each revocation. That means that each request to the resource MUST pass through the API gateway and each revocation should update the CRL (which is used by the API GW):

API-GW first

Central token repository:
Using the central token repository approach, the CRL is saved on the authentication service (on the same service which holds the actual tokens).
This practice makes this service as Single Point Of Failure for the entire application. Meaning that each request must pass through this service and each service on our cluster MUST know how to communicate with this service (takes back to the world of monolith application…)

Central token repository

While this may not look so complex with single resource service, with multiple services it looks like this:

Do you happen to know an architect that would sign off this architecture? Risking tightly coupling services to end up like this:

Tracing API tokens activities

The last step we want to make that we have on our API tokens checklist is traceability

Keep in mind that API token authentication eventually is another method of authentication in our system. That means that as we are auditing every user authentication (email, password), we MUST audit every API token activity.

API tokens can be destructive just the same as administrative actions performed by users, so bear in mind that there are few items on the traceability checklist (I call it the 5-w checklist):

  1. The who — Which user created this API token? Listing the user which created the API token can help us identify issues with identifying destructive operations by suspicious users on the system.
  2. The when — When this API token was created? Listing the timestamp can help to track potential issues with timeslots where we suspect changes were made in the system.
  3. The what — What scopes this API token was created with? Listing the scopes helps with identifying potential issues with elevated permissions granted to this API token.
  4. The where — Where that API token was accessed from? Which IP address? This is extremely useful for detecting anomalies and providing deny list for specific countries/networks.
  5. The how— How was that API token used? When it was authenticated last? How was that used in the system? Which APIs were accessed using that API token?

Summary

The complexity of authentication and identity management in the products build are not the same.

We are using way more microservices now; therefore, we need to make sure that the line of communication between our microservices is authenticated and secured.

More and more 3rd party services are being used, so we need to make sure that when we are consuming these services, we are doing so using the correct authentication and permissions.

This requires us to use machine-to-machine authentication methods which will allow us, as developers, to consume these services securely.

In this post, we talked about scoping, auth flows, revocations and traceability. We walked through the items necessary to ensure a successful design and implementation of the machine to machine authentication and authorization mechanisms,

and it was lit. 🔥

Got questions?
We are here! Feel free to drop us a line.

The post The Full Guide to API Token Generation appeared first on Frontegg.

]]>
https://frontegg.com/blog/the-full-guide-to-api-token-generation/feed 0
‘The Product’ in Product Led Growth (PLG) https://frontegg.com/blog/the-product-in-product-led-growth https://frontegg.com/blog/the-product-in-product-led-growth#respond Thu, 25 Feb 2021 11:06:39 +0000 https://frontegg.com/?p=4479 I call it the “Cyber of 2015”, the “Machine Learning of 2020”… well you get the idea — Everyone’s talking about Product Led Growth as the hottest topic around. It seems pretty clear that this is a very strong movement in the SaaS world and we’re only beginning to see the light. In general, for […]

The post ‘The Product’ in Product Led Growth (PLG) appeared first on Frontegg.

]]>

I call it the “Cyber of 2015”, the “Machine Learning of 2020”… well you get the idea — Everyone’s talking about Product Led Growth as the hottest topic around. It seems pretty clear that this is a very strong movement in the SaaS world and we’re only beginning to see the light. In general, for those who didn’t catch my drift, we’re talking about a business movement primarily driven by user adoption of a product rather than being driven by the force of sales or marketing. Usually, the typical examples of the best performers of PLG are companies like Slack, Dropbox and Calendly.

Money and Customers? Let the VP Marketing/Sales handle it…

The usual consensus behind generating growth, pipeline, and customers is that Marketing drives leads, Sales run the show, and all is well in the world. Although there are a lot of concepts here that are being pushed by Marketing Departments which might strongly affect the structure and workflows of the Sales organization, people are often missing a very important part of the story: The “Product” in Product Led Growth is a vital player in this game. 

Here are a few examples that will clearly illustrate why the discussion around the main concepts of PLG should not stop at the Marketing/Sales level:

Example #1: Try before you buy

One of the main aspects of PLG in the SaaS world is the need for users to try out and test products before they pay for them. This is a simple concept to grasp and the implications it has on the economic foundations of the business are massive. Customer testing of products before committing to purchase them must put the customer at center stage. Marketing tactics, sales pipeline and processes, product roadmap – all change when choosing the PLG path, thereby shifting a companys’ strategy and plans. 

That being said, how can we talk about giving customers a product trial period without discussing important product experience aspects such as:

  • Easy sign-up to new accounts
  • Ability to lock/unlock certain features dynamically
  • Ability to monitor my features usage and get notified when reaching the limit 
  • Ability to shut my account dynamically if I don’t like the product

If you read the list of experiences above and felt like you could relate, then keep reading.  Remember that when considering a ‘Free trial’, or a ‘Freemium’ model, these elements make it even more crucial at a very early stage, setting the grounds for upgrading your users into paying customers. 

Example #2: Self-service

Another important focus of the PLG is the ability for the user to have an AMAZING self-service experience within the product without the need for a dedicated customer-success, technical support or an onboarding specialist to help make it happen. Users want little-to-zero dependence on you in order to have a  successful experience using your product. This concept affects important SaaS metrics such as CAC, the structure of the sales and customer success teams and a lot more.

But then again, there are important product concepts around this topic, that include:

  • Seamless onboarding and walkthrough flows that make sure I have the best experience once I’m signed up
  • Great documentation inside and outside the product to provide both a toolkit and best practices to fully utilize your product. 
  • A full profile management portal 
  • A full account management portal to allow the admin of the account to control every company level setting

While these may sound that’s overdoing it, not being able to add team members or change basic settings in your product, could really hurt your chances of winning an account. In order to give users a true feeling of independence, the above capabilities (and many others) have to be provided as part of the product self-service experience.

These two examples above are just the tip of the iceberg when it comes to assessing the implications of every core aspect of PLG on the product itself.

Always start with the why how…

Product Led Growth

If you understand the concept behind Product Led Growth and you think that this is the right path for your company, especially on the business side,  you’ll need to shift your way of thinking about the product that you’re building.

You need to understand that embracing the PLG concept within your organization affects the basic foundations of the way you plan, design, build and monitor your product.

The “non-core” becomes the “core”

When building capabilities within your app, it’s common to think that that “non-core” capabilities are less important than “core” product capabilities. But when wanting to build a strong PLG motion within your product, you have to acknowledge that some “non-core” capabilities have to be promoted to first-class. This is especially true for features that strongly affect the way your product is consumed and the user journey within. So the time and thought invested in onboarding features, alerts, self-service signup, setting up roles and permissions and user management need to be thorough.

Take a product like ClickUp (used by Frontegg from early days) which provides an amazing experience for personal and organizational account setting. Their product provides users with the ability to easily invite team members and control billing and security aspects, all of which were vital for our experience with them from day one and up to the point of growth and vast usage.

Clickup saas platform

ClickUp: An amazing account management experience.

The metrics are supercritical

Providing a great experience and tons of capabilities is not enough anymore. You have to be able to monitor and analyze every little movement of the user within your app. Which features are being used, which are misunderstood, what is causing frustration and what is eliciting joy in your users? This is the only way to make sure you’re doing everything to provide an amazing experience for your end-user and it will play a major part in converting them into paying customers later.

The UX is critical

Checking off your yearly product roadmap feature plan is no longer good enough. Every feature has to be designed with great thought and creativity to make sure that the end-user experience is vividly clear and no less than amazing. Make sure you create a toolbox of design patterns that repeat themselves across the app, to ensure that your users get a sense of what it means to “use your product”. No surprises, keep it consistent and clear.

Product Led Growth is critical, hence your Product as well

When embracing the Product Led Growth approach, make sure that the product is capable of leading growth. You need to invest thought and acknowledge the fact that the product will be highly affected by the move. From hiring the right people, to planning and prioritizing the backlog, from the design and specifications of each feature to the building and the measures and monitoring. Every aspect is vital to making sure that users will fall in love with your product and spread the word among their colleagues, thereby increasing usage and leading to them eventually asking their boss for the company credit card.

Frontegg as a Product Led Growth Enabler

Besides believing strongly in the concept and putting a lot of effort into embracing this for our product, the Frontegg platform is perceived by many as an enabler of the “product aspects” we covered in this blog post. We meet companies that strive to enable powerful self-service experiences within their products, and our platform helps them do so easily in more ways than one.

The post ‘The Product’ in Product Led Growth (PLG) appeared first on Frontegg.

]]>
https://frontegg.com/blog/the-product-in-product-led-growth/feed 0