Standards first, connectors second
A connector is what you build when a standard is not available. It is not a defeat, but it is a dependency, and it belongs to the exception rather than the architecture.
Standards & ProtocolsEveryone supports the standards.
Everyone supports the standards.
Ask which parts.
Support is never a yes or no. It is a list of options, and the ones that decide whether an integration works are the ones your counterpart happens to require. This page is that list — what we speak, and the settings underneath each of them.
Why this page exists at all
Every identity product claims to support the standards. The question worth asking is narrower: which parts, configured how, and what happens at the edges where the specification leaves room.
Configured, not coded
Bindings, algorithms, scopes and claim mappings are settings on an application, not logic compiled into it. Changing an assertion format should not need a release.
Your provider can stay
Speaking a standard in both directions is what lets Monokee sit in front of, behind, or between the identity systems you already run, instead of replacing them first.
What we speak
The protocol surface
Four families, each doing a job the others cannot. Most deployments use all of them at once, which is exactly why they need to sit behind one policy rather than four consoles.
Federation and single sign-on
SAML 2.0
Monokee acts as identity provider, as service provider, or as a broker between the two. Metadata is exchanged rather than transcribed, and the assertion is signed with algorithms you choose.
OpenID Connect
Relying parties are registered against a provider defined in your domain, with the grant types, response types, scopes and claim mappings each application actually needs.
OAuth 2.0
The authorization layer underneath: clients, scopes, token endpoints and the credentials a client uses to prove it is the client it says it is.
Directory and provisioning
LDAP
Directories are read and written natively, as authoritative sources or as targets, without an intermediate format nobody else understands.
SCIM
Cross-domain provisioning where the other side speaks it: accounts and groups created, updated and deprovisioned over the standard rather than a bespoke script.
RADIUS
For network access and the equipment that has never spoken anything else, and is not about to start.
Authentication
WebAuthn
The browser-facing API for public-key credentials. Every operation is bound to a specific origin, which is what makes a credential created for one domain worthless anywhere else.
CTAP2
How the client platform talks to the authenticator, over USB, NFC, Bluetooth Low Energy or an internal channel — so the same model covers security keys, phones and platform authenticators.
Passkeys
Discoverable credentials, synchronised across a person's devices. The authenticator can enumerate what it holds, which is what makes username-less sign-in possible.
Portable identity
Verifiable credentials
W3C credentials issued, requested and verified as steps inside a journey, so part of the assurance can come from an issuer you trust rather than from a check you run yourself.
External wallets
Credentials presented from a wallet the person controls, integrated into single sign-on rather than bolted on beside it.
The level that decides it
Where integrations actually succeed or fail
Nobody has ever lost a week to whether a product supports SAML. They lose it to a binding preference, a subject format, or a claim that arrives in the wrong place. So these are the things you can set.
SAML 2.0 application
- Service provider metadata loaded from file, from a URL, or filled in by hand
- Assertion consumer services, with endpoints, bindings and a preference order
- Single logout endpoints and bindings
- Signing certificates, signature algorithm and digest method — SHA-256 by default
- Subject format and confirmation method, including transient identifiers that carry no attribute at all
- Attribute statements, mapped rule by rule onto domain attributes
- Both directions of the flow: identity-provider initiated and service-provider initiated
OpenID Connect application
- Client ID and secret, with the token endpoint authentication method the client supports
- Grant types and response types, chosen per application rather than globally
- Redirect URLs, refresh token policy and subject type
- Token and code lifetimes, in seconds, where the defaults do not fit
- Scopes and claims, mapped onto domain attributes and placed in the ID token, the userinfo response, or both
- Signature and encryption algorithms for the ID token and for userinfo
- The authentication flow that protects the application, and the consent flow if consent is required
FIDO2
The one that does not share a secret
Password-based authentication fails because both sides have to know the same thing. Public-key credentials remove that entirely: the private key is generated inside the authenticator and never leaves it, so there is nothing to phish, replay or leak.
Four actors, one boundary
The user, the relying party requiring authentication, the client platform enforcing origin binding, and the authenticator where keys are generated and held. The separation is the security property: even a compromised server or browser does not reach the private key.
Two ceremonies
Registration binds a new credential to an account at a specific relying party. Authentication proves possession of it by signing a fresh challenge. Neither exchanges a shared secret at any point.
Platform and roaming
Authenticators built into the device — secure enclaves, TPMs, biometrics — and external ones like security keys. Same cryptography, very different deployment stories, and both worth supporting for different populations.
Not a replacement for federation
FIDO2 does not replace OAuth 2.0 or OpenID Connect. It strengthens the authentication step inside them, while the federation protocol keeps handling token issuance and the session. Anyone selling you one as the other is confusing two layers.
ArrivingEmerging Emerging Emerging
The standards that are not settled yet
Continuous, event-driven trust needs systems to tell each other when something changed. The specifications for that exist and are being adopted unevenly — by us and by everybody else. It is worth knowing which conversation you are entering.
Shared Signals Framework
The envelope for pushing security events between systems, so a change in one is known to the others in seconds rather than at the next login.
CAEP
Continuous access evaluation: telling a relying party that the conditions a session was granted under no longer hold.
RISC
Risk and incident sharing between providers, for the account-level events that everybody needs to hear about at once.
Support for a standard is never a yes or no — it is a set of options, and the ones that matter are the ones your counterpart requires. If you have a specification, a metadata file or a system that has failed to federate with something else before, that is the most useful thing you can bring to a first conversation.
Bring us the integration that keeps failing
We'll tell you which side of it is the problem, and whether a standard already solves it.
Talk to an expert