LMID for small-team saas identity

The integration, as code

Concretely, end-to-end, what shipping LMID-as-IdP into your app looks like:

1. Get on the waitlist. Public OAuth-client registration lands as part of LMID's staged 2026 GA. Today, small-team operators come through the waitlist; we provision client credentials by hand. The advantage of the hand-onboarding is we'll tell you up front whether your auth shape is a fit — before you spend a sprint integrating.

2. Receive client_id and client_secret. Standard OAuth 2.0 confidential-client credentials. The endpoints — authorization, token, userinfo — live at id.llamamonkey.com. The discovery document will be at /.well-known/openid-configuration when public client registration ships.

3. Wire the redirect into your app. Your "Sign in with Llama Monkey" button redirects to the authorization endpoint with response_type=code, the configured scopes, and a registered redirect_uri. The familiar pattern. Most OAuth client libraries (Ruby's omniauth-oauth2, JS's openid-client, Go's golang.org/x/oauth2) work without modification once the discovery doc is in play.

4. Handle the callback. User authenticates against LMID with their existing Llama Monkey identity (or creates one in 20 seconds if they don't have one), grants the scopes your client requested, gets redirected back to your app with an authorization code. You exchange the code for an access token, call userinfo, get the user's canonical Llama Monkey identity. Standard OAuth.

5. Don't write a password reset flow. Don't write a session-rotation policy. Don't draft a breach-response plan for credentials you weren't storing in the first place. The hours you didn't spend on auth go into your product.

What your customer sees

The user-facing shape, which matters more for SaaS than the developer-facing shape does:

If they already use a Llama Monkey product (SnapMonkey, LiftMonkey, etc.) — they click "Sign in with Llama Monkey," the consent screen names your app and lists what it can see, they click "Authorize," they're back in your app authenticated. Zero new accounts. Zero new passwords. Your signup conversion at the auth step jumps because the friction is gone.

If they don't yet have a Llama Monkey identity — they're guided through a 20-second account creation on the LMID side, then flow back to your app. The 20-second cost is paid once, ever, across every Llama Monkey-integrated app they'll ever sign in to. If your app is the second one they sign up for, you inherit a zero-friction signup. If it's the first, you've added a small cost in exchange for the same zero-friction signup for every subsequent app in their stack.

What you don't make them do. You don't make them set a password. You don't make them confirm an email. You don't make them remember which email they signed up with when they come back in three months. LMID handles the identity layer; your app handles your product.

The staged GA timeline (where LMID is today, where it's heading)

Honest current-state, not aspirational:

Today (private beta). The provider at id.llamamonkey.com runs. Llama Monkey's own products (SnapMonkey, LiftMonkey, future apps) integrate against it. Third-party OAuth clients come on through the waitlist with hand-provisioned credentials.

Public client registration (planned, 2026 staged GA). Self-serve OAuth client registration via a developer dashboard. The audit-trail features needed before that ships are also in flight — once self-serve registration lands, any small-team operator with an OAuth client library can integrate without a conversation.

SDKs and reference integrations (post-GA). Ruby first (because that's what Llama Monkey ships in), followed by Node.js and Go. Until the SDKs ship, the standard OAuth client libraries cover the integration cleanly.

What's NOT on the roadmap. SAML. SCIM. LDAP bridge. Enterprise directory sync. Anything priced or shaped for IT departments. The buyer LMID is built for is the operator shipping their own product — and that buyer doesn't need any of those.

When this isn't the right fit for an identity buyer

You're selling into enterprise procurement today. If your buyer's checklist requires SAML SSO, SCIM provisioning, and SOC 2 audit packets, your answer is Okta, Auth0, or WorkOS — not LMID. We'd rather tell you that on this page than in month three of a pilot.

You need it in production this week. LMID is private beta. Public OAuth client registration lands as part of the staged 2026 GA. If you're launching this month and your auth surface is on the critical path, the realistic options are roll-your-own (with the operational tax) or one of Auth0/Clerk/Supabase Auth. If your launch is in Q3 or later, the waitlist is the right door.

You want enterprise pricing and a named CSM. LMID is priced for indie operators and small teams. We don't have an enterprise tier and we don't have a sales team. That's a deliberate shape; if you want quarterly business reviews and a customer-success contact, that's not what LMID is.

Your app's users are not the kind of users LMID targets. LMID is built for the consumer-shaped SaaS buyer — credit-card signup, no procurement, expects the OAuth flow they're used to from other consumer apps. If your app's primary users are inside an enterprise tenant signing in via their employer's IdP, LMID is not the layer for that user population; that's their employer's IdP's job.

You need SOC 2 / ISO 27001 audit reports in hand before integrating. See the staged-GA timeline above. The controls are being built; the reports aren't in hand today. If your customers ask for them today, your answer can be "the IdP we use is in staged GA and the controls are in progress" — but if that answer doesn't fly with your buyer, an enterprise IdP is the right pick.