Identity that fits the way your app works.
Hosted sign-in, organizations, and permissions, designed together. Give people a place in your app, and the right access when they get there.
Welcome back, Dana.
One account. A different role in each workspace.
Choose a workspace
Editor in Design studio
- Read a document
- Allowed
- Publish a document
- Allowed
- Invite a teammate
- Allowed
Inspect the example token
{
"iss": "https://acme.udibo.com",
"sub": "5d2c1e7a-…",
"email": "[email protected]",
"email_verified": true,
"org_id": "7c0a9b3e-…",
"org_slug": "design-studio",
"org_roles": [
"editor"
],
"roles": [
"billing"
]
}One integration, three foundations
Recognize the person
Passwords, social accounts, email codes, or magic links, with authenticator MFA and recovery codes, on hosted pages that carry your name, logo, and accent color.
Give them a place
Group customers into organizations with invitations, memberships, and roles. One person can belong to several, with different access in each.
Resolve what they can do
Define permissions in your app's own words. Assign roles across a tenant, inside an organization, or on one resource. Read tenant and organization roles from the token, and check resource grants with the API.
Branding
Your sign-in page, not ours
Hosted pages carry your name, logo, and accent color, with no Udibo watermark. People sign in to your product, not to a vendor.
Sign in to Acme
New to Acme? Create an account
How an integration works
Udibo speaks OAuth 2.0 and OpenID Connect, so standard clients connect. For Hono and React, the @udibo/oauth2 package gives you the backend and browser client.
1.
Register your application
Create a tenant, register your callback URL, and copy the client ID and issuer from the dashboard.
2.
Send people to your hosted pages
Udibo handles accounts, MFA, recovery, and email, then returns the browser to your callback with an authorization code.
3.
Enforce access in your backend
Your API validates the access token and reads the person's organization and permissions. Your app still decides who reaches each record.
const client = new DirectClient({
issuer: required("AUTH_ISSUER"),
clientId: required("AUTH_CLIENT_ID"),
clientSecret: required("AUTH_CLIENT_SECRET"),
redirectUri: required("AUTH_CALLBACK_URL"),
});
const bff = new HonoBff({
client,
sessionStore: sessions,
authRequestStorage: new EncryptedCookieAuthRequestStorage({
secret: required("AUTH_REQUEST_SECRET"),
}),
resourceServer,
scope: required("AUTH_SCOPES"),
defaultReturnTo: "/",
});
const app = new Hono();
app.route("/auth", bff.routes());
app.use("/api/*", bff.protect());From the Use Udibo guide: sign-in routes at
/auth, and every /api route needs a session.
Start from a working app
Each starter is a small, complete app secured with Udibo. Fork the one closest to your product as the base for a new project, or read it as a reference for how to secure that kind of app.
- B2B SaaSOrganizations, a protected project list, and verified webhooks.
- Consumer appHosted account pages, profile claims, and records owned by one person.
- Client portalPer-document access, organization grants, and checks across a list.
- API serviceA protected JSON API and an automated grant report, with no frontend.
- MCP serverTools gated by the signed-in person's permissions in their organization.
- Run it locally firstThe @udibo/oauth2 quickstart needs Deno and Git, and no hosted account.
Protection that starts on, and stays yours to tune
Hosted sign-in starts with breached-password checks, lockout, and rate limits switched on. Adjust each policy from your tenant's Security page, and use monitor mode to see what protection would refuse before it blocks anyone.
- Breached passwords refused
New passwords are checked against Have I Been Pwned by k-anonymity, so only a short hash prefix leaves Udibo.
- Lockout that reveals nothing
Repeated wrong passwords lock the account and hit a rate limit, and a locked account gets the same answer as a wrong password.
- A way back in
A locked-out person is emailed a one-time unlock link, or can reset their password from the sign-in page.
- Monitor before you enforce
One tenant-wide switch records what attack protection would refuse — lockout, the sign-in rate limit, per-account email limits, MFA throttling, breached-password checks — as audit events, without blocking anyone.
- Session lifetimes
Choose how long a sign-in lasts, how long remember-me holds, and when an idle session ends.
- Bot challenges
Add a Cloudflare Turnstile challenge to your hosted sign-up, sign-in, and password-reset forms.
Agent-ready
Built for the agents writing your code, and the ones you ship
Hand your coding agent docs it can read and a brief it can follow. When you build an MCP server, protect its tools with the same organizations and permissions as your app.
A brief your agent can follow
Paste the integration brief and your agent starts on the hosted path, with a definition of done, instead of writing its own password storage.
Docs in plain text
llms.txt indexes every guide, llms-full.txt files carry the identity and package docs in one response each, and any guide is Markdown by adding .md to its URL.
Typed package reference
Every exported subpath and signature of @udibo/oauth2 on JSR, so an agent calls the API that exists rather than one it guessed.
Add authentication to this application using Udibo Identity.
Integration path: managed identity service.
Read https://www.udibo.com/llms.txt first.
Keep tokens and client secrets on the backend. Preserve PKCE, state, and CSRF.
Prove sign-in, refresh, logout, and refusal of unauthorized API requests.An excerpt of the agent brief. The full version adds your framework, callback URLs, and identity mapping.
Protect an MCP server with Udibo
The MCP server starter checks each access token locally and answers with protected-resource metadata, so clients discover your tenant on their own. Give someone a role with write access and their agent can add notes; leave it out and it can only read.
Role you grant Dana
Tools Dana's MCP client is offered
- team_notesnotes:read
- Granted
- add_team_notenotes:write
- Not granted
- What is available today?
Available now
- Password, social, email-code, and magic-link sign-in
- Authenticator-based MFA and recovery codes
- Organizations, invitations, and roles
- Permissions across a tenant, an organization, or a resource
- Webhooks and an exportable audit log
- Self-service directory export
- Your branding, with no Udibo watermark
Not available yet
- Hosted passkeys
- SAML federation
- SCIM provisioning
- Custom domains for hosted pages
- How do I get access?
Join the waitlist and you will get an email invitation when your spot opens. Before you launch, work through the production checklist and confirm support expectations with Udibo.
- What does it cost?
Every released self-service feature is included on Free, with no enterprise upsell for features like MFA or the audit log. Paid plans add capacity as your usage grows.
- Can I try it without an account?
Yes. The @udibo/oauth2 package quickstart runs the same sign-in flow against a local identity provider.
- Can I move an existing app?
Yes. Keep your product and its data: map identities, test with a small cohort, and switch in stages with a rollback plan. Plan your migration.
- What happens if I leave?
Export your directory when you need to move. Your app speaks standard OAuth 2.0 and OpenID Connect, so another provider can take its place.
Start free, grow with usage
Every released self-service feature is included on Free. Paid plans add capacity when your app needs more room.
Free, every month
- Monthly retained users
- 500
- Hosted permission checks
- 25,000
- Emails sent by Udibo
- 1,000