Why TerminusDB and Single Sign-On (SSO) match so well together

Single sign-on greatly simplifies user management for companies. Instead of employees or users creating separate accounts on all kinds of services, we are now able to sign on with one single Microsoft, GitHub, Google, or any other type of account that offers single sign-on. Instead of total clutter and users scattered between lots of services, there is one clean way of signing on.

This approach has different security advantages as well:

• Instead of having to enforce 2FA on every service separately, administrators can simply turn it on at one level. It can then be enforced by every service it uses;
• Although password managers made life much easier for a lot of people, having fewer accounts clearly offers benefits to the user as well.

But most databases require a difficult set-up for this approach to work properly. A lot of web applications, for instance, are made with a boilerplate API that is often a thin wrapper around database calls. They are solely made to authenticate users and make calls to the database, with sometimes additional processing. Often it is tricky to call them directly. That’s why solutions like PostgREST are made, which turn a Postgres database into a proper REST API.

Instead of creating a boilerplate API to call the database, TerminusDB can be set up in such a way that makes it possible for a web application to directly interact with the database. If you set up your roles and permissions in advance, your user can sign on with a supported SSO provider and directly call the database without too much hassle. This is made possible by TerminusDB supporting a forward header, in which it offloads the responsibility of authentication to another service, assuming that the database itself is nicely closed off. Curious on how you can set TerminusDB up with single sign-on (SSO) with only little effort? Read the following tutorial: