Your enterprise customers want to sign in with their own identity provider. Canopy speaks SAML 2.0 and OIDC, and hands that customer's own IT administrator a portal where they set the connection up, verify their domain, and run a real test sign-in, without ever opening a ticket with your team.
Enterprise SSO is normally a support thread: screenshots of an identity-provider console, a certificate pasted into an email, and a configuration one of your engineers applies by hand for every customer who asks. Canopy gives that customer's own administrator a portal scoped to their organization, and six steps to work through at their own pace.
Every identity provider publishes a metadata document describing itself. Paste its URL, or the XML when the document isn't reachable from the internet, and Canopy reads out the entity ID, the sign-in URL, and the signing certificate. The three values most likely to be mistyped are never typed at all.
Providers disagree about what to name a claim, and a connection that resolves nothing fails its first test sign-in on a missing attribute. Canopy recognises three of them from the host their sign-in URL points at, and seeds the connection with the names each one really sends.
email.../identity/claims/emailaddressNameID@emailAddressA connection routes sign-ins for the email domains its organization has proved it controls. Canopy issues a DNS TXT record for each one, and until that record resolves the domain is pending and routes nobody. A verified domain belongs to one account and no other.
A test runs the real round trip against a connection that is configured but not yet live. Nothing is provisioned, no session is minted, and the test never appears in anyone's recent sign-ins. It reports the email and name the provider sent back, and whether that email's domain is verified, which is a separate question from the sign-in working.
A failed test doesn't report that something went wrong. It returns one of ten named reasons, each pointing at one fix.
provider_rejectedthe person isn't assigned to the application theresignature_invalidthe response didn't verify against the certificate on the connectionassertion_expiredthe two clocks disagree by more than the allowed skewaudience_mismatchthe response was addressed to a different entity IDissuer_mismatchit came from a different issuer than the connection expectsassertion_replayedthat response had already been usedattribute_missinga required attribute was absent under every source nameemail_domain_not_allowedthe sign-in worked, but the domain isn't verifiedassertion_invalidit couldn't be verified for a reason none of the above coverssso_errorthe round trip failed some other waySingle sign-on shows up in three places, and they're independent of each other. Run any of them, or none.
Your own administrators sign in to Canopy through your corporate provider. Configured once, for the whole account.
Your application's users sign in through their provider, either in the hosted OAuth flow or through the Direct-API flow with a publishable key.
The same end-user sign-in, configured by the customer's own IT administrator in a portal scoped to their organization.
An organization's policy can require single sign-on outright. Passwords and email codes are then refused for its members, and for any address whose domain routes to the connection, before a credential is ever checked. Because that door closes behind the administrator too, Canopy issues recovery codes so nobody is locked out of their own tenant.
Single sign-on, the organization portal, metadata import, domain verification, and test sign-in run on the Pro plan. Canopy is early-stage and says so plainly: this page describes what ships now, not what is planned.