AWRA Help Center

This is separate from signing in with a Google or Microsoft account, described in Signing In. That links a person’s own account; this connects your organization’s identity provider, such as Microsoft Entra ID, Okta or Google Workspace, to your workspace.

Setting Up A Connection

1. Open Settings → Security → Single Sign-On & SCIM. It needs the manage security permission.
2. Add a connection and choose SAML 2.0 or OIDC. For SAML, AWRA publishes service-provider metadata for the connection that you load into your identity provider; for OIDC, enter the issuer (or its discovery URL), the client id and the client secret from your provider.
3. Add the email domain your people sign in with, for example yourcompany.com.
4. Prove you own the domain. AWRA shows a TXT record of the form awra-sso-verification=<token>. Add it to the domain itself in your DNS, then press verify. DNS changes can take up to an hour to be seen.
5. For SAML, paste your provider’s metadata URL or XML to fill in its details, and give it the service-provider metadata URL shown on the page.
6. Choose what happens to someone who signs in without an AWRA account: refuse them and ask an Admin to add them, or create the account on first sign-in (just-in-time provisioning) with a default role. Group-to-role mapping can add roles from the groups your provider sends; it never removes roles.
7. Switch the connection on.

How People Sign In

People go to Sign in with your organization’s SSO, at /sso on the web or the same button in the AWRA mobile app, and enter their work email. AWRA finds the connection from the domain and sends them to your provider.

• Only verified domains are accepted. An address on a domain your connection has not verified is refused, so another organization’s provider cannot sign anyone into your workspace.
• After the first sign-in, the person is matched by the identity your provider sends rather than by email, so a renamed mailbox still reaches the same account.
• An address that already belongs to a different AWRA workspace is refused.
• Your workspace’s multi-factor and other sign-in rules still apply after the provider hands the person back.
• Each sign-in, and each refusal with its reason, is written to the audit log.

Signing Out, Encryption And Keeping The Domain Proved

• Single logout, both ways (SAML). Give your provider the Single logout URL shown on the connection, and fill in the IdP logout URL if your provider has one. Signing out of AWRA then signs the person out of your provider too, and signing out at your provider ends their AWRA session. Only signed logout requests are acted on.
• Encrypted assertions (SAML). Each connection has its own encryption certificate, published in its service-provider metadata. Encrypted assertions are always accepted, and must still be signed. Tick Require encrypted assertions to refuse anything else. New SP Certificate rotates the key; load the new metadata into your provider straight away, or encrypted sign-ins fail.
• Connections set up before 30 October 2026 must re-import AWRA’s service-provider metadata into the provider before single logout or encryption will work. Sign-in itself carries on as before.
• Only our own identity provider. On the Security Policy page, with single sign-on required, this makes the Google and Microsoft buttons stop counting: only your organization’s SAML or OIDC connection satisfies the requirement, on the web and in the mobile app. It can be switched on once one of your own connections is on.
• The domain is checked every day. AWRA looks up each verified domain’s TXT record daily. One failed lookup changes nothing; a record that stays missing brings a warning to the people who manage security, and after seven days the domain is unverified and stops accepting sign-ins until it is proved again.

SCIM 2.0 Provisioning

The single sign-on page issues a SCIM bearer token. Give it to your identity provider together with the base URL /api/scim/v2 on your AWRA address.

• Users can be listed (filtered by userName, externalId or email, and paged), read, created, replaced and updated, with ServiceProviderConfig, ResourceTypes and Schemas for discovery.
• Groups are roles. A group your provider pushes becomes a role of the same name with no permissions until an Admin gives it some; adding and removing members adds and removes that role. The Admin role cannot be renamed or deleted, and its last active member cannot be removed.
• Deactivating or deleting a user signs them out everywhere (web sessions and mobile app) and never erases them, so their approvals, postings and audit history stay attached to a real name.
• New users count against your plan’s seats; a create beyond them is refused.
• Tokens can be rotated or revoked from the same page, and your IP allowlist applies to them.

Related: MFA & Security, Security Posture, Incidents & Anomaly Rules.