Skip to main content

Authentication & Access Control

Breeze implements layered identity controls covering local accounts, enterprise single sign-on, machine-to-machine integrations, and role-based authorization within the application.

Password policy​

User passwords are subject to minimum length and complexity requirements enforced on user activation and password reset. Passwords are stored only as a bcrypt hash. Plaintext passwords are never stored, logged, or returned in API responses.

Multi-factor authentication (MFA)​

Breeze supports email-based MFA using a 6-digit one-time code:

  • The MFA code is encrypted at rest using AES-256.
  • The MFA code is short-lived and single-use — a new code is issued for every challenge and is invalidated once consumed.

MFA is enforced automatically for accounts with elevated privileges (administrators and other elevated roles). Tenant administrators can also enable a tenant-level setting that enforces MFA for all users in their tenant, regardless of role.

Single sign-on (SSO)​

Breeze supports enterprise single sign-on via OAuth 2.0. The currently supported configuration is Microsoft Entra ID (Azure AD); additional providers — including SAML-based identity providers — can be enabled on request.

When SSO is configured for a tenant, Breeze redirects the user's browser to the tenant's identity provider for authentication. After the identity provider authenticates the user, Breeze receives a verified token containing the configured subject identifier (typically the user's email) plus any role attributes the identity provider has been configured to share. Breeze maps those attributes to the corresponding Breeze user account and tenant before establishing a session.

See Authentication › Single Sign-On for tenant-level SSO configuration.

OpenID Connect (OIDC) via Signicat​

For end-user identity verification with national eID schemes (BankID Norway, Swedish BankID, MitID, and others), Breeze uses OpenID Connect via Signicat as the eID broker. The OIDC flow uses the standard openid profile email scopes; the nin (national identity number) scope is not requested today. If a future integration ever requires it on a legal basis that permits it, the nin may be requested as an additional scope. The specific eID scheme used in a given session is controlled per request via the acr_values parameter (for example idp:nbid for Norwegian BankID).

What is stored from eID authentication. Breeze does not receive a national identity number from the eID flow today, and does not persist a nin from authentication regardless. The only values stored on the Breeze user record from an eID login are the pseudonymous identifiers Signicat returns:

  • idp_id — Signicat's stable identifier for this user.
  • idp_name — which eID scheme was used (for example nbid, sbid).
  • nbid_subject_uuid — the BankID subject UUID, where applicable.

These identifiers exist purely to link a future eID login to the correct Breeze account. They are not personally identifying on their own.

Signicat is listed as a sub-processor; see Sub-processors for details, including a separate note on the data-verification lookup flow that is distinct from authentication.

Session management​

After successful authentication, Breeze issues a pair of tokens:

  • A short-lived access token (JWT) that is presented on every API request.
  • A longer-lived refresh token that is used to obtain a new access token without re-authenticating.

The refresh-token lifetime is tied to the strength of the original authentication.

The access token is short-lived (15 minutes); when it expires, the client exchanges the refresh token for a new one. The access token's hash is verified on every request and is also stored in the platform's token cache, which provides:

  • Server-side revocation — logging out, changing the password, or administrative session termination removes the token from the cache, immediately invalidating it even before its natural expiry.
  • Integrity verification — the per-request hash check defends against forged tokens even if the JWT signing key were leaked.

OAuth 2.0 for machine-to-machine integrations​

For server-to-server integrations, Breeze exposes an OAuth 2.0 client-credentials token endpoint. An OAuth client is created against an existing Breeze user account; the access token issued to that client inherits the same role-based authorization as the user it was created from. What an integration is permitted to do via the API therefore matches exactly what the originating user is permitted to do via the UI, and is governed by the same role-based access control described below.

OAuth clients are tenant-bound: a token can only access data belonging to the tenant of the user it was created from. The token endpoint is rate-limited per client.

Role-based access control (RBAC)​

Within a tenant, users are assigned roles. Breeze supports two complementary categories:

  • General roles — hierarchical levels of platform access (for example Standard User, Tenant Administrator, Domain Administrator, System Administrator). A user's general role determines the broad scope of what they can see and do.
  • Task roles — granular, capability-based roles that grant permission to perform specific operations (for example managing credentials, managing users, or configuring templates). Task roles extend the permissions granted by the general role for particular workflows.

For the customer-facing description of each role and its capabilities, see User Administration › Roles and Permissions.

Every API mutation runs through a centralized authorization guard that:

  1. Validates the user's authentication.
  2. Checks that the user belongs to the tenant whose data is being accessed.
  3. Verifies that the user holds a role with sufficient permissions for the requested operation.

This guard is applied uniformly across the GraphQL API; resolvers cannot bypass it.

Multi-tenant isolation​

Tenant isolation is enforced at the API layer: the requested tenant ID is filtered into every database query at the resolver, so a user authenticated to tenant A cannot retrieve, mutate, or even reference data belonging to tenant B. Tenant membership is verified on every request, not only at login.

Rate limiting on authentication endpoints​

To mitigate brute-force and credential-stuffing attacks, the authentication endpoints (/api/login, /api/activate, /oauth/token) are rate-limited per source, enforced consistently across all backend instances. Suspicious request patterns (known bot user-agents, unusual headers) trigger additional restrictions. Specific thresholds are available under NDA on request through your account contact.