Laravel + FusionAuth, the Laravel way

If you’re trying to find out how to add user management, authentication and all, to your Laravel app, you probably already came across a few articles and blog posts that can absolutely get you to a working setup. Here, I would simply like to share a solution that is largely based on the official guide from FusionAuth, with the addition that it better follows the Laravel way of doing things. As a bonus, you will find a docker-compose setup with which you can run your Dev environment on any system which supports Docker. All the source files are available at Gitlab. And… folks, be prepared for a long read.

FusionAuth, as described on their website, is “the customer authentication and authorization platform that puts developers in the driver’s seat, with control, flexibility and developer ergonomics”.

I have just added FusionAuth to one of my personal Laravel projects. For that, I had to study some materials I found on the internet, combine them together and bring to a state where I could finally say that I am more or less happy with the result. In this post, I will try to go through setting up a completely fresh Laravel project (+Vue.js +inertia.js, if that matters). We’ll go step by step until we reach a healthy app which performs user authentication with FusionAuth (let me please refer to it as simply “FA”, for brevity). A significant part of this post will be dedicated to Docker and docker-compose which I used to make a setup that is easily reproducible on nearly every computer.

I will assume that you are familiar with at least the basics of PHP and Laravel, Linux, command line, Docker and Docker-compose. Also you’ll need Composer, the brilliant PHP package manager, to be installed. This article is targeted at intermediate/advanced PHP developers that are still figuring out their path with Docker and modern backend & frontend tech.

Step 1. Install Laravel

First thing I did was to create a fresh project in Gitlab, for the sole purpose of this blog post: https://gitlab.com/crocodile2u/laravel-fusionauth. Opened a terminal and cloned it to my laptop:

git clone git@gitlab.com:crocodile2u/laravel-fusionauth.git

At this point, the repo is nearly empty, with just the default Gitlab’s README.md: https://gitlab.com/crocodile2u/laravel-fusionauth/-/tree/step-0

Next, I am going to add Laravel to this brand new project. I’ll be using Composer for this:

cd laravel-fusionauth
composer create-project --prefer-dist laravel/laravel
cd laravel
find -mindepth 1 -maxdepth 1 -exec mv '{}' ../ \;
cd ..
rmdir laravel

Line by line:

