Modern Development

Yummy API for Developers & Robots

API-First

Often solutions limit which operations can be performed through an API, which can be painful for customers who want to fully control user experience and/or automate (DevOps). For example the mandatory use of user UI, or even admin UIs - or say tenant creation. This is why Quasr has been build fully and truly API-first, allowing a UI-free and automated approach, allowing our customers to build and use their own UIs, and supporting DevOps practices through setup and configuration automation.

The Quasr API has two parts, one has a REST design and is mainly intended for actions that aren't focused on data, like account signup and login, consent, etc. The other one has a GraphQL design and is intended for more data-heavy use like getting, creating, updating, querying or deleting your resources. Quasr does offer a Tenant Admin UI but some functionality is only available through the API (though the gap is very small).

Machine-Friendly

Quasr takes a generic view at accounts. Accounts can be users but also physical machines as well as software (i.e. clients). This generic approach allows customers to use Quasr for a variety of use cases and easily deal with non-human entities. We believe the future will hold more automation, ie. more machines and software will be communicating with online services, and the need to securely authenticate them is just as relevant (perhaps even more).

Multi-Tenancy

Quasr is designed for high-volume multi-tenant scenarios and tenants are implemented as best as possible to support this. One key difference is tenants are completely self-encompassing, meaning they do not require any outside assets to operate. This may sound straightforward but in fact many solutions do not provide this. Think for example about admin UIs or accounts, often these sit at the root level, and can't be avoided. At Quasr your admins live within your tenant and are just accounts like any other. Hence you can configure how they're authenticating and you can even promote your users to be admins (if desired).

Tenants

A tenant is a logically isolated instance of Quasr, containing its own configuration, accounts, factors, etc. Each tenant's data is isolated and remains invisible to other tenants.

Quasr supports multi-tenancy. A Quasr customer would at least have one tenant to properly work with Quasr, but they might want to have multiple tenants. A tenant is always owned by an Account. Multi-tenancy can help solve various use cases, such as:

• Splitting between development environments such as dev, uat, staging and prduction.

• Separating environments for different B2B SaaS customers in typical B2B2X scenarios.

Quasr as a company is “dog-fooding” its own product, so our platform uses Quasr and its multi-tenancy capabilities itself. When a Quasr customer signs up for Quasr, they are basically a regular user in a Quasr owned tenant - we call this the "Quasr Root Tenant". This is where we as Quasr managed our own customer. This is also where the Quasr customer manages their user profile, billing, as well as the creation and deletion of their own tenants.

Tenants can be spun up from within the Quasr Account Administration, or via API. This means, you can integrate the tenant creation into your automated DevOps process if you like.

As shown in the images above, a Tenant Administrator sits in its own tenant with admin permissions. Upon tenant creation, this admin user is automatically provisioned and the login works through Quasr OpenID Connect Federation with the Quasr Root Tenant.