OIDC sign-in
The login happens at the identity provider; Door James receives only the claims it needs.
Integrations
Single sign-on with your identity provider
One account fewer: the recommended route is your own identity provider, so Door James does not become another user directory to maintain.
In short
Door James authenticates users through OpenID Connect against your organization's identity provider. Microsoft Entra ID and Google are preconfigured patterns; other OIDC providers can be set up. Group memberships from the directory drive whitelists, roles and booking rights; permitted domains control who can enter the organization at all.
- Protocol
- OpenID Connect
- Preconfigured
- Microsoft Entra ID, Google
- Permissions
- groups from the directory
- Transport
- HTTPS and TLS enforced
Features
Groups and roles
Directory groups map onto area access, roles and booking rules.
Domains and whitelists
An organization can hold several permitted domains; addresses outside them do not get in.
Role-based permissions
From organization admin to a restricted reception role – rights are granted per role and location.
Why there is no separate login
A separate account per application stops being a convenience question in organizations above a few hundred employees and becomes a security risk: forgotten deactivations when people leave, duplicate master data, separate password rules. Connecting an identity provider avoids all three, which is why it is the recommended setup and the one we configure in most rollouts. Where an identity provider is not available, a one-time code by email or a passcode can be used instead – deliberately, per organization, rather than as a shadow directory that grows on its own.
Groups as a control mechanism
The second, often underestimated effect concerns maintenance: when area access depends on directory groups, a team change automatically flows into booking permissions. Without that link every reorganization would have to be replicated in Door James – effort that in practice is skipped, which then leads to wrong permissions.
Frequently asked questions
Does Door James support Keycloak?
Door James speaks OIDC generically, so Keycloak is technically compatible. We only make a production commitment after confirming the current development and testing status.
And SAML?
SAML sign-in is supported and configurable in the Admin Panel: identity provider certificate, entity ID, NameID format, clock skew, signature requirements and separate service provider credentials for the member app and the panel. A successful connection test is required before the configuration can be saved. For a tender, confirm the specific scenario with us – but SAML itself is built, not planned.
Do we need SCIM for provisioning?
Users are created at first login through OIDC; profile data and groups come from Graph. For different provisioning scenarios we discuss the available routes.
Are there local accounts?
Connecting your identity provider is the recommended route, and it is what we set up in most rollouts. Door James also supports a one-time code by email and a passcode as sign-in methods – useful for locations without an identity provider, and the default for a fresh organization until an IdP is configured. Which method applies is set per organization, so if your policy rules out local sign-in, it gets switched off deliberately.
Bring your actual setup to the call
Which tenant, which directory, which calendars, which identity provider. Thirty minutes is enough to say whether it fits – and where it will not.