1. Change working directory to that of our new git working copy
2. In that directory, install Laravel, it’s going to be placed inside a new subfolder laravel
3. Change working directory to laravel (it will contain the familiar app, routes, artisan etc
4. Move everything from this folder, including files that start with a dot (so-called “hidden” files), to the parent directory — our working copy
5. Change working directory to parent directory — our working copy
6. Remove the [now empty and redundant] laravel subdirectory.

Let’s verify that the framework has been installed correctly and works fine:

./artisan serve

   INFO  Server running on [http://127.0.0.1:8000].  

  Press Ctrl+C to stop the server

And if you visit http://127.0.0.1:8000 in your browser, you should see the familiar default Laravel welcome page. At this point, the project looks like this: https://gitlab.com/crocodile2u/laravel-fusionauth/-/tree/step-1.

Step 2. Install Laravel Breeze

Laravel is super handy when it comes to repetitive tasks that sometimes include a lot of boilerplate. For example, Laravel has Starter Kits, which help you out with the boring stuff. We’ll be using Laravel Breeze in this tutorial, which provides everything our app will need in regard to user management such as login & register templates (actually, there’s much more, check it out in more detail). From the project root directory, run this commands:

composer require laravel/breeze --dev
./artisan breeze:install vue

This will install the laravel/breeze package in development mode only, because we won’t be needing it in production. The second line runs a CLI command from the newly installed Breeze package, and it will add Vue.JS support to our project, as well as Inertia.JS, and publish quite some new configuration files, tests, routes and Vue components to our application. Once you’ve done that, open two terminal windows/tabs, because we’ll need to run both PHP/Laravel backend server and the NodeJS development server which supports hotreload and will recompile our Vue components as we change them:

./artisan serve

   INFO  Server running on [http://127.0.0.1:8000].  

  Press Ctrl+C to stop the server

npm run dev

> dev
> vite

  VITE v4.0.4  ready in 338 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help

  LARAVEL v9.47.0  plugin v0.7.3

  ➜  APP_URL: http://localhost

Again, open http://127.0.0.1:8000/ in your browser. Our application has just become a modern Single Page App powered by PHP & Laravel on the backend and by VueJS, Inertia & TailwindCSS on the frontend. Verify that the hotreload is working: modify resources/js/Pages/Welcome.vue f. e. by changing the link “Register” text to “Join” (must be around line 33 in Welcome.vue). Save the file, switch to browser and you should be already seeing the updated text “Join” instead of stock “Register”. This is our project code at this stage: https://gitlab.com/crocodile2u/laravel-fusionauth/-/tree/step-2.

Step 3. Dockerize our project

One can argue that Docker can be unsafe, and that it is unnecessary and that it brings extra complexity, but we live in a dev world where nearly everyone uses it. I personally enjoy using Docker for the reproducible environments it brings. For our small project development, Docker will have three main advantages:

1. Easily run on every system that has Docker and Docker-compose;
2. We will no longer have to open two terminal windows in order to run our stuff in dev mode.
3. We’ve come a long way and we haven’t yet even mention FusionAuth, the key goal of our project. Well, trust me, things are going to be easier for us with FA, if we have Docker prior to it ;-)

First thing I’ll do about dockerizing our app is I’ll add a Dockerfile:

# we start off from a CLI PHP image based on Alpine Linux distro
FROM php:8.2-cli-alpine AS php_base

# Create directory where our project will reside _inside_ the container
RUN mkdir /project
# Tell docker to cd to that directory
WORKDIR /project

# If our PHP installation needed any extra PHP extensions not available
# in the default docker image, we would add those here

# For the sake of simplicity, and not to dig into Docker setup too deep,
# I am only providing a minimal setup here, suitable for development.
# For production, you would probably want to start from a PHP-FPM base image,
# or even make a Nginx Unit image which can embed PHP module.

FROM php_base AS dev

# In dev mode, we are going to mount project directory as volume,
# inside the container
VOLUME /project
# ... and we're telling here that this image is going to run a server
# that listens on port 8000
EXPOSE 8000

# For development, I always install XDebug, this just helps A LOT, always
# here, I also provide a few settings for XDebug which should
# work with any recent Docker version and make the debug client able
# to connect to your editor/IDE of choice.
# The main trick here is using "host.docker.internal" as xdebug.client_host.
# Up until recently, this DNS entry was not available in Docker under Linux,
# but now it seems like we're good to use it. This host name should resolve
# to the docker daemon host machine address.
RUN apk add --virtual deps $PHPIZE_DEPS linux-headers && \
    pecl install xdebug && \
    echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
    echo "xdebug.mode=develop,debug" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini && \
    docker-php-ext-enable xdebug && \
    apk del deps

# and this is the command we want to run in our container
# we listen on port 8000 (see the EXPOSE directive above),
# and we listen on all interfaces. If we skiped the --host switch,
# artisan would only listen to connections from localhost.
# REMEMBER: inside container localhost===[container host],
# and we will be connecting to this server from the host machine! 
CMD php artisan serve --port=8000 --host=0.0.0.0

Let’s check if Docker can build this image:

docker build --tag laravel_fusionauth --target dev .
Sending build context to Docker daemon  108.1MB
Step 1/8 : FROM php:8.2-cli-alpine AS php_base
# ... output truncated
Successfully tagged laravel_fusionauth:latest

In order to run the full project, it’s nearly never enough to run just the backend service, in our case it’s PHP/Laravel. Moreover, we already know that for a modern frontend, we needed to run another service ( npm run dev, remember). Most of projects will need a database, maybe a caching layer, an SMTP server, you name it. To keep it all manageable and easily reproducible by every engineer in the team, with a single command, we’ll use docker-compose. Create a docker-compose.yml in the project root folder:

version: "3.7"
services:
    backend:
        # instruct Docker how to build the backend service image
        build:
            # Context is our project folder.
            context: .
            # Remember, on line 17 of the Dockerfile, we have:
            # FROM php_base AS dev
            # Here, we tell Docker which exact build target we want to build
            target: dev
        ports:
            # <port on host>:<port in container>
            # here, they are the same, but they don't have to.
            # f. e., 80:8000 means that on the host, port 80 is mapped to container's port 8000.
            # Remember, on line 24 of the Dockerfile, we have EXPOSE 8000
            # and also, our command line for the server is (line 42):
            # php artisan serve --port=8000 --host=0.0.0.0
            - 8000:8000
        volumes:
            # <directory on host>:<directory in container>
            # Here, our project folder ( ./ ) is mounted as a volume
            # at /project to the backend container
            - ./:/project
        extra_hosts:
            # on Linux systems, host.docker.internal will NOT resolve to the host machine IP,
            # without this line
            - "host.docker.internal:host-gateway"

We have docker-compose to instruct docker on how to build the backend image, mainly we specify context and target . Docker-compose will take care of properly tagging the image that it builds. OK, lets build the same image, but this time using docker-compose:

docker-compose build 
Building backend
Sending build context to Docker daemon  108.1MB
Step 1/8 : FROM php:8.2-cli-alpine AS php_base
# ... output truncated
... built successfully

In order to run our infrastructure in dev mode, we use docker-compose up command. Only remember to open both of the previously open terminal windows/tabs and stop the server processes by pressing Ctrl + C . Otherwise we’d make an attempt to listen to port 8000 on host, which is already used by artisan serve .

docker-compose up
Creating network "laravel-fusionauth_default" with the default driver
Creating laravel-fusionauth_backend_1 ... done
Attaching to laravel-fusionauth_backend_1
backend_1  | 
backend_1  |    INFO  Server running on [http://0.0.0.0:8000].  
backend_1  | 
backend_1  |   Press Ctrl+C to stop the server

If you now visit http://0.0.0.0:8000 or http://127.0.0.1:8000/ in your browser, you’ll see a blank page and errors in JS console, like these:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading 
the remote resource at http://127.0.0.1:5173/@vite/client.
(Reason: CORS request did not succeed). Status code: (null).

Maybe that’s because the Vite server is not running? Well, we wanted to have it managed by our docker-compose setup anyway, so let’s do it now. Press Ctrl + C and docker-compose will stop. Then open the docker-compose.yml file and add another service:

    vite:
        # we'll use stock 'node' image from dockerhub, it has both NodeJS and Npm,
        # which is enough for us
        image: node
        ports:
            # just like our Vite server that we were running on the host,
            # we're going to use port 5173, on both host and the container
            - 5173:5173
        volumes:
            - ./:/project
        working_dir: /project
        command: npm run dev

Now, let’s run docker-compose up , again. It should succeed and you will see log messages from both backend and vite services starting up. The problem is that if you visit http://0.0.0.0:8000 or http://127.0.0.1:8000/ in your browser, there’s still a blank page and same console warnings. Well, let’s see closer to it. Honestly, I was puzzled with this behavior for a while, because the Vite documentation says that CORS is enabled by default on the dev server.. So, what does a developer do when they get stuck? Right. They search the web. I found these two pages to be helpful:

• https://sinnbeck.dev/posts/getting-vite-and-laravel-to-work-with-lando
• https://laracasts.com/discuss/channels/vite/laravel-vite-issue

So, I added these minimal extra config to vite.config.js, right next to the plugins entry:

    server: {
        host: true,
        hmr: {host: 'localhost'},
    },

See the full file at this step here: https://gitlab.com/crocodile2u/laravel-fusionauth/-/blob/step-3/vite.config.js

And overall, our project now looks like this: https://gitlab.com/crocodile2u/laravel-fusionauth/-/tree/step-3.

We now have a dockerized app which should run with a simple command docker-compose up on any system that support Docker.

Step 4. Install FusionAuth

Getting there! If you already tried to click through the links like “Log in” or “Register” in our app, you might have noticed that there is a full set of pages to manage users. Take http://localhost:8000/register , you may fill in all fields, press “submit”… and be presented with a nice error screen:

QueryException: could not find driver

So, we’re still using the Laravel Breeze default UserProvider which is based on a database. Our project, on the contrary, does not need a database, we want FA to store user data for us! FA has a nice set of docs, with this page focusing solely on FA in Docker.

Because FA is a complex software which relies on their own code + a database + ElasticSearch, they also offer us a docker-compose setup, check it out!

And, as you have already guessed, once we’re done with installing FA in our project, we’ll be adding some PHP code to our app, to implement a new UserProvider, a FusionAuth one.

I added all services, network configurations and volumes from the FA’s docker-compose.yml, to our own docker-compose.yml. With a few small changes:

• I prefixed all FA services with “fusionauth” so that it can be clearly seen from the service name itself that it belongs to FA. Because simply “db” would be misleading and easily confused with our application’s DB. Same goes for networks and volumes. ENV variables that FA uses, I also prefixed with “FUSIONAUTH”. Basically, everything related to FA, will now have a meaningful prefix.
• I had to add “hostname” entry for most of services, because underscore is not a valid symbol for a domain name, so you cannot name domain “fusionauth_db”, but we still have to connect to the DB. hostname: fusionauth-db solves this problem. Same way, in this docker-compose.yml you will find connection settings for the database and ElasticSearch, and I updated them according to the new hostnames. Now they are jdbc:postgresql://fusionauth-db:5432/fusionauth and http://fusionauth-search:9200.

The full updated docker-compose.yml at this stage you can see here.

Our docker-compose.yml now relies on quite a few ENV variables, we should add them to .env file. I also added them to the .env.example :

FUSIONAUTH_APP_ID=unknown-yet
FUSIONAUTH_API_KEY=unknown-yet
FUSIONAUTH_BASE_URL=http://fusionauth:9011

################################
# Below -> Fusionauth services #
################################
FUSIONAUTH_POSTGRES_USER=postgres
FUSIONAUTH_POSTGRES_PASSWORD=postgres
FUSIONAUTH_DATABASE_USERNAME=fusionauth
FUSIONAUTH_DATABASE_PASSWORD=fusionauth_db_password
FUSIONAUTH_ES_JAVA_OPTS="-Xms512m -Xmx512m"
FUSIONAUTH_APP_MEMORY=512M

Notice that the fusionauth service in the docker-compose.yml has a port mapping 9011:9011, which means it can be accessed from the host machine on port 9011: http://localhost:9011. And yet, for our application, the config says FUSIONAUTH_BASE_URL=http://fusionauth:9011. This is because our application will be running in docker, using the docker network created by docker-compose. And the FA’s API host will be resolvable exactly as fusionauth from within our Laravel backend container, and not as localhost , because from inside the backend service container, localhost is going to be that same container and nothing else. If you’re not yet into docker networking, just think of all those services/containers as of separate Linux computers connected by different networks, so that from one network you can only see that network members, but one computer can be registered in several networks — this might help you understand the infrastructure better. Take a look at compose documentation on networking. Here is a graphical scheme of our project’s infrastructure to this moment:

Project infrastructure created with docker-compose

Let’s shutdown our docker-compose stack by switching to terminal and pressing Ctrl + C. Then start it again: docker-compose up. This time it’ll probably take a longer while and you’ll quite a long list of log messages. That’s because there are now 5 services to start, also when you start FusionAuth for the first time, it performs certain initialization for all its services.

We’ll need to make one extra step, which is setting up FusionAuth admin account and creating the API key which our Laravel app will be using. Open http://localhost:9011/ in your browser, you should be redirected immediately to http://localhost:9011/admin/setup-wizard. Fill in al fields and submit the form. If no errors, you’ll se the admin dashboard, which will give you a friendly hint on what to do next:

FusionAuth hints to complete setup: create application, add API Key, setup SMTP server.

So, I clicked on the first “Setup” button and created an application and named it “Laravel Fusionauth”:

FA Applications list after adding the Laravel Fusionauth app

Copy the app id from this table and paste it to your .env file (we already have a line with FUSIONAUTH_APP_IDvariable):

FUSIONAUTH_APP_ID=1ef65db6-dcc4-417c-b54b-282d80838917

Now, go to Settings -> API Keys and press the + button on the top right. You can leave all fields empty (the key itself will be auto-generated for you):

Creating a new API Key in FusionAuth

Copy the key to your clipboard and click the “Save” button on the top right. Now paste the API Key to the .env file:

FUSIONAUTH_API_KEY=QBbwebYLcGcUygHNhSXJFSlLSxy7KrRZUHOYvm6xkzTthh_F_a65tdey

The last hint from FA dashboard screen was to setup an SMTP server. Well, sending emails is quite a common functionality anyway, so let’s add a mail service to our infrastructure stack. For that, we’ll be using Mailhog. Open docker-compose.yml and add these lines which I borrowed from a short but meaningful post by Rob Allen:

    mailhog:
        image: mailhog/mailhog
        logging:
            driver: 'none' # disable saving logs
        ports:
            - 1025:1025 # smtp server
            - 8025:8025 # web ui

Restart our docker-compose stack by pressing Ctrl + C and running docker-compose up again. Now we have to update FA settings, go to Tenants menu and press “edit” button against the “Default” tenant, which should be the only tenant in the table, change SMTP settings (host and port is enough):

Updated SMTP settings in FusionAuth

To make sure that everything works OK so far, press the blue button on the right (Send test email). You may send it to an arbitrary address, the email will not go any further than our Mailhog instance. As soon as you see the green line “Email sent!”, open Mailhog web UI: http://localhost:8025/, you should see an email from change-me@example.com with subject “FusionAuth SMTP Test”.

I deliberately didn’t add mailhog to the infrastructure above, leaving it as an exercize for you, dear reader.

Now, we have a fully functional FusionAuth setup. But our application does not yet know how to make use of it. At this point our repository looks like this: https://gitlab.com/crocodile2u/laravel-fusionauth/-/tree/step-4. Remember that the .env file is not under version control, in the repo you will only find the .env.example with dummy values! In the next step, we will add connection between our Laravel app and FusionAuth.

Step 5. Connecting Laravel with Fusionauth

FusionAuth has a ready-made API client composer package which we will, of course, be using:

composer require fusionauth/fusionauth-client

Now, we are finally going to write some PHP code ;-) ! Open app/Providers/AppServiceProvider.php and add these lines to the boot() method, which should be empty initially:

public function boot()
{
    $key = env('FUSIONAUTH_API_KEY');
    $url = env('FUSIONAUTH_BASE_URL');
    $this->app->bind(
        FusionAuthClient::class, 
        fn() => new FusionAuthClient($key, $url)
    );
}

This way we instruct the Laravel’s Dependency Injection mechanism how to create an instance of the FusionAuthClient class which we have just installed.

To represent an authenticated user in our app, Laravel Breeze has added a User model (app/Models/User.php). However, that User class is a descendant of Illuminate\Database\Eloquent\Model, which renders it unusable for our application. I will create a new folder app/Auth/FusionAuth and put another User class into it: https://gitlab.com/crocodile2u/laravel-fusionauth/-/blob/step-5/app/Auth/FusionAuth/User.php. As you can see, our User class also implements Authorizable, Authenticatable and CanResetPassword. I did not implement all fields that a FusionAuth user has, just the very basic ones that will let us to register and log in. I also made it implement JsonSerializable, you’ll see in a bit why I did that. This implementation is pretty dummy, and this is also because we’ll be implementing just user registration and login part of the whole suite of actions that Laravel Breeze comes bundled with. The rest of is left as an exercise to the reader, in order not to make a whole book of this blog post.

I decided to add a UserService class (https://gitlab.com/crocodile2u/laravel-fusionauth/-/blob/step-5/app/Auth/FusionAuth/UserService.php) which will be actually using the FA’s API client provided by composer library.

Next, I added the UserProvider class: https://gitlab.com/crocodile2u/laravel-fusionauth/-/blob/step-5/app/Auth/FusionAuth/UserProvider.php. It implements \Illuminate\Contracts\Auth\UserProvider and delegates the actual work on connecting with FA API, to UserService. I believe this separation of concerns make for a better code structure.

The most interesting bit here is, of course, the UserService. I implemented the following methods:

public function create(User $user, string $password): User
{
    $clientRequest = [
        'registration' => ['applicationId' => env('FUSIONAUTH_APP_ID')],
        'sendSetPasswordEmail' => false,
        'user' => [
            'password' => $password,
            'fullName' => $user->fullName,
            'email' => $user->email,
            'passwordChangeRequired' => false,
            'twoFactorEnabled' => false,
        ],
    ];
    $clientResponse = $this->authClient->register(null, $clientRequest);
    if (!$clientResponse->wasSuccessful()) {
        // fusionauth provides all the details about an error that occured
        // but we are leaving this aside and an exercise for the reader
        throw new \Exception("cannot create user");
    }

    $userData = (array) $clientResponse->successResponse->user;
    return new User($userData);
}

public function retrieveById($identifier): ?User
{
    $clientResponse = $this->authClient->retrieveUser($identifier);
    if (!$clientResponse->wasSuccessful()) {
        return null;
    }
    $userData = (array) $clientResponse->successResponse->user;
    return new User($userData);
}

public function retrieveByEmail($email): ?User
{
    $clientResponse = $this->authClient->retrieveUserByEmail($email);
    if (!$clientResponse->wasSuccessful()) {
        return null;
    }
    $userData = (array) $clientResponse->successResponse->user;
    return new User($userData);
}

public function validateCredentials(array $credentials)
{
    $clientRequest = [
        'applicationId' => env('FUSIONAUTH_APP_ID'),
        'loginId' => $credentials['email'],
        'password' => $credentials['password'],
    ];

    return $this->authClient->login($clientRequest)->wasSuccessful();
}

As you can see, here we encapsulate all the details of how we use the FusionAuth API client to perform operations on users.

In order for Laravel to know about our UserProvider, we have to register in in the AppServiceProvider by adding these few lines to the boot() method:

Auth::provider(
    'fusionauth',
    fn (Application $app) => $app->make(UserProvider::class)
);

And we’ll have to change the application’s configuration a little, this way we let Laravel know which user provider we want to use. Change these lines in config/auth.php:

return [
// ... more lines
    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'fusionauth', // -> was 'users'
        ],
    ],
// ... more lines
    'providers' => [
        // was:
        // 'users' => [
        //   'driver' => 'eloquent', 
        //   'model' => App\Models\User::class
        // ],
        'fusionauth' => [
            'driver' => 'fusionauth',
        ],
    ],
];

The power of using a solid framework is that you only have to add quite a small piece of functionality, re-using the existing abstractions (the interfaces we implemented for our FusionAuth provider), and as long as you did this job properly, everything that depends on those abstractions, continues to work. This also demonstrates one of the key powers of Object Oriented Programming — Polymorphism.

At this point, we can test the registration and authentication process end-to-end. Open http://localhost:8000/register, fill in the form, submit and you should be redirected to http://localhost:8000/dashboard:

Authorized user dashboard

For the application to fully work as expected, we’d need quite some more work. For example, if you open http://localhost:8000/profile and attempt to delete account, you’ll get an error saying that you provided an incorrect password. Practically in every other Controller that Laravel Breeze has (ProfileController, everything under app/Http/Controllers/Auth/) we’ll have to change certain things in a way that would actually work with FusionAuth in mind. But this post is already becoming a bit too long, so I’ll leave it for now, and maybe will return with a complete implementation later. Stay tuned!

Closing thoughts

Modern webapp development is complicated. Twenty years ago, when I was starting my career as a PHP developer, I would simply register an account on a shared hosting for my client, regularly update scripts via FTP, and in the end, it worked ;-)

