Thoryn

Solution · For Microsoft Entra customers

Thoryn for Entra.

Keep your Entra workforce identity. Add what Entra doesn't do — customer identity, verifiable credentials, and EU-aligned eIDAS 2.0 flows. Thoryn rides on top as a federation member. Conditional Access, MFA, and device posture stay where they are.

Companion mode. Not a replacement. Not a migration.

Companion, not replacement

We don't replace Entra. We extend it.

Three connectors make companion mode real. Each one is a separate piece you can ship without touching the others.

SSO-895

Federation in 15 minutes

Add Entra as a federation member. Workforce users sign in at Entra; Thoryn issues tokens for Thoryn-protected applications without ever seeing a credential. Conditional Access, MFA and device posture stay in Entra.

Read the Entra federation guide
SSO-897

Provisioning via SCIM

Wire Entra Provisioning to Thoryn. Users created, updated, or disabled in Entra propagate to Thoryn within minutes. Disable in Entra, the federation login refuses on next sign-in. No JIT surprises.

Read the SCIM-from-Entra guide
SSO-896

Token exchange (RFC 8693)

A workforce app that already holds an Entra access token exchanges it at Thoryn's token endpoint for an audience-bound Thoryn token. No second login, no flattened identity. The Entra token is the subject; Thoryn validates the issuer JWKS on every call.

Read the token-exchange reference

The honest matrix

What Entra doesn't do.

A non-exhaustive list of the capability gaps Thoryn fills. We're only counting the ones that come up in real customer calls.

Capability comparison: Microsoft Entra ID versus Thoryn, across five identity-platform concerns.
CapabilityEntra IDThoryn
Workforce identity (employees, contractors)

Companion mode means Thoryn defers workforce IdP to Entra by design.

Yes — strongOut of scope
Customer identity (CIAM)

Entra External ID exists for B2B partners; it is not positioned as consumer-facing CIAM. Thoryn is multi-tenant CIAM-shaped from the protocol layer up.

LimitedYes
Verifiable credentials (OID4VCI / OpenID4VP)

Microsoft retired Entra Verified ID for general issuance and verification; the platform is not a credential fabric.

NoYes
eIDAS 2.0 / EUDI Wallet

Thoryn ships an ARF-conformant relying-party verifier and credential issuer; tested against the NL and EU reference wallets.

NoYes — ARF-aligned
Granular OAuth protocol (PAR, RFC 9470 step-up, RFC 8693 exchange)
PartialYes

“Limited” on the Entra side means the capability exists but carries assumptions that don't map cleanly to consumer-facing identity or the EU regulatory landscape. We will be specific on a call.

How it works

Two flows. One companion posture.

Interactive workforce login on top, machine-to-machine token exchange on the bottom. Both treat Entra as the source of authentication; Thoryn issues the tokens that Thoryn-protected APIs accept.

Two-lane architecture diagram. Top lane: a workforce user signs in at Entra ID; Thoryn's Authorization Hub acts as an OIDC client to Entra, then mints an access token for the relying-party app. Bottom lane: an already-authenticated workforce app posts its Entra access token to Thoryn's /oauth2/token endpoint with grant_type=token-exchange; Thoryn validates the Entra issuer JWKS and returns an audience-bound Thoryn token, which the app uses to call a Thoryn-protected API.
Entra owns authentication and policy. Thoryn owns the OAuth / OIDC surface that Thoryn-protected applications consume.
Flow A · Interactive workforce login

User → Entra → Thoryn → app.

Thoryn registers as an OIDC relying party in your Entra tenant. When a user hits an app protected by Thoryn, the hub redirects into Entra; Entra runs Conditional Access, MFA, device-compliance checks; the user comes back; Thoryn mints the access token. The user's password and MFA factor never leave Entra.

Federation member reference
Flow B · Token exchange (RFC 8693)

Entra-token → Thoryn-token. No re-login.

A workforce app already calls its own backend with an Entra token. To call a Thoryn-protected API, it posts that token as thesubject_tokento /oauth2/token with grant_type=urn:ietf:params:oauth:grant-type:token-exchange. Thoryn validates the Entra signature, mints a fresh audience-bound token, and returns it.

Token-exchange reference

Connect in 15 minutes

Three steps. Two of them are us.

The console wizard from SSO-898. Engineered around the actual buyer of this feature: a customer identity admin who runs Entra and hasn't seen Thoryn before today.

  1. Entra side

    Register the app in Entra

    The wizard tells you exactly which menu, which checkbox, and which redirect URI to paste. We reproduce the Microsoft click-path so you don't have to read three different pages of Microsoft Learn.

  2. Thoryn console

    Paste tenant id, client id, secret

    Three fields. Optional toggles for SCIM provisioning and token exchange — both off by default; both can be enabled later without re-running the wizard.

  3. Thoryn console

    Test the connection — done

    The console performs a discovery call against your tenant, verifies the JWKS, and runs a probe sign-in. Green checkmarks; you are live. If anything fails, the error tells you which field is wrong.

Try the wizard

The fifteen-minute promise is explicit and falsifiable. If a real customer takes longer, we update this page.

References

We're running early-access pilots with two named Entra customers. When their public-reference clearance lands, the logos and quotes go here. Until then, the only honest thing to put on this slot is this paragraph.

FAQ

The four questions sales hears most often.

If your question isn't below, the answer is on a 30-minute call.

Do we keep our Entra Conditional Access policies?
Yes. Thoryn never sees the user's credential or MFA factor. The federation login redirects into Entra, where Conditional Access, device-compliance checks, MFA enrolment, and Hello-for-Business all run unchanged. Thoryn only receives the ID token Entra emits at the end of a successful sign-in. See the Entra federation member reference for what the hub does and does not look at.
What about MFA, FIDO2, or Hello-for-Business?
All stays in Entra. The user's MFA gate is enforced by Entra before Thoryn sees a token. Thoryn does not run a parallel MFA system — that would be the rip-and-replace anti-pattern this whole posture rejects. If you want step-up authentication for a specific operation, that is RFC 9470 and lives at the Thoryn / RP boundary.
What if we already have an Entra app issuing access tokens?
We accept Entra tokens via RFC 8693 token exchange. The app posts its Entra access token as the subject_token to Thoryn's /oauth2/token endpoint and gets back an audience-bound Thoryn token. No second login. See the token-exchange reference for the request shape and the validation steps.
Can we deprovision a user in one place?
Yes — via Entra Provisioning + SCIM. Disabling a user in Entra causes Entra Provisioning to call Thoryn's SCIM endpoint, which marks the user as inactive in Thoryn's identity-service. The federation login refuses on next sign-in. Existing access tokens are short-lived and refresh tokens are family-tracked, so the blast radius is bounded in minutes. See the SCIM-from-Entra guide for the field mapping and the lifecycle semantics.

Connect your Entra tenant in 15 minutes.

Bring your Conditional Access. Bring your MFA. Bring your device-compliance posture. We'll add what Entra doesn't do.