Security & Access

6 min read

The Security & Access settings section is where a workspace decides how people get in and what non-human things can reach its data.

It covers access tokens, audit logs, verified email domains, single sign-on, and — on Enterprise — directory provisioning over SCIM, alongside the AI clients connected to the workspace.

Access Token Metrics

The section shows token metrics:

Total tokens
Active tokens
Disabled tokens
Tokens expiring soon

Use these metrics to review automation credentials and identify tokens that may need attention.

Access Tokens

Access tokens are available from this settings section.

Use Manage on the Access Tokens card to open the access-token page. There you can create, review, disable, and revoke tokens according to your permissions.

Learn more: Access Tokens Overview

Audit Logs

Audit logs are available from this settings section.

Use Manage on the Audit Logs card to review workspace activity for investigations, compliance checks, and change tracking.

Domain verification, single sign-on and SCIM all write audit entries, so a change to how people sign in is reviewable in the same place as everything else.

Verified Domains

Single sign-on and SCIM act only on email addresses whose domain this workspace has verified. Verification is a DNS TXT record, which proves your organization controls the domain — and therefore the mailboxes an identity provider would be vouching for.

Open Settings → Security & Access and find the Verified domains card.
Enter your company’s email domain, such as acme.com, and choose Add domain. Consumer mail providers cannot be verified.
Copy the TXT record name and value the card shows, and publish them with your DNS provider.
Choose Verify. DNS changes can take a while to appear, so if the record is not found yet, wait and try again.

A verified domain is re-checked weekly. If the record disappears, the card warns you and the domain stays verified for two weeks before lapsing, so a tidy-up does not lock anyone out the same afternoon.

Guests on other domains are unaffected by everything below: they keep signing in with a Hawzu password, and a directory cannot manage them.

Single Sign-On

Single sign-on is available on every plan. A workspace can connect one identity provider over OpenID Connect or SAML 2.0 — Okta, Microsoft Entra ID, Google Workspace, or any provider that speaks either protocol.

Connect a provider

Verify a domain first, as above.
In the Single sign-on card, choose the protocol and register Hawzu with your identity provider. For OpenID Connect the card shows the redirect URI to register, and you paste back the issuer URL, client ID and client secret. For SAML you paste back the provider’s entity ID, sign-in URL and signing certificate — pasted or uploaded as the file it downloaded — and the card then shows the ACS URL, the service provider entity ID and a metadata URL to put into the provider.
Choose Test sign-in. This proves the connection works and signs nobody in; the result comes back to this page.
Choose Switch on. Members on your verified domains can now sign in through your provider from the Hawzu sign-in page.

Changing the issuer, client or certificate invalidates an earlier test, so a connection is only ever switched on as it was last proven to work.

Requiring single sign-on

Switching single sign-on on makes it available. Require makes it the only way in for people on your verified domains.

Requiring it needs a successful test sign-in from the last ten minutes. A recent test helps prevent lockouts, because the identity provider can change without Hawzu knowing. Before it takes effect, Hawzu shows how many people are affected, how many are unaffected, and which owners have no fallback.

Who is exempt when it is required:

People on domains you have not verified — contractors and guests.
Workspace owners with two-factor authentication turned on. This lets an owner still sign in if the identity provider is down, so make sure at least one owner has 2FA on before you require single sign-on.
API access tokens, which are credentials your workspace issued rather than people.

Anyone signed in with a password is asked to sign in through the provider the next time they open the workspace — asked, not redirected: they see a confirmation naming the workspace first. AI clients connected over MCP with a password-based session must be reconnected.

Somebody who belongs to two workspaces that each require their own provider signs in to each one once. A session remembers every provider it has been through, so moving between them afterwards does not ask again.

Admitting people automatically

By default, someone who signs in through your identity provider but is not a member is refused and told to ask an administrator.

Turn on Admit new people automatically and their first sign-in adds them to the workspace with the role you choose. Everyone your identity provider vouches for on a verified domain can then join, and each person takes a seat on your plan, so it is off until you ask for it.

Directory Provisioning (SCIM)

SCIM is available on Enterprise only. Single sign-on is on every plan.

With it, Okta or Microsoft Entra ID adds, updates and removes people in Hawzu as your directory changes.

In the Directory provisioning (SCIM) card, copy the SCIM base URL.
Create a token, naming it after the directory that will use it, and choose the role the directory’s people receive. The token is shown once, so copy it now.
Paste the base URL and token into your identity provider’s provisioning settings.

For the provider-by-provider walkthrough, what SCIM supports, and what each directory change does here, see Directory Provisioning Setup.

What a directory can and cannot do:

It acts only on addresses on your verified domains.
Deactivating somebody there removes their workspace access here — project access, group membership, pending invitations and connected AI clients — and signing in again does not undo it.
Reactivating them adds them back with the token’s role. Project access is not restored, because it was removed on the way out.
It cannot change an email address: a Hawzu account is identified by it.
It cannot deactivate the workspace owner.

Revoke a token to stop a directory immediately. Nobody already in the workspace is affected.

Connected Apps

The section lists every member’s connected AI clients — applications authorized to read this workspace over MCP. See MCP security.

Each row shows the member who connected it, the application’s self-reported name, and when it was connected. All such access is read-only: a connected client cannot create, edit, or delete anything.

Use the disconnect action to revoke a connection. It takes effect on the client’s next call. Disconnecting here affects only this workspace — if the same member authorized the same application in another workspace, that connection is separate and is unaffected.

Members can also see and disconnect their own connections from their personal security settings, whatever their role in the workspace.

Best Practices

Verify your domain before configuring single sign-on
Give at least one owner two-factor authentication before requiring single sign-on, so an identity provider outage is recoverable
Test the connection after every change to it
Prefer short-lived access tokens with the narrowest access that supports the task
Use audit logs to verify sensitive workspace changes

Next Steps

Review Access Tokens
Learn about Roles
Review Workspace Settings