These days: cloud, docker, service here, service there, SPA, hot-reload, server-side-rendering (moved away from it for years only to turn back and say “you can actually have the full HTML rendered on server!”). I say, progress is inevitable. Certain things have definitely become more complicated, but look… Twenty years ago we did not even use Version Control Systems, or at least mostly did not. Now Git is a must, even in a smallest company! And this makes lives easier, once you’ve learnt it a bit. Back then, most folks wouldn’t know what unit/integration tests are, not to mention CI/CD. Today, CI/CD was made part of nearly every developer’s life, and again, it makes life easier, not harder. In the end, there is way more that you have to know today to be a decent programmer, than 20 years ago. A lot of it is not even about programming. Infrastructure, networking, cloud solutions, building docker images, you name it.. And though sometimes it can be overwhelming, most of the time this tech brings value to our dev lives. Invest some of your precious time in learning.

In this post, we have built an app that uses a decent solution for user management. You can implement Single-Sign-On with FusionAuth, you can sync your users with Active Directory you have a complete mechanism for administering user accounts. Agreed, the setup we ended up with, is more complicated than the simple (yet reliable and secure) stock DB storage provided by Breeze. But ours is so feature-rich, and it is decoupled from our main app and in fact, can manage all users of an organization, that I would say, it can be well worth exploring!