Restrictions and security · BreezeAuth Docs

A service user’s credential works without anyone typing a password or answering a multi-factor challenge, so it deserves the same care as an administrator’s account. BreezeAuth gives you several controls to keep each service user’s power and exposure as small as possible. Combine them.

Controls at a glance

Control	What it limits	Where to configure it
Administrative role	What the service user can do	The service user’s Edit form
Service user status	Whether the service user can work at all	The service user’s Overview tab › Change status
Credential status	Which credentials work	The credential’s Edit form › Active
Credential expiration	Until when a credential works	The credential’s Expires at date
Network zones	From where the service user can connect	Organization › Security settings › Network access restriction settings
Country restriction	From which countries the organization can be accessed	Organization › Security settings › Restrict access by country

Some limits are built in and can’t be changed: service users can’t sign in to the admin console or to applications, can’t be Owners, and can’t be added to groups or assigned to applications.

Give only the access needed

The administrative role decides which operations the service user can perform through the API; anything else is refused. Choose the narrowest role that covers the integration, for example Auditor for read-only reporting or SCIM Provisioner for user provisioning, and avoid Administrator unless nothing else works. See Choose a role.

Create one service user per integration. That way each one has only the access it needs, its actions are easy to tell apart in the Audit Logs, and turning one off doesn’t affect the others.

Turn integrations off instantly

You can cut off access at two levels, and both take effect on the very next API request, including for access tokens that were already issued and have not expired:

Deactivate a credential to stop one deployment of an integration, or a secret that may have leaked. The service user’s other credentials keep working. See Deactivate a credential.
Deactivate the service user to stop the integration entirely, whatever credentials it has. See Deactivate or reactivate a service user.

Both can be undone by reactivating.

Limit how long credentials live

Give credentials an Expires at date whenever you can. A credential that expires on its own limits the damage of a secret that leaked without anyone noticing, and turns rotation into a routine. Access tokens themselves are always short-lived, and there are no refresh tokens: once a credential is deactivated or expired, nothing derived from it keeps working.

Restrict the networks service users connect from

Integrations usually run from a known place: your data center, a cloud account or a server with fixed public IP addresses. You can make BreezeAuth refuse requests from anywhere else, so a stolen secret is useless outside those networks.

This uses network zones: named lists of IP address ranges that you define once and reuse. When the organization’s network access restriction is active:

a service user can only obtain access tokens from an allowed network zone;
every API request it makes is also checked, and refused with network_not_authorized if it comes from outside the allowed zones.

To set it up:

Find out the public IP addresses your integration’s servers use to reach the internet. Your cloud or hosting provider, or your network team, can tell you; servers behind a NAT gateway usually share its fixed address.
Create a network zone for them, for example “Integration servers”.
Restrict access to the organization to that zone and to the zones your people connect from.

Warning: the organization’s network restriction applies to every member, people and service users alike, not only to service users. Before saving, make sure the selected zones include the networks of all administrators and people who use the organization, or they will be locked out immediately, you included.

If the organization also uses Restrict access by country, it applies to service users’ API requests too: requests from a country that isn’t allowed are refused with access_not_allowed_from_country.

Monitor activity

The Audit Logs record when service users and credentials are created, changed or deleted, every time a credential is used to obtain an access token, and the actions service users perform. On each service user’s Credentials tab, the Last used column shows when each credential was last exchanged for a token.

Review them regularly: a credential that is never used can be deleted, and activity at unusual times or from unexpected places deserves a closer look.

Security checklist

Each integration has its own service user.
Each service user has the narrowest role that works.
Client secrets are stored in a secrets manager or protected environment variables, never in code or on users’ devices.
Credentials have an Expires at date and a rotation routine.
Unused credentials are deactivated and then deleted.
If integrations run from fixed addresses, the organization restricts access to known network zones.
Someone reviews the Audit Logs and Last used dates periodically.
Everyone knows how to deactivate a credential or a service user in an emergency.