Skip to main content

Single sign-on (SSO)

Single sign-on lets the people at your organization sign in to TheAccessible with the same institutional login they already use — no separate password to manage. When SSO is enabled for your organization, a team member signs in through your identity provider (IdP), and a TheAccessible account is created for them automatically the first time.

What you get​

  • One login. Your users authenticate against your own IdP (Microsoft Entra ID, Shibboleth/InCommon, Okta, or any SAML 2.0 provider). Their normal multi-factor authentication applies.
  • Automatic account creation. The first time someone signs in via SSO, we create their TheAccessible profile inside your organization — no manual invites.
  • Domain-scoped. Only email addresses on the domains you verify (for example, yourschool.edu) can be provisioned through your connection.
  • A login audit trail. Your administrators can see recent sign-in attempts and their outcomes.

How it works, briefly​

  1. A user goes to the SSO start page and types your organization.
  2. We redirect them to your IdP to authenticate.
  3. Your IdP returns a signed assertion; we verify it, confirm the email is on a verified domain, and sign the user in.

You stay in control of who can authenticate — SSO is scoped to the email domains you verify with us, which is what prevents anyone outside your organization from being provisioned into your account.

What you'll need to set it up​

Setting up SSO is a short, one-time coordination between your IdP administrator (the person who manages Entra ID / Shibboleth / Okta) and TheAccessible. See:

Current limitations​

We want you to know these up front — your security team will likely ask:

  • No Single Logout (SLO). Signing out of your IdP does not automatically end an active TheAccessible session. Sessions do expire on their own based on your configured timeout.
  • No automatic deprovisioning (SCIM). Removing a user in your IdP does not automatically disable their TheAccessible account. Offboarding is handled by your organization administrator today.
  • SSO is additive. Enabling SSO does not disable other sign-in methods unless you ask us to. Talk to us if you require SSO to be the only path.
  • Encrypted assertions and signed authentication requests are not supported in this version. Assertions are protected in transit by TLS.

If any of these are blockers for your security review, contact us — several are on our roadmap and we prioritize them per customer need.