Single sign-on (SAML and OIDC) | Attack Surface Scan Docs

Your people sign in with the identity provider you already run. You decide who gets access there, and can turn passwords off for your domains here.

Before you start

Single sign-on is included in the MSP and Enterprise plans.
You need to be an owner or admin. The settings are on Team > Single sign-on.
Each domain people sign in from must be verified with the DNS record or the file. Email verification proves one mailbox, which is not enough to route everyone at a domain to your identity provider.
A domain can belong to one account's single sign-on at a time.

Values for your identity provider

Copy these from the settings page, which shows the exact values for your account.

Setting	SAML 2.0	OpenID Connect
Entity ID / Audience URI	`urn:amazon:cognito:sp:…` (copy from the settings page)	Not used
ACS URL / Reply URL	`https://auth.attacksurfacescan.com/saml2/idpresponse`	Not used
Redirect URI	Not used	`https://auth.attacksurfacescan.com/oauth2/idpresponse`
Name ID	The user's email address	Not used
Email	An attribute named `email` (or set the name we should read)	The `email` claim, from the `email` scope

Okta (SAML)

In the Okta admin console, go to Applications > Create App Integration and choose SAML 2.0.
Set Single sign-on URL to the ACS URL and Audience URI (SP Entity ID) to the entity ID.
Set Name ID format to EmailAddress and Application username to Email.
Under Attribute Statements, add email with the value user.email.
Finish, then copy the Metadata URL from the app's Sign On tab and assign the app to the people or groups who should have access.

Microsoft Entra ID (SAML)

In the Entra admin center, go to Enterprise applications > New application > Create your own application and choose the non-gallery option.
Open Single sign-on, choose SAML, and in Basic SAML Configuration set Identifier (Entity ID) to the entity ID and Reply URL to the ACS URL.
Entra sends the email as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress by default. On our settings page, choose Microsoft Entra ID default under the email attribute, or add a claim named email in Entra.
Copy the App Federation Metadata Url from the SAML Certificates section, and assign users or groups under Users and groups.

Google Workspace (SAML)

In the Google Admin console, go to Apps > Web and mobile apps > Add app > Add custom SAML app.
Download the IdP metadata file. You will upload it on our settings page.
Set ACS URL and Entity ID, with Name ID format EMAIL and Name ID Basic Information > Primary email.
Under Attribute mapping, map Primary email to email.
Turn User access on for the organizational units or groups that should sign in.

OpenID Connect (any provider)

Create a web application that uses the authorization code flow, with the redirect URI above and the openid, email and profile scopes. Then enter its issuer URL, client ID and client secret on our settings page. The discovery URL (ending in /.well-known/openid-configuration) works as the issuer too. The client secret is stored by our identity service, never shown again, and only needs re-entering to rotate it.

How signing in works

People choose Sign in with SSO on the sign-in page and enter their work email. We send them to your identity provider.
The first time someone signs in, they join your team as a member and take a seat. Admins can promote them on the Team page. Someone already on the team with a password account, or with a pending invite, keeps that role.
Your identity provider is trusted for your SSO domains only. A sign-in that asserts an address at any other domain is refused.
When the team has no free seats, new people are refused until a seat is freed.

Requiring SSO

Turning on Require SSO for these domains switches password sign-in off for every address at those domains. What changes:

Access	When SSO is required
Password sign-in	Refused. The sign-in page sends people to your identity provider instead.
Sessions started with a password	Stop working on their next request.
AI apps connected over MCP from a password session	Stop working. Reconnect them after signing in with SSO.
REST API keys	Keep working. They belong to the account, not to a person.
People at other domains (contractors, your MSP)	Unaffected. They keep signing in with a password.

Test before you require it

If your own address is at one of the domains, you can only require SSO from a session that signed in with SSO. Save the connection without requiring it, sign out, sign in with SSO, then turn it on. That way a mistake in the identity provider setup never locks your admins out.

Removing people

Remove access in your identity provider first: unassign the app or deactivate the user. Then remove them on the Team page. Removing them only on the Team page is not enough while your identity provider still lets them in, because they rejoin as a member on their next sign-in.

Troubleshooting

Message	Fix
Your identity provider did not send an email address	The email attribute name on our settings page does not match what your provider sends. Entra ID needs the Entra default; Okta and Google need an attribute named `email`.
Your identity provider did not allow this sign-in	The person is not assigned to the app in your identity provider.
Signed in as an address that is not at a domain your organization uses	Your provider sent a different address (often a UPN). Map the email attribute to the user's primary email, or add that domain to SSO.
Your organization has no free seats	Free a seat on the Team page, or upgrade.
Another account already uses single sign-on for this domain	Contact support. We will confirm ownership with both accounts.