How We Implemented Authentication and Access Control at Blink

Authentication vs. Access Control

In today’s cloud-native world, almost every application is connected and registered to a number of different cloud services, with each service requiring some kind of Authentication method. Authentication is a ubiquitous step in most cloud transactions, and choosing how to implement Authentication and Access Control is one of the earliest and most important architectural decisions that our engineering team made at Blink.

Before we discuss the Blink application, it’s helpful to have a common definition of Authentication and Access Control. For our purposes, we’ll be using the following definitions:

• Authentication is the process of identifying users when they request access to a system, network, or device.
• Access control determines user identity according to credentials like username and password. Different users may have different levels of access based on their role and responsibilities within an organization.

Authentication and Access Control requirements

Let’s say you are working for a startup and you need to enable a way for users to Authenticate with your product.

Will you have a simple email signup with password or support third-party authentication? For example, will you allow users to sign up with existing credential like their Google, GitHub, Twitter or other social accounts? Decisions such as these can have a major impact on how users onboard, login, integrate with third-party tools, and use your product.

Now aware of the many options available, you start doing research to understand how you want to implement Authentication and Access control. This is when you find about the exciting new world of Identity Providers and how each one works.

Identity Providers

There are a number of Identity Providers (or IdPs) available to choose from based on your cloud application’s specific requirements.

Auth0

Auth0 is a customer identity access management (CIAM) platform that was acquired by Okta in 2021. Auth0 is easy to implement and flexible for supporting most applications’ Authentication use cases.

AWS

You may not think of AWS as an Identity Provider, but Amazon offers authentication services like AWS SSO to help you manage workforce identities in AWS and manage access centrally across your AWS organization.

Google

Google provides the option to identify with your Google Account which will look like <name>@gmail.com

Or if you work at a company you will probably use your Work Google Account which is held by Google Workspace and will look like <name>@<company>.com

Okta

Okta provides cloud software that helps companies manage and secure user authentication into applications, and for developers to build identity controls into applications, website web services, and devices.

Depending on your cloud application’s specific requirements, you may also be interested in other Identity Providers like JumpCloud, VMWare Workspace One Access, and there are many more to suit your individual needs.

Authentication Methods

In addition to managing and protecting the identity of your users, there are countless ways of validating that a user actually is who they claim to be. Let’s dive into some of the more common authentication methods, one or more of which you may consider implementing for your own cloud application.

Password authentication

Anyone who uses the internet is familiar with passwords, the most basic form of authentication. After a user enters their username, they need to type in a secret code to gain access to the network.

Two-factor authentication (2FA)

Two-factor authentication builds on passwords to create a significantly more robust security solution. It requires both a password and possession of a specific physical object to gain access to a network—something you know and something you have, like access to a password manager app, an SMS message to your physical mobile device, or a secret numerical key.

Single sign-on (SSO)

Single sign-on (SSO) is a useful feature to consider when deciding between device authentication methods. SSO enables a user to only enter their credentials once to gain access to multiple applications. Consider an employee who needs access to both email and cloud storage on separate websites. If the two sites are linked with SSO, the user will automatically have access to the cloud storage site after logging on to the email client. SSO saves time and keeps users happy by avoiding repeatedly entering passwords.

Security Assertion Markup Language (SAML)

SAML is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:

• No need to type in credentials
• No need to remember and renew passwords
• No weak passwords

Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users in to other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML.

Authentication and Access Control at Blink

At Blink we chose Auth0 to be our Identity Provider and we support Password, SSO & SAML authentication.

We decided on Auth0, because it gave us the ability to support a variety of Authentication platforms and utilize Auth0’s login capabilities within the Blink application.

It was important to our larger enterprise customers that Blink support SAML authentication. In addition to being very powerful and flexible, SAML provides enterprises with the option to give all of their employees access to Blink, with the correct permissions, without registering or inviting each employee individually.

Once we determined SAML support was a requirement, we did quite a bit of research about potential solutions before deciding on Auth0. Specifically relevant to our use case, Auth0 implements a feature called Enterprise Connections which identifies each SAML configuration for each Customer.

We want our customers get the best user experience possible, so when it came to implementing the UX around Blink authentication, we chose to add a simple form that asks the Customer to provide their IdP and relevant information. Once everything is filled in, we are ready to use SAML with no problem.

Today we support both Username & Password, and SSO & SAML Authentication.

For SSO we decided to support only GitHub & Google.

What could have gone better?

Surprisingly, Auth0 doesn’t really offer a lot of documentation related to their support for SAML or how to integrate with other Identity Providers. But after some additional research, I’m happy to report that this solution worked pretty well for us. One thing you should look out for is that you need to make sure you are using your Custom Domain when setting up SAML authentication.

Another issue we encountered was around setting up Email Verification when using SAML. Auth0 doesn’t really support Email Verification for customers that are connected through SAML authentication, so this was one security limitation that we needed to overcome. Eventually, however, we were able to identify a different solution for email verification.

Conclusion

Authentication always seems to be more difficult than you realize when you set out to implement it. If you’re working at a platform startup and have yet to solve for Authentication, make sure you are going over all of your use-cases and future use-cases, so you will be prepared and choose the best IdP for you.

We researched a lot of different IdP providers (KeyCloak, Okta, Auth0, etc.) before settling on the provider that made the most sense for us. In the end, we chose Auth0 because it was the simplest option for our needs.