Login with Topolo, added by your coding agent in one prompt

Adding an identity provider to an existing application is a well-understood change with an uneven track record. The risky parts are rarely the redirect. They are the account-linking rules, the token storage, and the temptation to replace the logins you already have.

Topolo ships the integration as a prompt your coding agent can follow, with a check you can run afterwards. Today both are written for JavaScript and TypeScript apps and use @topolo/login. Topolo also publishes standard OIDC discovery at https://auth.topolo.app/.well-known/openid-configuration. You keep the decisions. The agent does the reading and the typing.

Print the prompt

topolo integrations prompt login-with-topolo

The output is an instruction set for your agent, written for an existing third-party application. It asks the agent to add Topolo as an additional OAuth and OIDC login provider, using @topolo/login for provider URLs, token exchange, userinfo, ID-token verification and refresh. @topolo/sdk is used only after login, to call Topolo APIs with the Topolo access token.

A 15-minute, no-deployment evaluation

Use a disposable branch of an existing JavaScript or TypeScript application. The exercise ends with an inspectable code diff and test evidence, not a claim that production login has been verified. Do not deploy, change existing sign-in defaults, or expose credentials as part of this first pass.

1. Minutes 0–3 — Inspect. Open the repository and identify the current auth framework, callback routes, local user/session model, refresh-token storage and deployed versus local URLs. Commit or record the starting point so the change is reversible.
2. Minutes 3–7 — Give the agent the brief. Run topolo integrations prompt login-with-topolo --framework auto, then paste its output into your coding agent. Require it to propose the files and account-linking rules before edits.
3. Minutes 7–11 — Review the change. Confirm @topolo/login, an additive Topolo sign-in route, PKCE/state handling, a local-to-Topolo identity mapping, secrets kept out of source control, and preserved existing login providers.
4. Minutes 11–15 — Check and decide. Run topolo integrations check login-with-topolo --repo-root . --json, review failed checks and tests, and retain a redacted diff. If the repository check passes, schedule a separate real browser-based test; do not label the integration production-ready.

Copy-ready brief for your coding agent

Inspect this existing JavaScript/TypeScript app's auth stack, user table, org/workspace model, callback routes and session storage BEFORE editing. Add Login with Topolo as an OPTIONAL additional OIDC provider using @topolo/login. Preserve every existing login route. Use authorization code + PKCE S256, validate state and OIDC token claims, keep secrets server-side, and implement a durable mapping between the local user and the Topolo subject/organization. NEVER link or merge accounts solely because emails match; require an authenticated local session or explicit account claim. Support denied consent, failed callbacks, token expiry/refresh, disconnect and re-login. Add automated tests for happy paths and account takeover attempts. Show me a file-by-file diff, risks, remaining manual browser tests and rollback instructions. Do not deploy, register a paid service, send messages, or change production settings without separate approval.

What the prompt requires

• Existing logins stay. Google, Facebook, email, SSO and password login are preserved, not replaced.
• The agent inspects first. It reads your auth stack, session store, user model, workspace or organization model and callback route conventions before it writes code.
• PKCE. The authorization code is exchanged with PKCE.
• Explicit account linking. Accounts link through a stored mapping of local and Topolo identifiers. The agent must not merge on a matching email alone unless the user is already signed in to the local account or confirms the link.
• Your token security pattern. Refresh tokens are stored the way your application already stores tokens, and refreshed when calling Topolo APIs.
• Tests. Callback exchange, account linking, refresh handling, and disconnect and re-login.

Configuration

The prompt names four environment variables: TOPOLO_CLIENT_ID, TOPOLO_CLIENT_SECRET when the client is confidential, TOPOLO_AUTH_BASE_URL and TOPOLO_REDIRECT_URI. Register the callback URI in the Developers console, or have your agent run:

topolo oauth clients create

Check the result

topolo integrations check login-with-topolo --repo-root . --json

The check inspects the repository for the pieces of the Login with Topolo integration. The agent fixes every failing check. You review the diff and the tests before you merge.

From vibe coding to vibe businesses

A coding agent can produce an authentication integration quickly. The business outcome is different: a verified sign-in that preserves the account boundaries people already trust. We measure progress by completed, verified work per minute of human attention, not lines generated or commits pushed. The agent can execute the repeatable steps; a human still decides whether the observed evidence meets the release bar.

A practical acceptance checklist before release

1. Test the real redirect. Register the precise staging callback URI and complete a browser-based authorization-code-and-PKCE flow with an approved test identity. Do not treat repository files as proof that the callback works.
2. Verify identity boundaries. Confirm the returned local session maps to the intended identity. Test issuer, audience, expiry, state and nonce protections as applicable to the chosen OIDC stack.
3. Challenge account linking. Try an existing local account with an overlapping email; verify that an unauthenticated email match cannot silently link or take over an account.
4. Exercise failure and recovery. Test invalid state, expired codes, denied consent, token refresh failure, sign-out and disconnect. Check that failures do not expose credentials or create orphaned sessions.
5. Preserve proof. Keep a redacted test record, code review and named release approval. Remove secrets and personal tokens from screenshots, logs and tickets.

Why identity comes first

Identity is the control point everything else depends on: who or what is acting, in which context, with what authority. One identity, shared context, governed action. A Topolo seat can belong to a person or an accountable AI agent, so an application that signs in with Topolo receives both kinds the same way.

Start from the developer docs.

Choose how to evaluate

If you want to explore how identity connects to actual business handoffs rather than only inspect an auth integration, use the 20-minute hands-on Topolo workflow evaluation. It walks through a real enquiry-to-booking use case. For a developer-specific identity assessment, use the tailored demo request below; both are optional.