01
What an identity provider does
An identity provider authenticates a person and reports the outcome to the applications that asked. Authentication is lifted out of every application and solved once, somewhere that can be monitored, hardened and audited properly, instead of a dozen places where none of that happens.
Most organizations reach this point when the alternative stops scaling. Ten applications each holding their own password table produce ten reset flows, ten session implementations, ten sets of assumptions about security, and no reliable answer to the question of who currently has access to what.
Authenticates the user
The sign-in happens at the provider, with whatever factors are configured. Applications never handle a credential, which means they never store, log or leak one.
Issues proof of authentication
The outcome arrives as a signed token or assertion, which the application verifies against published keys without consulting anybody. That signature constitutes the entire trust relationship.
Manages the account lifecycle
Existence, group membership and the end of access are all decided in one directory. Offboarding collapses into a single action instead of a checklist somebody works through on a Friday afternoon.
Records identity events
Administrative changes and sign-in activity are captured centrally. Without that, an access question asked six months later has to be reassembled from a dozen application logs, if it can be answered at all.
02
How federation establishes trust
OIDC and SAML differ in format and agree on mechanics. Verification does not happen inside the application. The application puts a question to a service it already trusts, reads the signed reply, and treats the signature as the thing that turns an assertion into evidence.
Everything rests on that verification step. Public keys are retrieved from the provider, the reply is checked against them, the audience and the validity window are examined, and only after all of that does a local session begin.
- Somebody opens an application and holds no session there.
- The application issues an authentication request and hands the person to the provider.
- The provider runs the ceremony with whichever factors are configured.
- A signed token or assertion describing the outcome travels back.
- The application checks that signature and its claims, then opens a local session.
03
Identity provider protocols
Standards are the reason an identity provider does not become lock-in. Specified wire formats keep the client code in each application largely portable, so the cost of a future migration falls on configuration rather than on a rewrite.
The standards below do different jobs, and a complete provider carries several simultaneously because a real application environment demands several simultaneously.
- OpenID Connect: who the user is, expressed as a signed ID token.
- OAuth 2.0 (RFC 6749): delegation of access to protected resources, tightened by PKCE (RFC 7636) and PAR (RFC 9126).
- SAML 2.0: signed XML assertions for the enterprise applications that expect them.
- SCIM 2.0 (RFC 7644): account and group creation, update and removal across systems.
- CIBA: authentication opened by the application and completed on a separate registered device.
04
How to evaluate one
Feature comparisons between identity providers converge quickly, because everyone implements the same standards. The differences that matter in production are narrower and harder to see on a datasheet.
Three questions separate providers usefully. What does the sign-in actually prove. Who can obtain the signing keys. What is recorded, and how much can that record be trusted.
What the sign-in proves
A password proves knowledge, a passkey proves device possession, a live biometric check proves presence. Since every connected application inherits this decision, it is the most consequential setting in the platform.
Where the signing keys live
Every token an application trusts is only as good as the custody of the key that signed it. Ask whether key material is sealed at rest under a key held outside the database, and whether non-exportable custody is available for tenants that need it.
What the audit record covers
Ask precisely which events are tamper-evident and which are an ordinary activity stream. A provider that describes everything as an audit log has not thought about the difference, and you will find out during an investigation.
How tenants are isolated
In a multi-tenant platform, isolation should be structural rather than a filter applied at query time. A token minted for one tenant should never validate against another under any configuration.
05
How SenseCrypt works as an identity provider
SenseCrypt is a passwordless identity provider from Seventh Sense. A user is enrolled from a photograph already on file and then authenticates with a live face check. No password appears anywhere in the design, and none waits behind it as a fallback.
This is a complete identity provider and not an MFA add-on, which leaves two deployment shapes open. It can be the sole identity service an application environment speaks to, or it can sit behind an existing platform as the external IdP that runs each sign-in. In the second arrangement the platform you already run stays the identity platform and keeps its policies, its directory and its applications, while SenseCrypt becomes the provider that authenticates the person, over OIDC or SAML 2.0.
The companion app on the user's enrolled phone is required in the two mobile methods. The target of the sign-in is not: the browser, kiosk, desktop or terminal being accessed holds no credential and needs no enrollment of its own.
Face login, matched on the phone
In the mobile-app methods, capture, liveness and comparison run on the user's own enrolled device, and every ceremony consumes one single-use token produced by patent-pending face tokenization. The enterprise-only Simple Webcam method matches from a webcam on a trusted customer network instead. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
The protocol coverage is complete
SenseCrypt supports OIDC, OAuth 2.0 with PKCE and PAR, SAML 2.0, SCIM 2.0 and CIBA, plus FAPI 2.0, FAPI 2.0 Message Signing and FAPI-CIBA. Role-based access control, per-tenant issuers and device keys that sign device-plane requests sit alongside those protocols.
Evaluation evidence and its scope
Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2. Face recognition evaluated in the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021: NIST-evaluated, never NIST certified, because NIST evaluates algorithms and certifies nothing.
Roles are issued centrally and enforced locally
Roles and permissions are computed centrally and written into the token. Separately, a default-closed group gate runs at sign-in, so somebody belonging to no permitted group is stopped before your application is involved at all. What each permission then allows is decided in your code.
06
Frequently asked questions
What is an identity provider?
A service that authenticates users and vouches for them to applications through signed tokens or assertions. The applications trust the signature and stop managing credentials themselves.
What is the difference between an IdP and SSO?
The identity provider is the service that authenticates the user. Single sign-on is the capability it enables, where one authentication opens many connected applications. One is a component; the other is an outcome.
Can SenseCrypt work alongside the identity platform we already run?
Yes, through standard OIDC or SAML 2.0 federation. Your existing platform stays the identity platform with its own directory, policies and applications, and SenseCrypt becomes the external IdP behind each sign-in. The setup is configuration in both consoles rather than software to install.
What exactly does SenseCrypt log?
Console and administrative actions are written to a hash-chained, tamper-evident log. End-user sign-ins are recorded separately as a read-only activity stream and are not hash-chained. The two are described separately because they carry different assurance.
Is SenseCrypt an MFA product or a full identity provider?
A full identity provider. It issues OIDC tokens and SAML assertions, provisions accounts over SCIM 2.0, supports CIBA, and enforces group-based access at sign-in. It can replace an existing provider or federate behind one.