Test Drive: Web-Scale Authentication and Authorization With FusionAuth
Posted 2 years ago by Ľubomír Mlích
Every web application is intended for humans. If interaction is expected, the application obviously needs to authenticate users, create accounts for them, and keep their credentials secure. This can be a complex task due to security and privacy concerns. While it is possible to create our own solution, it is much easier to use one of many ready-to-use solutions, that is if we have enough trust in it. Authentication vulnerability can bring our business down, so we should take our time to choose well. Also nowadays, people perceive IAM as a revenue generator too. In this article, we introduce one of them; FusionAuth, and show how it can be used.
At profiq, we consider ourselves subject matter experts in the identity and access management. We’ve been working with mature access management and identity management products for nearly a decade, and are always interested in exploring new and emerging technologies in this space.
We recently learned about FusionAuth, a Colorado startup with nearly 100k downloads and numerous accolades, including the Enterprise Security magazine’s Identity and Access Management 2019 Product of the Year, and two awards from CompareCamp.com — Rising Star 2019 and Great User Experience. We were curious about this highly-lauded solution, and decided to take it for one of our test drives.
FusionAuth is a free CIAM platform which has the following features:
- It is easy to install.
- It uses standard methods of authentication that work well, and are designed with security in mind.
- It has a UI that works with a variety of displays, including personal computers, mobile phones, and tablets.
- It supports login, registration, localized email, MFA, and reporting.
- It enables easy-to-use social authentication with Google, Facebook or Twitter.
- It is free, as in beer :).
- It is ready to use in the cloud.
Rather than use long-standing terminology like directories and realms, FusionAuth characterizes objects as follows:
- Users – Someone who can authenticate
- Applications – Where a user authenticates and how they are authenticated
- Registrations – How a user gets access to an application and the roles a user can access
- Tenants – How FusionAuth logically separates users, applications, and registrations
For example, we might have two tenants in our deployment. Inside each of the tenants, we might have an application named Foo, and a user with the email address email@example.com. Each of these users might have registered to the Foo application. And finally, each of these users might have different passwords and data. Email is used as default login credential, and the same email but with a different password can be used to access applications in different tenants, as these are different users. See the schema below:
With FusionAuth, we can use an admin web UI to administer these objects. Although there is no CLI available for automation of these tasks, you can use a REST API instead.
There are few installation options that depend on the platform we’ll run FusionAuth on. All platforms are supported, as Java, Tomcat, and Elasticsearch are working in background:
- Cloud – You can buy a ready-to-use instance (depending on your requirements) and leave the task and worries of providing hosting to FusionAuth.
- Docker – You can use your own server and let Docker create instances for you.
- Package – You can install a package that is ready for your operating system: Brew on macOS or RPM/DEB on Linux.
- CLI – You can use a one-line command to download and install an application using Bash or Powershell.
After running installation script from CLI, which downloads everything, there is one more configuration wizard waiting – to set an administrator account, correctly configure access to our database, accept the license agreement, and choose whether we wanted to receive news about FusionAuth. And that all. Now we can start adding applications, users, set up email, enable API keys to use APIs, and configure other settings to our liking.
Integrating FusionAuth with our Application
All right; now we have a nice, ready-to-use platform for user and role administration and authentication. How can we connect it to our application and start using it? As you can see at fusionauth.io, FusionAuth offers many different methods for login and authentication and we decided to use authorization code grant flow as it is good for web application.
Example of an authorization code grant flow
The authorization grant flow is based on the OAuth standard RFC6749:
- The application determines whether the user is logged in. If yes, the JWT is valid. If not, the user is redirected to the authentication URL. The URL for authentication can be found in application details as OAuth IdP login URL. It will be:
- Redirect the URL to be set in the Edit Application form. If you do not do this, an invalid redirect URL error will display.
- After entering the URL in a browser, the user can log in with the FusionAuth login form, and will be redirected to our application afterwards with the code GET parameters in the URL. For example https://my.app.me/?code=ZOLpXdYBdzxvQgoTxIecNrIKTpCtO4RRiIZgZZ3CtsM&userState=Authenticated.
- Our application will use received (authorization) code to get access token of user. For example:
$ http -f POST https://fusionauth.me:9011/oauth2/token \
- The access token in the reply is a JWT containing JSON with information about the user and the roles assigned to them for this application. JWT can be decoded at jwt.io. Our application should decode it, and verify that the signature and that the JWT have not expired.
In this way, the user will only share their credentials with FusionAuth. Our application uses temporarily valid tokens that are issued by FusionAuth. An access token is valid for one hour. If we want users to have longer sessions, we can change this in the configuration (after considering the security risk), or use a refresh token to prolong the user session without asking for credentials again.
Exploring FusionAuth Features
FusionAuth’s SSO feature lets users access the second application without entering credentials again. If a customer is already logged in to one of our applications and thus has an active session in FusionAuth, they will get an authorization grant code without needing to enter credentials after accessing OAuth IdP login URL to the second application.
Third-Party Identity Provider
It is very annoying to create an account for every web service that is available on the internet. If we want to simplify the life of our users, it is possible to configure FusionAuth to use a prevalent internet service to log in. This configuration can be seen as controversial for those who value their privacy. However, FusionAuth lets us choose our own path, and this feature can be configured to have different requirements. For example, in our application, if users want to use Google to authenticate, they will not be able to do so unless they have a Google developer account:
Reporting and Auditing
FusionAuth uses Elasticsearch in the background to store usage data and to display usage reports. These reports let you see your applications’ usage, which can be useful for resource management:
It is also important to be able to see who is responsible for configuration changes, and FusionAuth contains complete log of configuration changes in JSON format with previous and afterwards configurations, so we can see exactly what changed and stay on top of these changes.
We introduced you to FusionAuth, and took it for a trial run using a simple deployment with basic features. We explored the available options that web application developers can choose from. Although we did not try every available option, or dive into a complex configuration or performance testing, we can say the following:
- Deployment was very easy.
- Documentation is good; there are few topics in the blog which should also be in the docs, in our opinion. In addition, only the documentation is searchable, so it is good to take a look at the blog separately. That said, the docs are still solid enough to get you started.
- The FusionAuth community was helpful when we could not solve a problem on our own.
- Admin UI is intuitive. There are few buttons which purpose have to be discovered, this journey does not take long time.
- The lack of a CLI seemed like a gap to us at first, but after exploration of FusionAuth, we saw that the API could be used to automate repetitive tasks instead.
- It looks like a neat solution for small or mid-sized businesses.
Web Master, Enterprise Application Admin, QA Engineer