The identity of all your people, on open standards.
Obexal is a sovereign European platform that authenticates your workforce, connects every application and governs access, from one directory and one set of open protocols.
At a glance
| Protocols | OIDC, OAuth 2.1 and SAML 2.0, inbound and outbound |
|---|---|
| MFA | WebAuthn passkeys, TOTP, email codes; never SMS |
| Directory | Profiles, groups, invitations; SAML, LDAP/AD and social federation |
| Provisioning | Inbound SCIM 2.0 (Users resource) and outbound, failures audited |
| Access | Apps restricted to their assigned groups; roles with an anti-escalation guard |
| Conditional access | Network, schedule, country (local GeoIP), 6-signal risk; simulation before enforcement |
| Hosting | France, datacenter in the Paris region; EU data residency |
| Plans | SSO, MFA and directory from Starter; SCIM and conditional access from Team |
This page gathers the workforce identity of your organisation in one place: the people on your payroll and the way they reach the tools they need. Everything below runs on the same directory, the same audit log and the same sovereign hosting, so there is one source of truth to reason about rather than a patchwork of consoles.
One login for every application
Obexal is a complete identity provider for the standards your applications already speak: OpenID Connect, OAuth 2.1 and SAML 2.0. Your people sign in once and reach every connected app, with no proprietary lock-in and no gateway routing your traffic outside the European Union. Discovery is published at /.well-known/openid-configuration and the signing keys at /.well-known/jwks.json, so relying parties integrate against documents rather than manual configuration.
Public clients use the authorization code flow with PKCE, machine clients use client credentials, and Pushed Authorization Requests (PAR) move authorization parameters to a hardened back channel. Applications exchange the code for tokens at /oauth/token and validate a token in real time at /oauth/introspect. SAML 2.0 works both ways: Obexal is a multi-tenant SAML identity provider for your legacy apps, and a SAML service provider when an upstream IdP signs your people in. Beyond a catalog of ready connectors you can register your own OIDC and SAML applications, scoped to your tenant. The full integration path is in the documentation.
Phishing-resistant MFA, never SMS
Stronger sign-in should not mean constant friction. Obexal offers three factors:
- Passkeys: built on WebAuthn, including usernameless sign-in.
- TOTP: time-based one-time codes from any standard authenticator app.
- Email codes: single-use codes delivered by email as a fallback.
It never uses SMS: text messages are a weak, interceptable channel, and leaving them out is a deliberate, sovereign choice.
Passkeys are phishing-resistant by design: the credential is a private key that never leaves the device and is cryptographically bound to your domain, so a look-alike site gets nothing. MFA can be enforced strictly per tenant and per group, and step-up asks for an additional factor only when a sensitive action or a change in context calls for it. Trusted sessions stay smooth, sensitive actions stay protected, and every enrollment, challenge and step-up is written to the audit log.
One directory, one source of truth
One directory is the source of truth for your people. Each profile carries a first and last name, a display name, a job title, a department and a preferred language, set by an administrator or provisioned automatically, and read by the employee portal and by your applications. Users are organised into groups that model your teams, functions or projects, with direct membership so that the answer to "who is in what" stays readable at a glance.
Nobody signs up uninvited. Self-signup is off by default: an administrator invites a person with a pre-filled profile, and the invitation is the activation. At first sign-in the person sets a password or a passkey and lands in the right groups from day one. Identity federation brings in Google, Microsoft or generic OIDC sign-in per tenant, and inbound LDAP or Active Directory that fails closed: if the source does not answer, access is denied rather than silently granted. Group membership then travels to your applications as a groups claim in the tokens they receive.
Accounts that follow your org chart
Accounts follow the org chart automatically. Inbound, Obexal is a SCIM 2.0 server at /scim/v2/Users: your HR system or upstream IdP creates, updates and deactivates accounts without a custom integration. The inbound scope is the Users resource; groups are managed in the Obexal directory itself. Outbound, Obexal is a SCIM client toward any application that exposes a SCIM 2.0 endpoint, pushing create, update and deactivate events to each registered target.
The point is the last day as much as the first: suspend an account once, and Obexal deprovisions it downstream through the SCIM targets, automatically. If a push fails, the failure is recorded in the audit log rather than swallowed in silence, and you can trigger an on-demand sync to reconcile a target. Every provisioning event, success or failure, is auditable and can be streamed to your SIEM.
Access that follows group membership
Assign one or more groups to an application and it becomes reserved for their members: a user reaches it only through group membership. An application with no assigned group remains open to the whole organization, so the restriction is always an explicit choice you can read in the console. Attach groups to an application and the grant takes effect immediately for every member; leave the group and the access is gone. Applications do not have to call Obexal to know a user's rights, they read them from the groups claim in the token.
Administration is kept separate by design. Custom RBAC roles, built from an explicit permission catalog with an anti-escalation guard, govern who can do what inside the Obexal console. Those roles never leak into application tokens: they steer the console, not your apps. Only the groups claim travels to your applications, which keeps authorization simple to reason about and simple to audit.
Rules you simulate before you enforce
Access rules are versioned code across three explicit dimensions, plus adaptive risk:
- Network: allow or deny by CIDR blocks and IP ranges.
- Schedule: restrict access by day and hour.
- Country: decide against a GeoIP database resolved 100% locally; no external lookup is ever called and no IP address leaves the platform.
Adaptive risk adds six deterministic, explainable signals (a new IP, a new device, an unusual hour, a fast IP change, a burst of failures, impossible travel); when risk rises, the policy steps up to MFA rather than blocking outright.
Because a change to access should never be a surprise, every candidate policy version can be replayed as a counterfactual simulation against real sign-ins before it goes live, so you read exactly who would be allowed, stepped up or denied. Apply it when the impact matches your intent, and if a version turns out to be wrong, restore a prior one in a single step. Note that the device is not a policy dimension you write rules against: a new device is simply one of the six risk signals.
Sovereign, and verifiable
Obexal is hosted in France, in a datacenter in the Paris region, with EU data residency. No non-EU dependency sits in the request path, there is no external CDN, and fonts are self-hosted. Traffic uses TLS 1.2 at minimum with 1.3 preferred, and HSTS. Passwords are hashed with Argon2id under a policy aligned with NIST 800-63B and ANSSI, and compromised passwords are rejected against a blocklist checked entirely locally. Application secrets, from OAuth client secrets to SAML signing keys and SCIM tokens, are encrypted with AES-256-GCM at rest. On certifications we state the real status: not certified to date, with an ISO 27001:2022 mapping documented and a SecNumCloud roadmap under way.
Workforce identity is one half of the platform. For customer-facing sign-in see CIAM, for the identity of AI agents and services see AI agent identity, and if you are moving off another IdP the migration guide covers progressive coexistence rather than a big-bang switch. The full security posture is on the security page.
Frequently asked questions
Can we migrate from Okta, Auth0 or Microsoft Entra?
Yes. Both identity providers run side by side and applications move one at a time, so there is no big-bang cutover. See the migration path.
Can MFA be made mandatory?
Yes, per organisation and per group. Enrolment is then required at sign-in, and a strict server-side mandate can be enabled as well.
Where is our data hosted?
In France, in a datacenter in the Paris region, with data residency in the European Union and no non-EU dependency in the request path. Security and trust.
Which plan does this require?
SSO, MFA and the directory are in every plan. SCIM provisioning and conditional access start with the Team plan. See plans and pricing.
Continue: CIAM, your customers' identity · AI agents · Migrate from another IdP