Built for the people who look after access

One sign-in for your organisation’s applications

For IT teams with several internal applications, each with its own login.

The problem

Every application keeps its own passwords, its own idea of who is an administrator, and its own way of resetting access. Leavers keep access somewhere, and nobody can say who signed in where.

What you get

• One sign-in page and one session for every connected application
• Authenticator-app codes as a second factor, mandatory where you decide
• Roles assigned once and sent to each application in the token
• One audit log of sign-ins and administrator actions

How OneiD works Talk to us about it

Active Directory for modern applications

For organisations whose users live in Active Directory or another LDAP directory.

The problem

New applications expect OpenID Connect, not LDAP. Opening the directory to each of them spreads service accounts and directory passwords across many systems.

What you get

• Applications speak OpenID Connect; only OneiD talks to the directory, over LDAPS
• Passwords are checked against the directory and never stored by OneiD
• Directory groups become roles through a mapping you control
• A required group decides who may sign in at all

LDAP and Active Directory Talk to us about it

One identity layer in front of your provider

For teams that use Okta or another OpenID Connect provider and want their applications to depend on it less.

The problem

When every application integrates directly with the provider, its groups, claims and settings leak into each application, and any change of provider touches all of them.

What you get

• Applications integrate once, with OneiD, and receive the same tokens whatever the provider
• Provider groups become OneiD roles; a required group limits who may sign in
• Sign-out continues to the provider, so the user is signed out in both places
• The provider’s own multi-factor rules still apply

Okta and other providers Talk to us about it

Protected APIs and service-to-service calls

For teams that run APIs called by applications, scripts and other services.

The problem

Shared API keys are copied into many places, never expire and cannot say who is calling or what they may do.

What you get

• Services get short-lived tokens with the client credentials grant
• API scopes say exactly what a caller may do
• APIs check tokens locally with OneiD’s public keys, without a call per request
• A disabled client or a replaced secret stops access

Protect an API Talk to us about it

Integrations built by your team or your partners

For product teams and partners who add “Sign in with OneiD” to software, gateways or plugins.

The problem

Each integration is written from scratch and gets the details slightly wrong: the issuer, the token checks, refresh and sign-out.

What you get

• A connector specification with every rule an integration must follow
• A test checklist to prove an integration before it ships
• Documentation in Markdown and llms.txt that coding agents can follow
• Quickstarts for nine stacks and five API frameworks

Connector specification Talk to us about it