Enterprise · Identity

Set up single sign-on

Let members sign in to Weaver-AI with their work emails. Setting this up takes about fifteen minutes, most of it in your Identity Provider’s console.

Open SSO settings Contact support

Pick your provider

Weaver-AI speaks OIDC. These four are the ones it knows by name; anything else that issues OIDC tokens works through Other OIDC provider.

Microsoft Entra IDApp registrations → New registration. Create a web application, add the callback under Authentication, then a secret under Certificates & secrets.

OktaCreate an OIDC web application with the authorization code flow, and assign the people who should be able to reach Weaver-AI.

Google WorkspaceCreate an OAuth client of type Web application in Google Cloud, and add the Weaver-AI callback as an authorised redirect URI.

Other OIDC providerAny provider with a discovery document. Weaver-AI needs the issuer, a client ID and a client secret.

1. Register Weaver-AI with your provider

Create a confidential, server-side web application. Enable the authorization code flow and add Weaver-AI’s callback as a sign-in redirect URI.

url

https://app.weaversec.com/api/auth/sso/callback

Request these scopes. Weaver-AI adds openid if you leave it out, but list all three explicitly:

text

openid email profile

2. Collect the configuration

Field	What to put in it
`Provider`	Entra ID, Okta, Google Workspace, or another OIDC provider
`Name members see`	What appears on the sign-in button, such as “Acme single sign-on”
`Issuer URL`	The exact HTTPS issuer from your provider's OIDC discovery document
`Client ID`	The provider application's client ID
`Client secret`	Required the first time. Leave blank later to keep the stored one

3. Enter it in Weaver-AI

Open Account → Single sign-on
Go to app.weaversec.com/account and find the single sign-on section.
Choose Configure SSO and confirm it is you
Enter the current code from your authenticator app, or a recovery code. The confirmation lasts ten minutes.
Fill in the provider details
Provider, the name members will see, issuer URL, client ID and client secret.
Leave it on Test and save
Nothing about sign-in changes yet. That is the point of this mode.

4. Test the connection

Do all five. The fourth and fifth are the ones people skip and regret.

Use a private browser window
Or sign out first, so you are not testing your own live session.
Sign in as a member, through the provider
Enter their exact work email. Weaver-AI should offer your organization’s button, and return you to the right account.
Try someone who is not a member
They should be refused. A successful provider login grants no Weaver-AI access on its own.
Confirm your own password and MFA still work
This is your way back in if the provider ever fails. Check it before you rely on it.
Only then change the mode
Move to Optional, and to Required when you are ready for it to be the only way in.

Where to find the issuer URL

“The issuer from your discovery document” is accurate and no help while you are standing in an admin console. It is a specific field with a specific name in each provider.

Field	What to put in it
`Okta — custom authorization server`	Security → API → Authorization Servers. The Issuer URI column, usually https://YOUR-ORG.okta.com/oauth2/default
`Okta — org authorization server`	Your Okta URL with nothing after it: https://YOUR-ORG.okta.com. Simpler, and it has no access policy of its own to configure
`Microsoft Entra ID`	App registrations → your app → Endpoints → the OpenID Connect metadata document, minus the trailing /.well-known/openid-configuration. Usually https://login.microsoftonline.com/TENANT-ID/v2.0
`Google Workspace`	https://accounts.google.com
`Any other provider`	Open its discovery document and copy the "issuer" value exactly, including or excluding a trailing slash as it appears

Signing in is not the same as being invited

Single sign-on proves who somebody is. It does not decide that they belong to your Weaver-AI account. A person who authenticates perfectly at your provider is still refused by Weaver-AI with “not a member of the Weaver-AI account for your organization” until an owner has invited that exact address.

Invite people in Account → Team first, using the same address the provider will send. Weaver-AI does not create accounts from an SSO sign-in, deliberately: an identity provider decides who works at your company, and only you decide who gets a seat here.

They do not have to open the invitation email. Signing in through your provider completes a pending invitation on its own — the provider has already proved who they are, which is better evidence than a clicked link. That is what makes a shared alias or an address that receives no mail usable.

Assign the people who should be able to sign in

Registering the application is not the same as letting anybody use it. Every provider keeps a separate list of who is assigned to an application, and a member who is not on it is refused by the provider before Weaver-AI is ever contacted — after they have typed their password and, in Okta’s case, after they have set up Okta Verify.

What each mode does

TestSaved but offered to nobody. Sign-in is unchanged while you check the settings.

OptionalMembers can use the provider, and passwords keep working.

RequiredMembers must use the provider. Owners keep a password as a way back in.

Rotating the client secret

Create the new secret without deleting the old one
Both are valid at your provider while you switch over.
Save the new secret in Weaver-AI
It takes effect immediately. Weaver-AI cannot return or recover the previous value.
Sign in once through the provider
Confirm it works before you remove anything.
Delete the old secret at the provider
Only after the test passes.

Turning it off

Turn offin the same section stops Weaver-AI offering your provider. It does not remove anyone’s membership, their role or their password. Confirm password and MFA access works before disabling a provider or deleting its application.

When something is wrong

Weaver-AI does not offer the buttonThe email’s domain must match the account’s verified domain, and the connection must not be in Test mode.

The provider signs in, Weaver-AI refusesThe person is authenticating but is not an active member of the account, or the provider email does not match their membership exactly.

It worked yesterdayCheck whether the client secret expired. Providers expire them on a schedule, and rotation is a four-step job, not a one-step one.

Nobody can sign inSign in as an owner with your password and MFA, and set the mode back to Optional while you investigate.