DEV Community: Xiao Yijun

Getting CLI authentication right: the complete guide to all 4 methods

Xiao Yijun — Thu, 09 Apr 2026 02:16:27 +0000

Every developer CLI ships with login as its first command. And every one of them solves auth differently.

GitHub shows you a code and opens your browser to verify it. AWS opens a browser for PKCE-based SSO. Stripe has you confirm a pairing code in the dashboard. The newer AI tools (Claude Code, OpenAI Codex CLI, Cursor) each picked their own approach too.

If you're building a CLI, auth is one of the first things you need to figure out. Pick the wrong method and you'll hear about it: frustrated users, security audits, or both. And with the recent wave of AI coding agents that call CLI tools programmatically, the stakes are higher: you're not just authenticating a human anymore. You might be handing credentials to an autonomous process.

Here are the four auth methods that matter, how the biggest tools implement them, and the mistakes you'll want to avoid.

The four methods at a glance

Before going deep, here's the quick comparison:

Method	Best for	Security	Needs browser?
OAuth Device Code Flow	Headless environments, SSH	High	No (on the same machine)
Browser-based OAuth (localhost redirect)	Local development	Highest	Yes
API Keys / PATs	Automation, CI/CD, quick prototyping	Moderate	No
Client Credentials	Machine-to-machine, services	High	No

Each has tradeoffs. Here's what you need to know about each one.

1. OAuth device code flow (RFC 8628)

This is the one where your CLI shows you a code like ABCD-1234 and a URL, then tells you to open that URL on any device and enter the code.

Who uses it: GitHub CLI (default), Azure CLI (via --use-device-code), Vercel CLI (recently switched to this as default), OpenAI Codex CLI (as a beta option)

How it works

You run cli login
The CLI requests a device code from the auth server, sending its client_id and requested scopes
The server returns three things: a device_code (internal identifier), a user_code (the short code you type), and a verification_uri (where to go)
Your CLI displays the code and URL, then starts polling the auth server every 5+ seconds
You open the URL on any device (phone, laptop, a different computer), type in the code, and authenticate however you want (password, SSO, passkeys, MFA)
Once you approve, the next poll returns an access token and refresh token
The CLI stores these and you're in

Why developers like it

The big selling point: it works anywhere. SSH session into a remote server? Works. Running inside a Docker container? Works. Cloud IDE with no local browser? Works. The browser doesn't need to be on the same machine as the CLI.

It also supports the full range of enterprise auth (SAML, OIDC, MFA) because all of that happens in the browser, not in the terminal. The CLI never sees your password.

The security catch most people miss

Device code flow has a phishing problem. An attacker can initiate a device code request, get a legitimate user code, and trick you into entering it, effectively authorizing the attacker's session. This isn't theoretical. Security researchers have documented this attack against AWS SSO device code auth.

This is a big enough concern that AWS changed their default. Starting with AWS CLI v2.22.0, the default for aws sso login switched from device code flow to PKCE-based authorization code flow. Device code is still available via --use-device-code, but it's no longer the default path.

Meanwhile, Microsoft's own tenant has started blocking device code flow entirely via conditional access policies, a strong signal that they consider it a high-risk authentication method.

So we have an interesting split: Vercel adopted device code flow as their default in September 2025, while AWS moved away from it. The pattern seems to be that device code flow is great for environments where you genuinely can't open a browser, but if you can open one locally, PKCE is the safer bet.

On the auth provider side, the demand is clearly growing. Logto just shipped OAuth 2.0 Device Authorization Grant support for native apps in v1.38.0 (open source) and Logto Cloud, so you can now enable device flow as the authorization method for any native application. This matters if you're building a CLI. Implementing RFC 8628 correctly (code expiry, rate limiting, polling logic, the sign-in UX on the verification page) is more work than most teams expect, and having your auth provider handle it means you just need to make the right HTTP calls.

Technical details from the RFC

A few things worth knowing from RFC 8628:

The expires_in value for device codes is set by the auth server. The RFC uses 1800 seconds (30 minutes) as an example, but it's not a fixed requirement.
If the server doesn't specify a polling interval, clients must default to 5 seconds.
If you get a slow_down error, add 5 seconds to your interval.
Device codes should be single-use and expire quickly.
All token exchanges must happen over HTTPS.

2. Browser-based OAuth (localhost redirect)

This is the most common method for CLIs running on a developer's local machine. You run login, your browser opens, you authenticate, and the browser redirects back to a local server the CLI spun up. Modern implementations add PKCE (pronounced "pixie") on top, which makes the flow much harder to exploit.

Who uses it: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (for SSO, with PKCE as default)

How it works

You run cli login
The CLI starts a temporary HTTP server on a random local port (say http://127.0.0.1:8742)
It opens your default browser to the auth provider's authorization endpoint, passing that localhost URL as the redirect URI
You authenticate in the browser (SSO, password, passkeys, whatever the provider supports)
The auth provider redirects your browser to http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
The local server captures the authorization code, exchanges it for tokens via a back-channel HTTPS request
The browser shows a "Success! You can close this tab" page
The CLI stores the tokens and shuts down the local server

The user experience is smooth. No codes to copy, no URLs to type. Just a browser tab that opens and closes.

When it falls apart

This only works when the CLI can open a browser and bind to localhost. That rules out:

SSH sessions to remote servers
Docker containers (unless you do port forwarding gymnastics)
CI/CD pipelines
Headless servers
Some restricted corporate environments

That's why most tools that default to browser OAuth also support a fallback, typically device code flow or API keys.

Three security pitfalls that keep showing up

Pitfall 1: Binding to 0.0.0.0 instead of 127.0.0.1

This is the most common mistake, and it's severe. If your callback server listens on all interfaces, anyone on the same network can intercept the authorization code.

// Bad: exposed to the entire network
server.listen(8742, '0.0.0.0');

// Good: only accessible locally
server.listen(8742, '127.0.0.1');

I've seen this in production CLIs. It's an easy mistake to make because many HTTP server libraries default to 0.0.0.0.

Pitfall 2: Missing state parameter validation

The state parameter is your CSRF protection. Without it, an attacker can trick your CLI into accepting an authorization code from a malicious session.

// Bad: no CSRF protection
app.get('/callback', (req, res) => {
  const code = req.query.code;
  exchangeCodeForTokens(code); // Could be from anyone
});

// Good: validate state
const state = crypto.randomBytes(32).toString('hex');
app.get('/callback', (req, res) => {
  if (req.query.state !== state) {
    return res.status(400).send('Invalid state');
  }
  exchangeCodeForTokens(req.query.code);
});

Pitfall 3: Not using PKCE

If your OAuth flow doesn't use PKCE (Proof Key for Code Exchange), the authorization code can be intercepted and replayed.

In a standard authorization code flow, if an attacker intercepts the authorization code (through the network, or by reading the redirect URL), they can exchange it for tokens. PKCE prevents this by requiring proof that the token exchange was initiated by the same client that started the authorization request.

Here's what PKCE adds to the flow:

Before starting the flow, the CLI generates a random code_verifier (a high-entropy string)
It creates a code_challenge by hashing the verifier with SHA-256
The challenge is sent with the initial authorization request
When exchanging the code for tokens, the CLI sends the original code_verifier
The auth server verifies that the verifier matches the challenge

An attacker who intercepts the authorization code doesn't have the code_verifier, so they can't complete the exchange.

This is why AWS CLI v2.22+ made PKCE the default for SSO, moving away from device code flow. When the CLI can open a browser on the same machine, browser OAuth with PKCE is strictly better than device code flow — same UX, stronger security guarantees, no phishing vector. Device code flow is still the right choice when the browser can't be on the same machine (SSH, containers, remote dev environments), but that's not the common case for local development.

3. API keys and personal access tokens

The simplest approach. You generate a token in a web dashboard, paste it into your CLI config or an environment variable, and you're done.

Who uses it: Stripe CLI (as a login option), npm, pip, most AI coding tools as a fallback (Claude Code via ANTHROPIC_API_KEY, OpenAI tools via OPENAI_API_KEY, Aider)

How it works

Log into the service's web dashboard
Go to settings → API keys (or personal access tokens, or developer tokens)
Generate a new key, usually a long random string with a prefix (e.g., sk_live_, ghp_, npm_)
Store it in a config file (~/.config/stripe/config.toml, ~/.aws/credentials) or an environment variable

The CLI reads it on startup and includes it in API requests, typically as a Bearer token in the Authorization header.

Why it's still popular despite the risks

For automation, API keys are hard to beat. They work in CI/CD, in containers, in scripts, in cron jobs. Anywhere that can read an environment variable. No browser needed. No interactive prompts. No token refresh dance.

For AI agent workflows especially, API keys are the path of least resistance. When Claude Code or Cursor needs to call an API, an environment variable with an API key is the simplest integration point.

The risks are real

Leaks. API keys end up in git commits, log files, error messages, and CI output. GitHub scans for exposed tokens and reports over a million leaked secrets per year.
Overprivileged. Most API keys grant broad access. If leaked, the blast radius is large.
No MFA. API keys bypass your carefully configured multi-factor auth.
Hard to rotate. Every time you rotate a key, you need to update it everywhere it's stored. With teams, that's a coordination problem.

Modern enhancement: temporary token exchange

The smart move when using API keys: exchange them for short-lived tokens at runtime.

AWS pioneered this with STS (Security Token Service). Your long-lived credentials are only used to request temporary credentials that expire in an hour. Tools like aws-vault automate this entirely.

import boto3

sts = boto3.client('sts')
temp_creds = sts.assume_role(
    RoleArn='arn:aws:iam::123456789:role/CLIRole',
    RoleSessionName='cli-session'
)
# temp_creds expire in 1 hour by default

Even if you start with API keys, consider adding this pattern. It limits the damage window of a compromised key from "until someone notices" to "one hour."

4. Client credentials flow

This OAuth 2.0 flow is designed for machine-to-machine auth: services talking to services, no human involved.

Used in: CI/CD pipelines, background services, automated tooling

How it works

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=my_service
&client_secret=secret_value
&scope=api:read api:write

The service sends its client_id and client_secret directly to the auth server and gets back a short-lived access token. No browser, no user interaction, no redirect.

When to use it

Use client credentials when:

A service or bot needs to authenticate, not a human
You're in a CI/CD pipeline
You need automated, unattended access
The "user" is the application itself

Don't use it for human authentication. It doesn't support MFA, SSO, or any interactive verification.

What real CLIs actually use

Here's a corrected breakdown based on current documentation and source code. A lot of articles get this wrong because tools keep changing their defaults.

CLI Tool	Default auth	Fallback options	Token storage
GitHub CLI (`gh`)	Device code flow via browser	PAT (`--with-token`), env var (`GH_TOKEN`)	OS keychain (fallback: plain text file)
AWS CLI v2	PKCE auth code flow (SSO)	Device code (`--use-device-code`), credential files	`~/.aws/sso/cache/`
Azure CLI (`az`)	WAM on Windows; browser auth code flow on Linux/macOS	Device code (`--use-device-code`)	`~/.azure/msal_token_cache.*`
Vercel CLI	Device code flow (new default, Sep 2025)	API token (`--token`, env var)	`~/.local/share/com.vercel.cli/auth.json`
Stripe CLI	Browser-based pairing flow	API key (`--interactive`, `--api-key`, or env var)	`~/.config/stripe/config.toml`
gcloud CLI	Browser OAuth	`--no-browser` manual flow	`~/.config/gcloud/`
Claude Code	Browser OAuth	API key (env var, `apiKeyHelper`)	OS keychain / `~/.claude/.credentials.json`
OpenAI Codex CLI	Browser OAuth	Device code (beta), API key	`~/.codex/auth.json` / OS keyring
Terraform CLI	Browser OAuth	Token paste	`~/.terraform.d/credentials.tfrc.json`

The trend is clear: browser-based OAuth is the default for local development, with device code flow as the headless fallback, and API keys for automation. PKCE is gaining ground as the most secure option when a browser is available.

Token storage: what to use, what to avoid

Getting auth right doesn't matter if you store the tokens wrong.

The right way: OS keychains

Every major OS has a built-in encrypted credential store:

macOS: Keychain (used by GitHub CLI, Claude Code)
Windows: Credential Manager
Linux: Secret Service API (GNOME Keyring, KDE Wallet)

These provide OS-level encryption, access control, and hardware security integration. Your CLI doesn't need to implement its own crypto.

// Using keytar (cross-platform keychain library)
const keytar = require('keytar');

// Store
await keytar.setPassword('my-cli', 'default', token);

// Retrieve
const token = await keytar.getPassword('my-cli', 'default');

The fallback: encrypted config files

When a keychain isn't available (containers, minimal Linux installs), use encrypted config files with restrictive permissions:

# File permissions: owner read/write only
chmod 600 ~/.config/my-cli/credentials

What to avoid

Plaintext files. This should be obvious, but plenty of tools still do it. A plaintext token file is accessible to every process running as your user, every backup tool, and anyone who gets temporary access to your machine.

// Don't do this
fs.writeFileSync(path.join(homedir, '.myapp/token'), token);

Environment variables for long-term storage. Environment variables are visible in process listings, often logged by crash reporters, and inherited by child processes. They're fine for CI/CD (where the CI platform manages the secret) but risky for local development.

Browser localStorage. If your CLI has a web component, don't store tokens in localStorage. One XSS vulnerability exposes everything.

Token lifecycle management

Access tokens

Keep them short-lived. One hour is the common standard. When an access token expires, the CLI should transparently refresh it. The user shouldn't have to re-login for routine operations.

Refresh tokens

Refresh tokens are the long-lived credentials that let you get new access tokens without re-authenticating. They're high-value targets for attackers because of their longer lifespan (days to months).

Refresh token rotation

Modern auth systems rotate refresh tokens on every use:

CLI sends refresh token to get a new access token
Auth server returns a new access token and a new refresh token
The old refresh token is immediately invalidated
CLI stores both new tokens

This limits the damage of a stolen refresh token. If an attacker tries to use a refresh token that the legitimate CLI already used, the auth server detects the reuse and invalidates the entire token family. Both the attacker's stolen token and the legitimate user's current token stop working, forcing re-authentication but preventing the attacker from maintaining access.

Common pitfalls (with code)

1. Binding the callback server to all interfaces

Already covered above, but worth repeating: always bind to 127.0.0.1, never 0.0.0.0.

2. Logging tokens

This happens more often than anyone admits. A debug log statement, an error handler that dumps the request headers, a verbose mode that prints everything.

// This will end up in your log aggregator, your support tickets,
// and eventually on someone's screenshot in Slack
logger.debug('Request headers:', headers);

// Better: redact sensitive headers
const safe = { ...headers };
delete safe.authorization;
logger.debug('Request headers:', safe);

3. Baking credentials into container images

Docker images are not secret stores. Every layer is extractable.

# Anyone who pulls this image can extract your key
ENV API_KEY=sk_live_abc123

# Instead: accept credentials at runtime
ENV API_KEY=""
# docker run -e API_KEY=${API_KEY} my-image

4. Not handling token expiry gracefully

When a token expires mid-operation, don't just crash with a 401 error. Attempt a refresh, and only prompt for re-authentication if the refresh token is also expired.

def api_call(endpoint, data):
    response = requests.post(endpoint, json=data, headers=auth_headers())
    if response.status_code == 401:
        if refresh_tokens():
            # Retry with new tokens
            response = requests.post(endpoint, json=data, headers=auth_headers())
        else:
            raise AuthExpiredError("Session expired. Please run `cli login` again.")
    return response

5. Ignoring the principle of least privilege

Don't request admin:* scope when you only need repo:read. This applies to both OAuth scopes and API key permissions.

When an AI agent is using your CLI, this becomes even more important. You probably don't want an AI assistant to have delete-repo permissions just because it needs to read code.

The AI agent wrinkle

Here's what makes 2026 different from 2023: CLIs aren't just for humans typing commands anymore. AI coding agents like Claude Code, Codex, and Cursor's agent mode call CLI tools programmatically. This creates new auth challenges:

Delegated permissions. When Claude Code runs gh pr create on your behalf, it's using your GitHub credentials. But should an AI agent have the same permissions as you? The principle of least privilege says no, but most tools don't have a way to scope down agent access.

Credential exposure. If your API key is in an environment variable, every process can read it, including the AI agent's subprocess. Tools like Claude Code have addressed this with apiKeyHelper scripts that generate short-lived tokens on demand, but this isn't universal yet.

Headless auth for agents. An AI agent running in a sandboxed environment can't open a browser. Device code flow works here (the human approves on a separate device), but API keys are the more common solution because they require zero interaction.

Audit trails. When an AI agent makes API calls with your credentials, the audit log shows you made those calls. There's currently no standard way to distinguish "the human did this" from "the agent did this on behalf of the human."

This is an evolving space. The best thing you can do right now:

Use scoped tokens with minimal permissions for agent workflows
Prefer short-lived credentials (temporary tokens, not long-lived API keys)
Use dedicated credentials for agent use, separate from your personal credentials
Monitor API usage for unexpected patterns

Decision framework

Picking an auth method? Here's the short version:

"My users are developers on their local machines"
→ Browser-based OAuth with PKCE (best security + smooth UX)

"My CLI needs to work in SSH sessions and containers"
→ Device code flow as fallback, browser OAuth as primary

"This runs in CI/CD with no human in the loop"
→ Client credentials flow or scoped API keys

"I need the fastest implementation possible"
→ API keys (but add token rotation later)

"Enterprise customers need SSO and MFA"
→ Any OAuth flow (device code or browser), which supports the full enterprise auth stack

"AI agents will use this CLI"
→ Support API keys (for easy agent integration) + browser OAuth (for human users), with scoped permissions and short-lived tokens

FAQ

Is device code flow secure?

It's secure against most attacks, but it has a known phishing vulnerability. An attacker can generate a device code and trick users into authorizing it. This is why AWS moved to PKCE as the default for SSO login. For headless environments where PKCE isn't practical, device code flow is still the best option. Just be aware of the phishing risk.

Should I store tokens in environment variables?

For CI/CD: yes, because the CI platform encrypts them at rest and injects them at runtime. For local development: no. Use the OS keychain instead. Environment variables are visible in process listings and can be accidentally logged or leaked to child processes.

What's the difference between an API key and a personal access token?

Functionally, very little. Both are long-lived credentials that authenticate API requests. The distinction is mostly organizational: API keys are often scoped to a project or application, while personal access tokens are tied to a user account. Some services use the terms interchangeably.

How often should I rotate credentials?

Access tokens: every hour or less (handled automatically by the token refresh flow). Refresh tokens: rotate on every use (the auth server should do this). API keys: at least every 90 days, or immediately if you suspect exposure. In practice, most teams only rotate API keys after an incident, which is too late.

How do I handle auth in Docker containers?

Three options, in order of preference:

Device code flow for interactive use (works because the browser can be on a different machine)
Environment variables passed at runtime (docker run -e API_KEY=${API_KEY}) for CI/CD
Volume-mounted credentials (docker run -v ~/.config/tool:/root/.config/tool:ro) for local development

Never bake credentials into the image. Never.

What about MCP (Model Context Protocol) authentication?

MCP is the emerging standard for AI agents to connect with external tools and services. It introduces a new auth dimension: the agent needs credentials to talk to the MCP server, which in turn needs credentials to talk to downstream APIs. This is still being standardized. For now, most MCP implementations use API keys or OAuth tokens passed through the MCP configuration. Expect this to evolve rapidly.

CLI auth is changing fast. What was best practice two years ago (device code flow as the default, plaintext credential files) is already being replaced. If you're adding auth to a CLI today, start with browser OAuth + PKCE for humans, API keys for automation, and plan for the day when AI agents are your primary users.

How to choose an identity provider: The engineering team's evaluation framework

Xiao Yijun — Tue, 24 Feb 2026 05:05:48 +0000

Most identity provider comparison articles are written by identity providers. Shocking, right? They list features their product has, skip the ones it doesn't, and call it an "objective guide."

This isn't that.

We've reviewed dozens of real enterprise evaluation requests — the actual spreadsheets and RFP documents that procurement teams send to vendors. The patterns are clear: engineering teams consistently underweight the criteria that matter most and overweight the ones that matter least.

The result? Teams pick an IdP based on a demo, discover the migration story is a nightmare six months in, and start evaluating again.

Here's the evaluation framework we wish someone had given us before we started. It's built for engineering teams at B2B SaaS companies — the ones building products, not the ones buying workforce SSO for their employees.

Quick answer: What makes or breaks an IdP decision

If you're skimming, here's the short version:

Protocol depth matters more than feature count. Supporting "OAuth2" means nothing. Which grant types? Can you customize token claims? Can you become an OIDC provider yourself?
Migration capability is the #1 underrated criterion. If you can't migrate your existing users without forcing password resets, the IdP is unusable — no matter how good everything else looks.
Multi-tenancy must be native, not bolted on. If organization models and per-tenant configurations require workarounds, you'll be fighting the system forever.
AI-readiness isn't future planning — it's a 12-month requirement. Token exchange, agent identity, delegated scopes. If the IdP doesn't support these, you'll be back here evaluating again next year.

The rest of this guide walks through each evaluation dimension in detail, with specific questions to ask and red flags to watch for.

Who this guide is for (and who it's not for)

This is for you if:

You're a CTO, VP of Engineering, or platform architect at a 50-300 person B2B SaaS company
You have 100K+ existing users and can't afford a disruptive migration
You're moving upmarket into enterprise customers who need SSO, org models, and audit logs
You need to write a technical evaluation report and want a framework that doesn't come from a vendor

This is NOT for you if:

You're looking for workforce IAM (employee SSO to internal tools) — that's a different buying decision
You're a startup with 500 users and no enterprise customers yet — pick whatever has the best SDK and move on
You need identity verification (KYC/KYB) — that's a separate category entirely

Dimension 1: Protocol capabilities — Not just "supports OAuth2"

Every IdP on the market will tell you they support OAuth2 and OIDC. That's table stakes. The real questions are about depth.

Grant types: Which ones and why it matters

Must-have:

Authorization Code + PKCE — The only flow you should use for browser-based and mobile apps. If a vendor still recommends Implicit flow, walk away. PKCE isn't optional — it's a security requirement.
Client Credentials — For service-to-service communication. Your backend services need to authenticate with each other without a user present.
Refresh Token — Sounds basic, but the implementation details vary wildly. Can you configure rotation? Expiration? Can you revoke a specific refresh token without nuking the entire session?

Increasingly critical:

Token Exchange (RFC 8693) — This is the grant type that enables AI agent authentication, impersonation flows, and delegation. If it's missing today, ask about the roadmap. If there's no roadmap, that's a red flag.

OIDC Provider capability

Here's a question most teams don't think to ask: Can you use this IdP as an OIDC Provider — not just an OIDC consumer?

Why it matters: As your SaaS grows, partners and customers may want to use your identity system to log into their own tools. You need to issue tokens, manage consent, and handle third-party app registrations. If your IdP only lets you consume external identity providers but can't act as one, you'll hit a wall when you need to federate outward.

Ask:

Does the IdP expose an OpenID Discovery endpoint you can white-label?
Can you register first-party and third-party applications with different trust levels?
Can first-party apps skip the consent screen while third-party apps require it?

JWT customization

The token is the contract between your IdP and your services. If you can't customize it, every downstream service needs to make additional API calls to figure out what a user is allowed to do.

Ask:

Can you add custom claims to access tokens and ID tokens?
Can you embed organization context (which tenant the user is operating in) directly in the token?
Can you define custom scopes that map to your application's permission model?
Are claims computed at token issuance time, or can they be dynamically populated via a webhook or script?

A token that carries { "org_id": "org_123", "role": "admin", "auth_level": 2 } means your API middleware can make authorization decisions in one line. A token that only carries { "sub": "user_456" } means every service needs to call back to the IdP or a database to figure out the rest. At scale, that difference is the difference between 2ms and 200ms per request.

Dimension 2: Authentication flows — The details that kill you

Every IdP supports email/password and social login. Congratulations, you've narrowed the field to... all of them.

The differentiation is in the details most demo scripts don't cover.

The sign-up flow

Post-registration auto-login: After a user signs up, are they automatically logged in? Or do they see a login page again? Forcing a user to log in immediately after registering is a conversion killer. You'd be surprised how many IdPs get this wrong.
Custom registration fields: Can you collect role, company name, or use case during sign-up? Or do you need a separate onboarding flow after the fact?
Progressive profiling: Can you collect additional information over multiple sessions, rather than demanding everything upfront?

The login flow

login_hint support: When a user clicks a link from a marketing email, can you pre-fill their email address? This sounds trivial. It's not. It's the difference between a 40% and 60% conversion rate on email campaigns.
Organization-specific authentication policies: Can Org A require SAML SSO while Org B uses email/password? Can you enforce MFA for enterprise tenants only? If per-tenant auth policies require code changes instead of configuration changes, you'll burn engineering cycles every time you onboard an enterprise customer.
Branding customization: Can you customize the login experience per tenant? Not just logo and colors — full CSS control, custom domains, and white-labeled emails. "Hosted UI vs. bring your own UI" should be a choice you make, not a limitation you accept.

What most checklists miss

Silent authentication: When a token expires, can the app silently refresh without redirecting the user? What happens if the refresh token is also expired — is there a fallback (like a sliding session via iframe)?
Account linking: A user signs up with Google, then tries to log in with email. Are these two accounts, or one? How does the IdP handle identity merging? Get this wrong and you'll have phantom duplicate accounts forever.
Passwordless options: Magic links, passkeys, WebAuthn. Not because everyone needs them today, but because your enterprise customers will ask within 6 months.

Dimension 3: Session and token management — The deep water

This is where evaluations get separated from demos. Session and token management is boring until it breaks — and when it breaks, your entire user base gets logged out simultaneously.

Cookie security

Not glamorous. Absolutely critical.

HttpOnly, Secure, SameSite attributes: All three must be set correctly. Any IdP that doesn't set HttpOnly on session cookies is not ready for production.
Cross-subdomain support: If your app runs on app.yourproduct.com and your API on api.yourproduct.com, can sessions span subdomains? How?
Third-party cookie deprecation: Chrome is phasing these out. How does the IdP handle cross-origin auth flows without third-party cookies? If the answer is "we're working on it," that's not good enough.

Remember me and persistent sessions

Your users want to stay logged in for weeks, not minutes. But a 180-day persistent session has very different security implications than a 30-minute session.

Ask:

Can you configure session duration independently from token lifetime?
Is there a "remember me" option that extends the session while keeping token lifetimes short?
Can you force re-authentication for sensitive operations without terminating the session?

Refresh token security

Token rotation: Does the IdP rotate refresh tokens on each use? (It should.)
Encrypted storage: Are refresh tokens encrypted at rest?
Revocation granularity: Can you revoke a single device's session without revoking all sessions?
Configurable expiration: Different apps need different refresh token lifetimes. Can you configure this per-application, or is it a global setting?

Dimension 4: Authorization model — Beyond basic RBAC

Role-Based Access Control is the baseline. If the IdP doesn't support RBAC, it's not worth evaluating. But for B2B SaaS, RBAC alone isn't enough.

Organization-scoped permissions

Your users belong to organizations. Their permissions within each organization are different from their platform-level permissions.

A user might be an admin in Org A and a viewer in Org B. The same user, two different role contexts. If the IdP can't model this natively, you'll build a parallel permissions system in your application — and now you have two sources of truth.

Questions:

Can you define roles at the organization level, not just the user level?
Can a single user have different roles in different organizations?
Is the current organization context embedded in the token, so your API knows which org the user is operating in?

Multi-level authorization (auth_level)

For financial applications, healthcare, or any product where certain operations carry higher risk: not all authenticated sessions are equal.

Viewing a dashboard? Session cookie is fine. Initiating a wire transfer? You need a fresh MFA verification, even if the user is already logged in.

This is step-up authentication, and it requires the concept of an authentication level (auth_level) as a first-class citizen in the token system.

Ask:

Can the token carry an auth_level claim that your backend can check?
Can you trigger step-up authentication from your application without forcing a full re-login?
Does the auth_level have its own expiration, independent of the session?

If your IdP doesn't support this natively, you'll end up building it yourself — which is exactly the kind of identity logic you're buying an IdP to avoid.

Token-based authorization decisions

The ideal: your API middleware reads the token, sees the user's org, role, and auth level, and makes the authorization decision without hitting any external service.

The reality with many IdPs: the token tells you who the user is, but you need a separate API call to figure out what they're allowed to do.

That separate call adds latency, creates a dependency, and introduces a failure mode. At 1,000 requests per second, you don't want your authorization check making network hops.

Dimension 5: Migration — The criterion that decides everything

Here's a statistic nobody likes to talk about: most IdP evaluations end not because the new IdP isn't good enough, but because the team can't figure out how to migrate their existing users.

If you have 100K+ users, migration isn't a "nice to have" — it's the entire project.

Three migration strategies (and which ones the IdP must support)

1. Bulk import with existing password hashes

Your users have passwords hashed with bcrypt, argon2, or whatever your current system uses. Can the IdP import those hashes directly and verify passwords against them?

If yes: users log in with their existing password, and nothing changes from their perspective. Best case scenario.

If no: every user gets a "reset your password" email. You will lose 30-50% of your user base in the migration. This is not hypothetical — we've seen it happen.

2. Progressive (lazy) migration

Instead of migrating all users at once, you migrate them one by one as they log in. The first login hits your old system, verifies the password, and creates the user in the new IdP. Every subsequent login goes directly to the new IdP.

This is the safest approach for large user bases, but it requires the IdP to support:

A custom authentication hook that calls your legacy system
The ability to create users on-the-fly during login
Tracking which users have been migrated vs. which haven't

3. Dual-write (running systems in parallel)

During transition, both the old and new identity systems are active. Writes go to both, reads gradually shift to the new system. This provides a rollback path but adds operational complexity.

Migration red flags

"We support CSV import" — This means bulk import of user profiles, not passwords. You'll still need password resets.
"We have a migration guide" — Read it carefully. If it says "users will need to set a new password," that's the 30-50% user loss scenario.
No mention of hash compatibility — If the vendor hasn't thought about password hash migration, they haven't worked with teams at your scale.

Questions to ask

Which password hash algorithms do you support for import? (bcrypt, argon2, scrypt, PBKDF2, custom?)
Can we run a progressive migration where users are migrated on first login?
Can we track migration progress — what percentage of users have been migrated?
What's the rollback strategy if migration doesn't go well?
Can we maintain session continuity — so users don't get logged out during migration?

If the vendor can't answer these confidently, they haven't done this before. Move on.

Dimension 6: Multi-tenancy — Native vs. bolted on

B2B SaaS means multi-tenancy. Your customers are organizations with multiple users, roles, and access policies. The IdP needs to understand this natively.

What "native multi-tenancy" means

Organization as a first-class entity: Not a custom field on the user profile, but a proper data model with its own ID, configuration, and membership list.
Per-organization authentication policies: Org A uses SAML SSO with their corporate IdP. Org B uses email/password with mandatory MFA. Org C uses Google Workspace login. All configured via UI or API, not code changes.
Organization invitations and membership management: Admins within each org can invite users, assign roles, and remove members. The IdP handles the invitation flow, email verification, and role assignment.
Organization-scoped tokens: When a user operates within an organization, the token includes the org context. Your API knows which org's data to return.

The "custom metadata" workaround

Some IdPs don't have a native organization model. They suggest using custom user metadata (user.app_metadata.org_id = "123") as a workaround.

This falls apart fast:

A user belonging to multiple orgs requires array management in metadata
No built-in invitation or membership flow
No per-org auth policies
No org-scoped tokens — you have to infer context from other signals
Audit logs don't know about organizations

If the vendor says "you can model organizations using our metadata fields," that's the identity equivalent of storing relational data in a JSON column. It works until it doesn't.

Questions to ask

Is the organization model native or built on top of user metadata?
Can users belong to multiple organizations simultaneously?
Can we configure different authentication requirements per organization?
Are organization-scoped roles and permissions supported natively?
Can organization admins manage members via a self-service UI?
Does the token include organization context?

Dimension 7: AI-readiness — The criterion nobody's asking yet

Twelve months ago, "AI agent authentication" wasn't on any evaluation checklist. Today, if you're building AI features into your product — copilots, autonomous agents, AI-driven workflows — your IdP needs to handle a new type of identity: the agent.

Why agents break the traditional model

Traditional auth has two actors: the user and the application. OAuth2 was designed around this.

AI agents introduce a third: a non-human entity that acts on behalf of a user, with constrained permissions, and needs its own audit trail.

An agent isn't a user — it doesn't have a password or a browser session
An agent isn't a machine-to-machine service — it's acting on behalf of a specific user
An agent needs scoped, time-limited permissions — not the full access the user has

What your IdP needs to support

Token Exchange (RFC 8693): The agent presents its own credential plus the user's authorization, and receives a scoped token. The token carries: who (the user), what (the agent), scope (the permission boundary), and when (the expiration).

Agent as a client type: The agent should be modeled as a proper OAuth2 client with its own client_id, not a hack using API keys or shared user tokens.

Delegated scope management: The user can grant specific permissions to the agent — read but not write, access to certain resources but not others.

Audit distinction: Your logs must differentiate between "user did X" and "agent did X on behalf of user." If you can't distinguish these, you'll fail your next SOC2 audit when the auditor asks "who made this change?"

MCP (Model Context Protocol) compatibility

MCP is becoming the standard protocol for AI agents to interact with tools and services. If your IdP supports OAuth-based authentication for MCP servers, agents can authenticate properly through the protocol layer rather than through API keys or shared secrets.

Questions to ask

Do you support OAuth2 Token Exchange?
Can agents be modeled as distinct client types?
Can tokens carry delegation information (who authorized the agent, what scope)?
Do audit logs distinguish agent actions from human actions?
Is there MCP server integration or OAuth support for agent-to-tool authentication?

If the vendor hasn't thought about this, they're building for 2020. You're planning for 2026.

Dimension 8: Non-functional requirements — The stuff that keeps you up at night

Features sell. Operations decide whether you renew.

Performance

Authentication throughput: Can the system handle 100+ auth requests per second during peak? What about 1,000+?
Token validation latency: If your services validate JWTs locally (as they should), this is sub-millisecond. But if the IdP requires introspection calls, what's the P99 latency?
Scale ceiling: What's the maximum Monthly Active Users (MAU) supported? Is there a demonstrated track record at your target scale?

Compliance

SOC2 Type II: Not Type I. Type II means they've been audited over a period, not just at a point in time. If they only have Type I, ask when Type II is expected.
Audit logs: Every authentication event, permission change, and admin action logged. Can you export logs to your SIEM? Are logs immutable?
Data residency: Can you specify which region stores user data? For EU customers, this isn't optional.

Reliability

Uptime SLA: 99.9% sounds good until you realize that's 8.7 hours of downtime per year. 99.99% is 52 minutes. For authentication — the front door of your application — the difference matters.
Failover: What happens during a provider outage? Is there a fallback mechanism? Multi-region deployment?
Incident history: Check their status page history. Not what they promise — what actually happened.

Data portability

User export: Can you export all user data, including metadata, organization memberships, and roles? In what format?
Standards compliance: Are they using standard protocols (OIDC, SCIM) that make migration to a different provider feasible?
No lock-in signals: Proprietary APIs, custom protocols, non-standard token formats — these are lock-in indicators. The more proprietary the integration, the harder it is to leave.

The evaluation matrix: A practical scoring framework

After evaluating across all dimensions, you need a way to compare. Here's a priority framework:

P1 — Deal-breakers (must pass or disqualify)

Criterion	Why it's P1
Password hash import or progressive migration	Can't use it if you can't migrate
Authorization Code + PKCE support	Security baseline
Native organization model	B2B SaaS requirement
SOC2 Type II or clear path to it	Enterprise customers will ask
99.9%+ uptime SLA	Auth down = product down

P2 — Strongly preferred (significant engineering effort if missing)

Criterion	Why it's P2
Custom JWT claims	Avoids per-request permission lookups
Per-org authentication policies	Enterprise customer onboarding
Organization-scoped roles and tokens	Multi-tenant authorization
Refresh token rotation and revocation	Security best practice
Hosted UI + custom UI option	Flexibility for different use cases

P3 — Important (plan for within 12 months)

Criterion	Why it's P3
Token Exchange (RFC 8693)	AI agent authentication
OIDC Provider capability	Partner federation
Step-up authentication / auth_level	Financial or high-risk operations
SCIM provisioning	Enterprise customer directory sync
Passkey / WebAuthn support	Passwordless direction

P4 — Nice to have (won't block decision)

Criterion	Why it's P4
Built-in analytics dashboard	Can build from audit logs
White-labeled email templates	Convenience feature
Visual flow builder	Convenience feature
Pre-built social connectors (beyond top 5)	Long tail providers

How to use this: Start with P1. If a vendor fails any P1 criterion, stop evaluating them. Then score P2 and P3 categories. The vendor with the best combined P2+P3 score is your answer.

Common evaluation mistakes

We've seen teams make the same mistakes repeatedly. Here's how to avoid them:

Mistake 1: Evaluating on features, not architecture

A feature comparison table tells you what exists. It doesn't tell you how it's built. An IdP might "support" organizations by storing org IDs in user metadata. That checks the box on a spreadsheet but creates real problems in production.

Fix: For every feature, ask "how is this implemented?" — not just "do you have this?"

Mistake 2: Ignoring migration until after selection

Teams pick the "best" IdP, start implementation, and then realize they can't migrate their users without a password reset campaign. Now they're either stuck with a bad migration experience or starting the evaluation over.

Fix: Make migration capability your first filter, not your last.

Mistake 3: Over-indexing on the demo

Every vendor's demo is polished. It shows the happy path with a clean database and zero edge cases. Your production environment has users with merged accounts, weird unicode in profile fields, and sessions that shouldn't exist but do.

Fix: Ask for a proof-of-concept with your actual data. Import 1,000 real users and run your actual authentication flows.

Mistake 4: Not involving the right people

If only the platform team evaluates, they'll pick what's technically cleanest. If only product evaluates, they'll pick what's easiest to integrate. If only security evaluates, they'll pick what has the most compliance checkboxes.

Fix: Evaluation team should include platform engineering, product, and security. Each owns different P1/P2 criteria.

Mistake 5: Forgetting you'll need to leave someday

Vendor lock-in is real. Proprietary SDKs, custom APIs, non-standard token formats — they all make migration harder later.

Fix: Prefer IdPs that use standard protocols (OIDC, OAuth2, SCIM). Your future self will thank you.

FAQ

How long does an IdP evaluation typically take?

For a thorough evaluation including proof-of-concept testing, expect 4-8 weeks. Rushing it leads to the mistakes we outlined above — particularly the migration oversight. Budget 2 weeks for requirements gathering, 2-3 weeks for vendor evaluation and PoC, and 1-2 weeks for stakeholder alignment.

Should we build our own auth instead?

It depends on your stage. If you have fewer than 10,000 users and no enterprise customers, a lightweight auth library might be fine. But once you need SSO, multi-tenancy, MFA, and compliance documentation, the maintenance cost of homegrown auth exceeds the cost of a dedicated IdP. We've seen engineering teams spend 2-3 full-time engineers maintaining custom auth systems — that's $300-500K/year in opportunity cost.

What's the difference between CIAM and workforce IAM?

Customer Identity and Access Management (CIAM) is what your product's end users interact with — sign-up, login, profile management. Workforce IAM is what your employees use to access internal tools (Okta for your company's Slack, Google Workspace, etc.). They're different buying decisions with different evaluation criteria. This guide is about CIAM.

How important is open-source vs. proprietary?

Open-source IdPs offer transparency (you can audit the code), portability (self-host if needed), and community contributions. Proprietary IdPs may offer more polished UIs and managed services. The key question isn't "open vs. closed" — it's "can I leave if I need to?" Open-source solutions tend to make leaving easier because the data model and APIs are public.

When should AI agent authentication be a P1 instead of P3?

If you're already building AI features that access user data on behalf of users (copilots, automated workflows, AI assistants), move it to P1 now. If AI features are on your 6-12 month roadmap, keep it at P3 but weight it heavily. If AI isn't on your radar, it can stay P4 — but revisit in 6 months.

How do we evaluate pricing when vendors use different models?

Most IdPs price by Monthly Active Users (MAU). But "MAU" definitions vary — some count any login, others count unique users, some count M2M tokens separately. Get the vendor to quote your specific scenario: X users, Y organizations, Z M2M connections, with your expected authentication volume. Compare total cost, not unit price.

The bottom line

Choosing an identity provider is an infrastructure decision, not a feature decision. You're committing to a system that will handle every user's first interaction with your product, every permission check in your API, and every audit log entry your compliance team reviews.

The evaluation framework above covers what actually matters — not the marketing bullet points. Use it to filter candidates quickly (P1 criteria first), evaluate deeply (P2 and P3 criteria with proof-of-concept testing), and make a decision that holds up for years, not months.

The teams that get this right share one thing in common: they treat identity as infrastructure, not as a feature to ship and forget.

Remote MCP server in action: a new entry point for SaaS products in the AI era

Xiao Yijun — Wed, 04 Feb 2026 15:42:40 +0000

SaaS products have a long-standing problem: time-to-value is too slow. A lot of users churn before they reach the “aha” moment.

We’ve iterated on Logto onboarding a bunch of times. It helped, but the bottleneck didn’t go away. You still end up reading docs, skimming tutorials, installing SDKs, wiring configs, writing code, then debugging the last 10% before anything works.

So we tried a different approach: a remote MCP server as Logto’s IDE-native control plane. Instead of clicking through an admin console, you configure Logto and generate integration code through a conversation, right where you’re building the app.

One prompt can take you from zero to a working integration. The agent doesn’t just generate code, it also creates and configures the Logto application in your tenant. All from inside your IDE. (Try Logto MCP Server)

In this article, I will share our experience and thinking around building the Logto MCP Server, including:

MCP vs. Agent Skills: why we chose MCP
Problems we met when shipping an MCP server, and how we solved them
How we design MCP tools, and how you should design yours
Our expectations for the future of MCP

The OAuth implementation of the Logto MCP Server is based on mcp-auth and Logto. If you are interested in MCP server OAuth, you can refer to this open source project.

MCP vs. Agent Skills: why we chose MCP

Before deciding how AI should access Logto, we evaluated two options: MCP servers and Agent Skills.

MCP servers have two forms: local and remote.

A local MCP server runs on the user’s machine. It requires service installation, environment setup, credentials, or special login flows. In usage and delivery, it is very similar to skills.

A remote MCP server is hosted on the server side. Users connect by URL and authorize with OAuth. This model is closer to SaaS service extension.

From a structure view, an Agent Skill is a combination of "business logic + underlying capabilities". Those capabilities can be tools, CLIs, or API calls. MCP tools can carry this layer in a unified way.

So the key question is not how capabilities are implemented, but how they are delivered to users.

Agent Skills deliver: a full local toolchain (Skill package + local runtime + API keys or platform credentials + CLI tools + install, config, upgrade, and maintenance flow).

In essence, you give the capability to users to run by themselves.
Remote MCP servers deliver: a remote service entry (URL + OAuth login).

In essence, you provide the capability as a service.

Below, we compare them from user experience, ecosystem reach, and delivery and maintenance cost.

User experience

Agent Skills usually depend on platform APIs or CLIs. Users must create API keys or install and log in to CLIs first. These steps are not complex, but they raise the entry barrier.

MCP servers support OAuth. Users log in with their SaaS account. The experience is like “Sign in with Google.”

For users, using an MCP server is simple: enter a URL, log in, connect. This is the experience we want to deliver.

Ecosystem reach

On the MCP website, there are already 104 AI apps that support MCP, including tools like VS Code, Cursor, and Windsurf.

Agent Skills are still platform-specific. Even if many platforms start to support them, when we ship an MCP server, users can use it immediately. When we ship a Skill, only users on that platform can use it.

MCP is also included by the Agentic AI Foundation (AAIF). It is a protocol-level standard. The ecosystem will keep growing. For us, this makes MCP worth long-term investment.

Delivery and maintenance cost

Agent Skills depend on platform APIs or CLIs, which quickly brings problems:

What if the API changes?
What if the CLI breaks compatibility?
How do you upgrade and redistribute the Skill?

You also need to distribute CLIs, manage scattered credentials, adapt to multiple platforms, and guide users to upgrade. The ROI is very low.

MCP servers are much simpler. Users connect to a URL. It always points to the latest version. When we update the MCP server, users get it next time they connect. No upgrades needed. If APIs change, we update them inside the MCP server.

Most SaaS products already have strong infrastructure: solid APIs and mature auth systems. An MCP server fits naturally as the “AI interface” of the API, just like an admin console is another interface on top of the same APIs.

For Logto, choosing an MCP server fits our architecture and uses our strengths.

It also centralizes all requests into one entry point. Logs and audits are easier. Permissions are clear: AI can only do what the user authorizes. This model is structurally cleaner for enterprise and compliance scenarios.

Problems we met when shipping an MCP server, and how we solved them

MCP is not perfect. Most issues are ecosystem maturity problems. They will improve over time. Before that, we use workarounds to meet real needs.

Fragmented MCP feature support

The MCP spec defines many features, but client support varies:

Tools: widely supported
OAuth: well supported in VS Code; tools like Cursor need mcp-remote as a bridge
Other features (Resources, Prompts, Instructions): inconsistent support

Right now, tools are the most reliable common layer (check out the MCP Community Page to see what features each client supports).

So our strategy is simple: build on tools.

LLM does not know how to use your tools

This is a business-layer problem.

With Agent Skills, business logic and context are packaged together. The LLM knows how to use them. MCP only provides tools. After connection, the LLM does not know:

The usage scenarios
The call order
The business constraints

MCP has the concept of Instructions, but not all clients support it. Instructions also push all content into context at connection time, which wastes tokens.

Another idea is to put guidance into tool descriptions. But this causes two problems:

Descriptions become complex. Multi-tool workflows create tangled logic and are hard to maintain.
As tool count grows, descriptions consume large parts of the context window.

Our workaround: provide a getInstructions tool

The idea is simple: if Instructions are not well supported, turn them into tools.

The LLM can call getInstructions on demand.

For task A, it calls getTaskAInstructions. The MCP server returns a prompt that explains how to complete task A and how to combine other tools.

Complex business logic stays behind the instruction tools. Other tools stay simple. Tool descriptions focus only on their own function.

This is similar to Agent Skills: prompts are loaded on demand. It is also more efficient than global Instructions because it avoids dumping everything into context.

LLM may leak your secrets

For many SaaS products, some secrets must never be exposed (for example, client secrets, API keys, or webhook signing keys). If they leak, others can impersonate you or gain direct access to resources.

The risk with LLMs is that a chat is not a secure channel. Conversations can be logged, copied, forwarded, or end up in debugging logs. You cannot assume “only me and the model can see this.” So handing a long-lived secret to an LLM, or asking it to output a secret for users to copy, is high risk.

This is common in traditional web app integrations: developers often need a secret, put it into server environment variables or config files, and then finish steps like initializing SDKs.

To keep onboarding easy without weakening secret safety, we do three things:

Use temporary secrets during integration

During the chat-based setup, the MCP server only returns short-lived temporary secrets (for example, valid for 1 hour). They are enough to get the integration working, and they often expire before you go live. Before going live, developers create and replace them with long-lived production secrets outside the chat.

Make the security boundary explicit

We clearly warn users: do not create, paste, or store production secrets in the chat. We also remind developers that even environment variables or config files can leak if an agent / LLM can read them through tools or indirect access. Put production secrets only in environments where no AI-assisted integration is used.

Do not handle production secrets in chat; guide users to the console

Long-lived secrets are not generated or distributed through the chat. They are created and managed in the console credentials page. In the chat, we only provide a direct link to the console so users can complete production secret setup there.

How we design MCP tools

Our path

Logto has a full Management API. Our first idea was simple: expose every API endpoint as an MCP tool.

This failed quickly.

First, context explosion. Logto has many APIs. Mapping them one-to-one fills the context window. Each tool description costs tokens.

Second, loss of meaning. APIs are atomic building blocks for developers. But users of the Logto MCP Server are not building systems. They just want to finish tasks. They do not care how many APIs exist.

Example: Logto has a sign-in-experience API for branding, sign-in methods, sign-up methods, and security policies.

At first, we thought about how to expose all parameters to the LLM. How to teach it to combine calls.

But this is the wrong mindset. Users are not calling APIs. They want to change branding or configure login methods.

So tools should be updateBranding, updateSignInMethod, updateSignUpMethod. The MCP server handles API composition internally.

Logto MCP Server should be treated as a product, not an API wrapper. It is "another admin console".

How to design MCP tools

The rule becomes clear:

If users directly use your service (like a console), tools should be business-oriented.
If you provide base capabilities for others to build on, tools should stay atomic and simple. Example: a filesystem MCP server with read_file, write_file, then coding agents combine them.

Additional principles:

Keep tool logic and descriptions simple to save context.
For complex workflows, use getInstructions tools to load guidance on demand. Keep their descriptions simple too.

Our expectations for the future of MCP

While building the MCP server, we also thought about what could improve the ecosystem.

Skill-level capability delivery

Sometimes MCP servers need to provide not just tools, but guidance on how to combine them into tasks, like Agent Skills.

This is common in SaaS. For example, GitHub MCP Server, Logto MCP Server, or analytics platforms. Users want workflows, not atomic calls.

getInstructions tool is a workaround. Protocol-level support would be better.

Session-level MCP enablement

Clients connect to many MCP servers, but not every session needs all of them. Session-level enable/disable could reduce context waste.

Context isolation for MCP tool calls

Tool calls consume a lot of context. If MCP interactions are handled by sub-agents, the main conversation could receive only condensed results.

Conclusion

This is our experience with building a remote MCP server.

If you are exploring this direction, try the Logto MCP Server or join our Discord to exchange real-world implementation experience with the community.

We will also share architecture design and OAuth flow details in future posts.

Ship user authentication with one prompt: introducing Logto MCP Server

Xiao Yijun — Wed, 04 Feb 2026 15:34:50 +0000

"Integrate Logto into my project"

One prompt, and you get a working auth setup.

Today we’re launching Logto MCP Server: a hosted MCP server that lets your AI tool set up Logto for your app. No local installation. No copying API keys.

The agent can inspect your project, create a Logto application, apply the right settings, and generate integration code you can run. What used to be a multi-step setup becomes a short conversation, inside your IDE.

Get started in 2 steps

Add Logto MCP Server to your AI tool (Cursor, VS Code, OpenCode, Claude Desktop, and any client that supports MCP authorization)
Ask it to integrate Logto

No API keys to copy around. You authenticate once, then you can start working.

What you can do

"Integrate Logto into my project"

The agent detects your stack, creates the Logto app, and generates working integration code. It supports 38+ quick starts, including React, Next.js, Vue, Nuxt, SvelteKit, Express, Go, Python, iOS, Android, Flutter, and more.

"How do I set up social login?"

Ask questions in plain English. The agent searches Logto docs and answers with citations, so you can verify and keep moving.

Built for developers

Hosted MCP server, no local installation required
Works with your tools: Cursor, VS Code, OpenCode, Claude Desktop, and any client that supports MCP authorization
Secure by default: OIDC/OAuth 2.1 compliant, plus RBAC, MFA, CAPTCHA, and more
Standards-based auth for MCP: uses the MCP Authorization spec, powered by mcp-auth (our open source project bringing standard auth to MCP servers)

What's next

This first release is about the “quick start” path: get a working sign-in flow running quickly.

Next, we’re expanding what the MCP server can configure and guide you through:

Sign-in experience: branding, sign-in methods, social providers
RBAC: roles, permissions, and recommended patterns
Multi-tenancy: organizations and B2B SaaS setups

If you want to influence the roadmap or you hit rough edges, join our Discord!

Learn more

👉 Get started with Logto MCP Server
🌟 Explore Logto features

Online sign-up form builder: From authentication to user profile collection

Xiao Yijun — Fri, 30 Jan 2026 07:27:09 +0000

Picture this: A potential customer discovers your amazing product, gets excited about what it can do for them, clicks that bright "Get Started" button... and then abandons your site within seconds. Sound familiar? You're not alone. The sign-up form is the digital equivalent of a first date—mess it up, and there's rarely a second chance.

In today's hyper-competitive digital landscape, your registration form isn't just a data collection tool—it's your conversion battleground. The difference between a thoughtfully crafted authentication experience and a generic, friction-heavy form can mean the difference between explosive growth and stagnant user acquisition.

Enter Logto's revolutionary no-code sign-up form builder. This isn't just another auth solution; it's your secret weapon for turning curious visitors into engaged users while collecting the user profile data that powers truly personalized experiences.

Ready to see the transformation in action? Watch how Logto revolutionizes user registration from a technical headache into a competitive advantage:

What every sign-up form needs

Every high-converting sign-up form needs two fundamental elements that work in perfect harmony:

Authentication that actually works

Your authentication system is like a bouncer at an exclusive club—it needs to be secure but not intimidating. Smart businesses offer multiple entry points: traditional username/password combinations for the security-conscious, email or phone verification for the practical, social sign-ins for the convenience-seekers, and enterprise SSO for the corporate crowd. The magic happens when users can choose their preferred method without friction.

Strategic user profile collection

Beyond the basic "who are you?" questions, savvy products collect user profile data that serves real business purposes. Think personal details that enable customization, contact preferences that reduce spam complaints, and business-specific information that powers segmentation. For B2C products, this might mean preference data that improves recommendations. For B2B applications, it's company size, industry, and role information that enables targeted onboarding.

The golden rule? Collect only what you need immediately, then gather the rest progressively as users engage with your product.

Why every commercial product needs a strategic sign-up form

Here's a sobering reality check: According to FormStack's 2023 research, 67% of users will permanently abandon a form if they encounter any friction during the signup process. Even more shocking? Google's data reveals that 92% of users will leave a website if the sign-up process takes longer than 3 minutes.

But here's where it gets interesting—companies with optimized sign-up forms see conversion rates that are 25% higher than industry averages, and those leveraging social sign-in options experience up to 42% better completion rates.

Your registration form isn't just a gateway; it's your first sales conversation, your brand's handshake, and often the make-or-break moment that determines whether a curious visitor becomes a loyal customer. In SaaS businesses, improving signup conversion by just 10% can translate to millions in additional annual recurring revenue.

The challenge? User registration is merely the tip of the identity management iceberg. Modern products need authentication systems that scale from startup MVP to enterprise-grade platform without breaking a sweat. This is precisely where identity-as-a-service platforms like Logto transform the game—turning what used to be months of complex development into a few hours of smart configuration.

Step 1: Custom branding - make it yours

First impressions happen in milliseconds, and your registration form needs to feel like a natural extension of your brand. Logto's branding engine transforms generic auth screens into branded experiences that users trust.

Upload your logo, define brand colors, enable dark mode support, and add favicon customization for that professional polish. Multi-language support and legal compliance links are built-in. Navigate to Console > Sign-in Experience > Branding and configure everything in minutes.

Step 2: Sign-up and sign-in configuration

Configure your authentication methods to maximize both security and user conversion:

Flexible registration options:

Email/Phone/Username registration: Support multiple identifier types with email/SMS verification and password setup
Social sign-in integration: Reduce registration friction with pre-built connectors for major social platforms
Enterprise SSO: Enable corporate authentication for B2B applications

Additional flow configuration:

Sign-in methods: Define which authentication methods users can use for returning visits
Password recovery: Configure forgot password flows with multiple recovery options
Account linking: Allow users to connect multiple authentication methods to single accounts

These configurations ensure your registration form supports diverse user preferences while maintaining security standards appropriate for your application's risk profile.

Step 3: Collect additional user profile data (advanced capabilities)

This is where Logto's sign-up form builder becomes your conversion optimization secret weapon. The "Collect user profile" feature transforms basic registration into intelligent data gathering that fuels personalization engines without killing completion rates.

Navigate to Console > Sign-in Experience > Collect User Profile.

Logto offers both primitive and composite field types designed for real-world use cases.

Text fields handle everything from names to job titles with smart length validation.
Number fields capture ages, company sizes, and experience levels with range controls.
Date fields support multiple international formats because not everyone writes dates the same way.
Dropdown selects make choosing industries, departments, or countries effortless.
Checkboxes handle preferences and agreements without overwhelming users.
URL fields automatically validate social profiles and websites.
Need custom validation? Regex fields let you enforce specific formats for employee IDs, or any proprietary data structure.

The composite fields are where things get exciting.

Full name fields intelligently combine first, middle, and last names.
Address fields collect complete location data with configurable components for different regional requirements.

Every field becomes a conversion optimization opportunity through strategic customization.

Labels, descriptions, and placeholders provide clear guidance without cluttering the interface.
Type-specific configurations ensure each field behaves optimally for its data type. E.g, min/max lengths for text, range limits for numbers, format enforcement for URLs, data format for dates, default value for checkboxes, etc.
Required versus optional field configuration lets you balance data collection ambitions with completion rate realities.

Back to Collect user profile list page, the drag-and-drop interface makes field reordering effortless, while real-time validation ensures optimal user experience before you go live.

Step 4: Test with out-of-the-box sign-up flows

Navigate to Console > Sign-in Experience, click "Live Preview". The Live Preview feature lets you experience your complete signup process exactly as your users will. Test every authentication method, validate field behavior, confirm brand consistency, and check mobile responsiveness.

Create test accounts to validate the complete user journey, then manage them through Console > User Management.

Step 5: Publish and integrate

Logto meets you where you are, offering integration paths that fit your team's workflow and technical preferences.

Logto's comprehensive SDK library transforms integration from weeks to hours. Frontend SDKs for React, Vue, Angular, and Vanilla JavaScript come with pre-built UI components. Backend SDKs cover Node.js, Python, .NET, Java, and Go for seamless server-side authentication. Mobile SDKs handle React Native, iOS, and Android development. Framework-specific integrations optimize for Next.js, Express, and Spring Boot environments.

Or try a no-code integration solution powered by Cloudflare via Protected App when you’re using Logto Cloud.

Visit Console > Applications for comprehensive guides, code samples, and quickstart templates tailored to your technology stack.

Principles of high-converting sign-up forms

Building registration forms that actually convert requires balancing ambition with user psychology:

Social authentication improves completion rates by 20-40% by eliminating password friction
Every additional form field can reduce conversion by 10-15%, so collect only essential information upfront
Smart MFA waits until the second login session rather than creating registration barriers
Use progress indicators for multi-step flows and real-time validation that prevents errors

Logto's no-code sign-up form builder incorporates these principles automatically, ensuring your registration flows optimize for both conversion and user satisfaction while maintaining enterprise-grade security.

Conclusion

Building effective sign-up forms no longer requires months of development or choosing between user experience and security. Logto's no-code solution empowers teams to create sophisticated registration forms that convert visitors into users while collecting the user profile data that powers personalized experiences.

Logto transforms user registration from a technical challenge into a competitive advantage that moves your business metrics.

Ready to transform your user registration?

Logto Cloud puts production-ready authentication at your fingertips:

Free Development tenant lets you explore every feature without limits. Free Tier includes up to 50,000 MAUs—perfect for validating your product-market fit. Pro Plan starts at just $24/month for growing businesses that need advanced features and higher usage limits. Enterprise Solutions provide custom deployments with dedicated support for scale.

Prefer to keep everything in-house? Logto OSS delivers the complete open-source identity platform with full feature parity for independent deployment.

Start building your perfect sign-up form today →

Stop losing users to friction. Start converting them with Logto's intelligent sign-up form builder. Your conversion metrics and your users will thank you.

Logto 2025: scaling and trust

Xiao Yijun — Wed, 21 Jan 2026 03:51:30 +0000

2025 was the year Logto got a lot bigger:

Logto Cloud grew ~10x in MRR year over year
Identities in Logto Cloud grew from under 1M to 2M+
Logto OSS gained 2,000+ GitHub stars

We also served more enterprise customers, kept SOC 2 Type II current, improved GDPR-related work, and shipped a lot across authentication and authorization.

More of our growth came from larger customers with stricter requirements around data residency and isolation, so we leaned heavily on Private Cloud there.

Private Cloud: why enterprises picked it

For enterprise teams, features are table stakes. The real decision is about the “boring” requirements: isolation, data residency, performance, security review, and reliability.

Logto Private Cloud exists for that:

data residency options that match compliance requirements
infrastructure-as-code and flexible cloud setup, making rollouts smooth and scalable

Example: for one European organization, we deployed two Private Cloud instances in about a week. Each is sized for 1,000+ RPS with headroom.

What we shipped

We aim to keep changes practical and aligned with OIDC and OAuth. A few highlights:

more connectors to reduce integration time across common IdPs and ecosystems
Logto as a SAML IdP for better compatibility with enterprise and legacy systems
CAPTCHA and security policies to reduce abuse and automated attacks
magic links for additional passwordless sign-in options and user invitation flows
secret vault for federated token storage
user profile collection for onboarding and progressive profile completion

Open source

Logto OSS gained 2,000+ stars in 2025, plus amazing community work like custom password hashing support and new connectors.

Open source is how most people find Logto, test it, and decide whether to trust it. We’re not changing that.

MCP and agent auth

We started MCP Auth work to support AI and agentic workflows. As more software becomes agent-driven, identity and authorization need to keep up. More on this in 2026.

Reliability: what changed for us

In 2025, we saw fewer incidents caused by regressions. Most issues came from upstream dependencies or cloud infrastructure.

That’s not an excuse to say it wasn’t on us. The biggest gap wasn’t the fix, it was speed and clarity of updates. We’re tightening that up.

2026 priorities

reliability, incident communication, and operational maturity
making Logto the default choice for modern multi-tenant SaaS where security and UX both matter
pushing forward on MCP and agentic auth

If you’re building a SaaS or AI product and need modern auth that scales, Logto is built for it.

Logto product updates

Xiao Yijun — Wed, 21 Jan 2026 03:42:08 +0000

We're excited to announce Logto v1.35.0, our December 2025 release! This update brings enhanced reCAPTCHA customization options, expanded support for third-party applications, and improved security features for passwordless authentication.

reCAPTCHA Gets More Flexible

Use reCAPTCHA Anywhere with Domain Customization

One of the most requested features has been the ability to use reCAPTCHA in regions where Google's default domain may be inaccessible. With v1.35.0, you can now customize the reCAPTCHA domain to use alternatives like recaptcha.net, ensuring your bot protection works seamlessly for users worldwide.

Choose Your Verification Style with Checkbox Mode

reCAPTCHA Enterprise users now have a choice between two verification modes:

Invisible mode: The default score-based verification that runs silently in the background, providing a frictionless user experience while still protecting against bots.
Checkbox mode: The classic "I'm not a robot" widget that many users are familiar with. This mode provides explicit user interaction and can be useful when you want users to consciously acknowledge the verification step.

Simply ensure your verification mode matches your reCAPTCHA key type configured in Google Cloud Console, and you're ready to go.

Third-party Apps: Now for SPA and Native Too

Previously, only traditional web applications could be designated as third-party apps in Logto. This release removes that limitation, allowing you to create third-party single-page applications (SPA) and native applications.

This enhancement opens up more flexible OAuth/OIDC integration scenarios, whether you're building a partner ecosystem, enabling third-party integrations, or managing multiple client applications with different trust levels.

Enhanced Security for Passwordless Authentication

Client IP Tracking

For organizations that need additional security controls around passwordless authentication, we've added client IP address tracking to the connector message payload. The SendMessageData type now includes an optional ip field that HTTP email and SMS connectors can utilize for:

Rate limiting: Prevent abuse by limiting requests from specific IP addresses
Fraud detection: Identify suspicious patterns based on IP geolocation or reputation
Audit logging: Maintain comprehensive logs for security compliance

Smarter Email/SMS Template Handling

We've improved the template fallback logic for email and SMS connectors. If a usage-specific template isn't found, the system now gracefully falls back to the generic template. This includes checking the generic template with the default locale when locale-specific templates are unavailable, ensuring your users always receive properly formatted messages.

Bug Fixes

SAML Integration Improvements

Extended relay state support: The relay state column now supports up to 512 characters (previously 256), fixing integration issues with service providers like Firebase that generate longer relay state values.
Better error messages: SAML authentication flow APIs now provide more straightforward error messages, making troubleshooting easier.

API Parameter Fix

Fixed a parameter naming issue in the SAML app creation API that could cause filter and paywall calculation errors.

Get Started

Ready to upgrade? Check out our upgrade guide for step-by-step instructions.

For the complete list of changes, see the GitHub release page.

Have questions or feedback? Join us on Discord or open an issue on GitHub.

How to implement guest mode (anonymous users) and convert to Logto users

Xiao Yijun — Wed, 21 Jan 2026 03:31:17 +0000

Many apps let users try features before signing up. Think shopping carts, document drafts, or saved preferences. Users expect this "guest mode" to just work.

But if you're using Logto (or any OIDC provider) for authentication, you might wonder: how do I handle these anonymous users?

The short answer: Logto handles authentication, your app handles guest sessions. They're separate concerns.

In this article, I'll show you a simple three-phase pattern to implement guest mode with Logto. You'll learn how to:

Manage guest sessions in your backend
Let guests sign up through Logto
Merge guest data to the real user account

Why there's no "anonymous login" in Logto

You might expect Logto to have an "anonymous login" feature. Something like: call an API, get a token, no user interaction needed.

But that's not how OIDC works. Here's why:

OIDC is built around user consent. The whole point is to verify "who is this person?" An anonymous token would mean "this is someone, but we don't know who" — which defeats the purpose.

Think of it this way:

Authentication = proving identity ("who are you?")
Session tracking = remembering actions ("what did you do?")

Guest mode is about session tracking, not authentication. So it doesn't belong to your auth system.

This is actually good news. It means you have a clean separation:

Logto handles identity (sign-up, sign-in, tokens)
Your app handles guest sessions (before identity exists)

Let each system do what it's designed for.

The three-phase solution

Here's the pattern: Guest → Auth → Merge

Phase 1: Handle guest sessions without authentication

Your backend creates and manages guest sessions. Logto isn't involved yet.

When a user takes a meaningful action (like adding to cart), your backend:

Generates a guest ID (e.g., UUID)
Returns it as a cookie or JWT
Stores user actions under this guest ID

Keep it simple. A guest_sessions table with guest_id, data, and created_at is enough.

Phase 2: Let users sign in with Logto

When the user clicks "Sign up" or "Sign in", trigger the standard Logto OIDC flow.

The guest ID stays in the cookie/storage during this process. After successful authentication, your frontend now has:

An access token from Logto (user identity)
The guest ID from before (guest data)

Phase 3: Securely merge guest data to authenticated users

Now connect the dots. Call your backend API with both:

POST /api/merge-guest
Authorization: Bearer <access_token>
Body: { "guestId": "guest_abc123" }

Your backend must validate both tokens before merging:

Validate the access token → extracts user ID. See Validate access tokens for how to do this with Logto.
Validate the guest ID → confirm it's a real guest session your backend issued. This is critical — never trust a guest ID from the client without verification.

Only after both validations pass:

Merge guest data to the user account
Invalidate the guest session

The merge logic depends on your business. Shopping cart? Combine items. Document drafts? Transfer ownership. You decide.

How to secure your merge endpoint with token validation

The merge endpoint is a sensitive operation. A few things to keep in mind:

Always validate the access token. Don't just read the user ID from the request body. Decode and verify the JWT. Here's how to do it with Logto.
Always validate the guest ID. Check it exists in your database and hasn't expired. If you issued it as a JWT, verify the signature.
Require authentication. The merge endpoint should reject requests without a valid access token.
Set a TTL for guest sessions. Clean up abandoned sessions after 30 days (or whatever makes sense for your app).

Conclusion

Guest mode with Logto follows a simple pattern:

Guest (your app) → manage sessions before users sign up
Auth (Logto) → handle sign-up and sign-in
Merge (your app) → connect guest data to real users

This pattern works with any OIDC provider, not just Logto. The key insight is: authentication and session tracking are separate concerns. Let each system do what it's built for.

Secure Google API access with OAuth authorization and token storage

Xiao Yijun — Tue, 19 Aug 2025 01:31:38 +0000

In today's interconnected digital landscape, applications that can effortlessly integrate with third-party services provide exceptional user experiences. Whether you're building a productivity suite, an AI agent, or a document collaboration platform, the ability to securely access and utilize APIs from services like Google, GitHub, Facebook, or any other services can transform your application from good to indispensable.

Today, we'll explore how Logto's Secret Vault and Social Connector capabilities enable you to build a smart productivity application that integrates with Google APIs. We'll demonstrate secure token storage, retrieving access tokens for AI access, incremental authorization, and seamless third-party service integration.

The challenge: Building a smart calendar assistant

Imagine you're developing a "Smart Calendar Assistant", an application that helps users manage their schedules intelligently. Here's what your app needs to accomplish:

Basic authentication: Users sign in with their Google account to access the app.
Profile management: Display user's basic profile information.
Calendar integration: Read calendar events to provide schedule insights.
Advanced features: Create calendar events, send meeting invitations via Gmail, and manage Google Drive documents, but only when users explicitly request these premium features.

The challenge? You need different levels of Google API access at different times, and you must store tokens securely for ongoing API operations without constantly prompting users for re-authentication.

Solution: Logto's incremental authorization with Secret Vault

Logto's approach solves this elegantly through:

Minimal initial scopes: Request only essential permissions during sign-in.
Incremental authorization: Request additional scopes on-demand for premium features.
Secure token storage: Store and manage access/refresh tokens in the encrypted Secret Vault.
Automatic token refresh: Handle token expiration transparently.

Let's walk through the implementation.

Step 1: Setting up Google connector with basic scopes

First, create and configure your Google connector in Logto Console. During the initial setup, configure minimal scopes for basic authentication:

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/calendar.readonly
openid

View Google API Library and OAuth 2.0 scopes documentation to find the scopes you need for your application.

Key Configuration Steps:

Create a Google OAuth client in Google Cloud Console. Check all scopes required for your application.
Configure the Logto Google connector with your client credentials. Add the minimal scopes listed above in the Scopes field.
Enable Store tokens for persistent API access in the connector settings.
Set Prompts to include consent and enable Offline Access to ensure refresh tokens are issued.

Read details in the Logto documentation on Google connector setup.

This setup allows users to sign in and grants your app permission to read their calendar events. This is perfect for providing basic schedule insights.

Step 2: Implementing sign-in flow

Navigate to Logto > Sign-in experience > Sign-up and sign-in. Add the Google connector under Social sign-in section to let users authenticate with Google.

When users sign in with Google, Logto automatically:

Authenticates the user with the configured scopes.
Stores the access and refresh tokens securely in the Secret Vault.
Returns user profile information to your application.

// Your app receives the user session after successful Google sign-in
const userSession = await logtoClient.getIdTokenClaims();
console.log(`Welcome ${userSession.name}!`);

The tokens are now securely stored and tied to the user's Google identity, ready for API calls.

Step 3: Accessing Google APIs with stored tokens

To read the user's calendar events, retrieve the stored access token and call the Google Calendar API:

// Retrieve the stored Google access token
const tokenResponse = await fetch('/my-account/identities/google/access-token', {
  headers: {
    Authorization: `Bearer ${userAccessToken}`, // Logto access token
  },
});

const { accessToken } = await tokenResponse.json();

// Call Google Calendar API
const calendarResponse = await fetch(
  'https://www.googleapis.com/calendar/v3/calendars/primary/events',
  {
    headers: {
      Authorization: `Bearer ${accessToken}`,
    },
  }
);

const events = await calendarResponse.json();

Logto handles token refresh automatically. If the access token is expired but a refresh token exists, Logto will obtain a new access token transparently.

Step 4: Incremental authorization for premium features

When users want to access premium features (like creating calendar events or accessing Gmail), use Logto's Social Verification API to request additional scopes:

// Request additional scopes for premium features
const verificationResponse = await fetch('/api/verification/social', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${userAccessToken}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    connectorId: 'google-connector-id',
    redirectUri: 'https://yourapp.com/callback',
    scope: 'https://www.googleapis.com/auth/calendar https://www.googleapis.com/auth/gmail.send',
  }),
});

const { verificationRecordId, authorizationUri } = await verificationResponse.json();

// Redirect user to Google for additional authorization
window.location.href = authorizationUri;

After the user grants additional permissions, complete the verification and update the stored tokens:

// Handle the callback and verify the authorization
await fetch('/api/verification/social/verify', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${userAccessToken}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    verificationRecordId,
    connectorData: {
      /* authorization code from callback */
    },
  }),
});

// Update the stored token set with new scopes
await fetch('/my-account/identities/google/access-token', {
  method: 'PATCH',
  headers: {
    Authorization: `Bearer ${userAccessToken}`,
  },
  body: JSON.stringify({
    socialVerificationId: verificationRecordId,
  }),
});

Now your app can create calendar events and send emails with the updated token that includes the new scopes.

Step 5: Managing token status

Logto Console provides comprehensive token management capabilities. Navigate to User Management > select a user > Social Connections to view:

Token Status: Active, Expired, Inactive, or Not Applicable
Token Metadata: Creation time, last update, expiration, and granted scopes
Connection Management: View profile information synced from Google

This visibility helps administrators understand user connection states and troubleshoot any token-related issues.

Beyond Google: Comprehensive third-party integration

You can extend your Smart Calendar Assistant to integrate with various services beyond Google. Popular social connectors include Google for authentication, calendar, and Gmail integration, GitHub for code repositories and issue management, and Facebook for social features and marketing insights. Additional prebuilt connectors are coming soon to support token storage capabilities.

For custom integrations, Logto provides flexible options through standard OIDC or OAuth 2.0 connection. This comprehensive ecosystem allows you to connect with virtually any third-party service your organization uses.

Security and best practices

Logto's Secret Vault employs enterprise-grade security:

Per-secret encryption: Each token set uses unique Data Encryption Keys (DEK)
Key wrapping: DEKs are encrypted with Key Encryption Keys (KEK)
Minimal exposure: Tokens are decrypted only when needed for API calls
Automatic cleanup: Tokens are deleted when users disconnect accounts or connectors are removed

Conclusion

Logto is a developer-friendly authentication platform that enables secure applications with comprehensive third-party service integration.

With Logto's incremental authorization and secure token storage, your Smart Calendar Assistant delivers seamless user experience balancing functionality with security. Users enjoy frictionless onboarding through single sign-on requesting only minimal permissions for core features. As they explore advanced capabilities, progressive enhancement unlocks premium features through natural, contextual permission requests.

Persistent access via securely stored tokens enables ongoing API operations without constantly interrupting users for re-authentication, creating smooth professional experience. This system is built with security by design, leveraging enterprise-grade encryption to protect user credentials and maintain trust.

Ready to build your own third-party API integration? Here's how to start:

Set up Logto: Create your Logto tenant and configure your first social connector
Enable token storage: Turn on "Store tokens for persistent API access" in your connector settings
Implement incremental Auth: Use the Social Verification API for on-demand scope requests
Build and scale: Expand to additional providers using Logto's comprehensive connector ecosystem

The future of application development lies in seamless service integration. With Logto's Secret Vault and Connectors, you have the tools to build applications that are not just functional, but truly interconnected with the services your users rely on daily.

Want to explore more? Check out our integration guides and start building your next connected application today.

Using Bolt.New and Logto to quickly build your custom login flows

Xiao Yijun — Mon, 18 Aug 2025 12:33:48 +0000

What is Bolt.New

Bolt.new is a browser-based tool for generating and running full-stack web applications instantly. Built on top of StackBlitz’s WebContainer technology, it gives developers a clean, pre-configured stack that includes Next.js (App Router), Tailwind CSS, Supabase, Prisma, and ShadCN UI. The entire environment runs locally in the browser, no installations, no cloud build steps, and no signup required.

Unlike tools that focus on AI-assisted coding inside an existing project, Bolt.new focuses on the beginning of the development process. It removes the overhead of setting up project structure, dependencies, and local servers, letting you go from idea to working prototype in seconds.

How is Bolt.new different from Cursor or Lovable?

While tools like Cursor and Lovable serve as AI copilots inside your code editor, Bolt.new focuses on something else entirely: instant, full-stack project generation and execution.

Cursor enhances VS Code workflows with AI, helping you edit or generate code in your existing environment.
Bolt.new creates a working app from scratch based on a prompt or template, and runs it instantly inside the browser using WebContainers.

There’s no dependency on local tools or remote cloud VMs. Everything runs in-browser with native support for Node.js, package management, and full-stack development. This makes it particularly well-suited for fast prototyping and local-first experimentation, especially in AI or SaaS project contexts.

Who is Bolt.new for?

Bolt.new is designed for developers who often start from scratch such as:

Indie hackers validating product ideas
AI builders testing workflows or embedding models
Founders prototyping MVPs
Engineers creating internal tools or demos

These users are typically comfortable with the modern web stack and prefer tools that are fast, clean, and non-opinionated. Bolt.new is not a visual site builder or tutorial-driven platform. It assumes a working knowledge of React and full-stack development but removes setup friction.

The history and evolution of Bolt.new

Bolt.new was created by the team behind StackBlitz, a company founded in 2017 by Eric Simons and Albert Pai. StackBlitz pioneered WebContainers, a browser-native WebAssembly runtime capable of executing Node.js environments directly inside the browser. This eliminated the need for cloud servers or local installations when developing modern JavaScript applications.

In 2023, StackBlitz faced a turning point. Growth had slowed, and the team explored a more radical direction: combining WebContainers with AI to generate fully functional applications from natural language prompts.

This experiment became Bolt.new, which launched publicly in October 2024. Within weeks, it gained significant traction among developers for its simplicity and speed. The tool combined everything StackBlitz had built over years, runtime isolation, fast dependency installation, and shareable environments, with an AI interface that understood common development goals.

Bolt.new marked a shift in developer tooling: instead of just writing code faster, developers could now start with code that was already running, tailored to their intent.

Guide: Use Logto and Bolt.New to add a custom log-in experience

Register an app in Logto console

In this example, I used Bolt.new to create a CMS app. I skipped the prompt phase and went straight to the point: I asked the agent to build a CMS with Logto as the authentication provider.

According to the instructions, I needed to provide two key pieces of information:

Logto endpoint
App ID

Since the app is a single-page React application, no app secret is needed. The agent handled the rest: it installed the latest Logto React SDK, set up authentication components, and wired everything together.

To complete the setup, I went to the Logto Cloud Console, created a new single-page application, and copied the Logto endpoint and App ID into Bolt.new.

Then configure the Redirect URIs and Post sign-out redirect URIs.

One important detail: because Bolt.new is browser-based and not a local IDE, you can’t use http://localhost:3000/as your redirect URI. Instead, make sure to use the preview URL shown in the Bolt.new browser tab.

Customize Logto pre-built sign in experience

Logto provides a configurable, pre-built sign-in flow that you can customize in the Console. To get started, go to Sign-in Experience > Sign-in & Sign-up, then choose your preferred sign-in methods (such as email, username, phone number, or social login).

Once configured, triggering the sign-in flow will redirect users to Logto’s hosted sign-in page with your selected options. The entire authentication process is handled by Logto, and users are returned to your app after signing in.

This assumes you’ve already set up the Google and GitHub connectors correctly. If not, you can follow the setup guide https://docs.logto.io/connectors

Create a floating login panel above your product

Now I want to go a step further and build a more customized sign-in experience, similar to what Perplexity offers. Instead of redirecting to a separate page, I’ll place a floating login panel directly on top of the product UI. This keeps users in context while still using Logto’s authentication flow underneath.

So I just use this prompt:

The nice part is, when you click Sign In, it goes straight to the sign-in page. If you click Create Account, it opens directly to the account creation screen.

Add social flows

You can provide the agent with Logto’s direct sign-in documentation along with a prompt like “add social sign-in flows.” This allows you to skip the default Logto landing screen. For example, clicking the Google Sign-In button will immediately launch the Google authentication flow, giving users a faster and more friendly login experience.

Logto’s upcoming update will support AI-powered auth integration

This is just a basic example. Logto is currently building MCP servers that run directly inside your IDE, allowing you to interact with the Logto Console and Management API without ever leaving your development environment.

With this setup, you’ll be able to:

Create and manage users
View and filter logs
Configure login and sign-up flows
Define API resources, permissions, and roles
Manage applications and access settings
And more

By combining local tooling with AI and Logto’s infrastructure, authentication is no longer a painful integration step, it becomes part of your natural development flow.

Why AI startups choose Supabase and where it falls short

Xiao Yijun — Mon, 18 Aug 2025 08:00:20 +0000

What is Supabase?

Supabase is an open-source Backend-as-a-Service (BaaS) platform that has become increasingly popular among AI startups and developers building intelligent applications. Often described as the "open-source alternative to Firebase," Supabase combines a PostgreSQL database, real-time subscriptions, authentication, instant APIs, and storage into a unified platform that prioritizes developer experience and rapid deployment.

Built on top of enterprise-grade tools like PostgreSQL, PostgREST, GoTrue, and Realtime, Supabase offers developers the power of SQL databases with the simplicity of modern web development. The platform automatically generates RESTful APIs from your database schema and provides real-time functionality out of the box, making it particularly attractive for AI companies that need to iterate quickly.

Why AI startups are choosing Supabase

Rapid development speed - The primary driver

Just like Supabase’s slogan, Build in a weekendScale to millions. The main attraction of Supabase for AI companies lies in its ability to accelerate development cycles. In the fast-paced AI industry where time-to-market is crucial, startups cannot afford to be slowed down by complex backend setup. Supabase allows AI developers to focus on their core product developenebt and user experience rather than spending weeks configuring databases, authentication systems, and APIs.

One of my friends pointed out that as an entrepreneur, testing and quick pivoting are inevitable — so development speed really matters. Supabase’s quick setup, all-in-one services, and affordable pricing make it a great fit for fast-moving developers.

Cost-effective solution for startups

Compared to self-hosted AWS solutions or enterprise-grade alternatives, Supabase offers compelling pricing that aligns with startup budgets. The generous free tier allows AI companies to prototype and validate their ideas without upfront infrastructure costs, while the transparent pricing structure makes it easy to predict scaling costs as the product grows.

For many AI startups bootstrapping their operations, the cost savings compared to traditional cloud services can be substantial, allowing them to allocate more resources to AI model development and talent acquisition.

PostgreSQL foundation for AI workloads

Supabase's PostgreSQL foundation provides several advantages for AI applications. PostgreSQL's support for JSON data types, advanced indexing, and extensions like pgvector make it suitable for storing embeddings, model outputs, and complex AI-generated data structures. This eliminates the need for multiple specialized databases in many AI use cases.

AI-Era development patterns

An interesting phenomenon in the AI development space is that AI models themselves have been trained on vast amounts of code that uses Supabase, making AI coding assistants particularly effective at generating Supabase-related code. This creates a virtuous cycle where AI developers can leverage AI tools to build on Supabase more efficiently, further accelerating development speed. That’s what it means to build a product the ecosystem wants to adopt.

Where Supabase stands in the Backend-as-a-Service ecosystem

Supabase vs Traditional cloud services

Compared to AWS and other traditional cloud providers, Supabase offers significant advantages in developer experience and setup simplicity. While AWS provides more granular control and enterprise features, the complexity can be overwhelming for small AI teams that need to move fast. Supabase abstracts away much of this complexity while still providing the core functionality most AI applications need.

However, this simplicity comes with trade-offs. Large-scale AI companies often find they need more specialized services as they grow, leading some to eventually migrate to more traditional cloud architectures.

Competition from lightweight alternatives

Supabase competes with other developer-friendly platforms like Fly.io, Railway, and various serverless solutions. Each has its strengths, but Supabase's combination of database, authentication, and real-time features in a single platform gives it an edge for full-stack AI applications.

For vector search specifically, some AI companies choose specialized services like Pinecone or Weaviate instead of relying on Supabase's pgvector extension, especially for applications requiring high-performance similarity search at scale.

Market positioning: SMB vs Enterprise

Supabase has found its sweet spot in the small to medium business market, particularly among startups and indie developers. The platform excels at serving companies that need to build and deploy quickly without the overhead of enterprise infrastructure.

However, as AI companies grow and their requirements become more complex, many find themselves needing more specialized solutions for permissions management, multi-tenancy, or compliance requirements that enterprise-focused alternatives handle better out of the box.

What is Supabase pricing structure

Free Tier - Perfect for AI prototyping

Great for prototypes, testing, and small projects.

Unlimited API requests
Up to 50,000 monthly active users (MAUs)
500 MB database size
Shared CPU and 500 MB RAM
5 GB bandwidth
1 GB file storage
Community support
Projects are paused after 1 week of inactivity
Limit of 2 active projects

This lets AI teams build and test their MVPs without worrying about infrastructure costs, important for validating product-market fit. Many AI coding agents support Supabase integration. For example, you can design both the front-end and back-end in Lovable, and use Supabase as your database.

Pro Plan (From $25 / month)

Most popular — for production-ready apps with room to scale.

Includes $10 in compute credits
Everything in the Free Plan, plus:
- 100,000 MAUs included, then $0.00325 per extra MAU
- 8 GB database (then $0.125 per GB)
- 250 GB bandwidth (then $0.09 per GB)
- 100 GB file storage (then $0.021 per GB)
- Email support
- Daily backups (stored for 7 days)
- Log retention (7 days)

Team Plan (From $599 / month)

For teams needing SSO, backup controls, and compliance.

Everything in the Pro Plan, plus:
- SOC2 compliance
- Project-scoped and read-only access
- HIPAA support (as a paid add-on)
- SSO for Supabase Dashboard
- Priority email support and SLAs
- Daily backups (stored for 14 days)
- Log retention (28 days)

Enterprise (Custom pricing)

For large-scale, high-demand applications.

Dedicated support manager
Uptime SLAs
Bring Your Own Cloud (BYO Cloud)
24×7×365 premium enterprise support
Private Slack channel
Support for custom security questionnaires

Supabase authentication capabilities for AI products

Core authentication methods

Supabase provides authentication suitable for AI applications handling user data and personalized experiences:

Email and password authentication

Secure user registration and login
Email passwordless authentication workflows important for AI applications
Password reset functionality
Customizable email templates for branded experiences

Social OAuth providers

Google, GitHub, Discord, Facebook integration
Apple, Twitter, LinkedIn, and more
One-click social login implementation
Automatic user profile synchronization for personalized AI experiences

Magic Link authentication

Passwordless login via email
Enhanced user experience for AI tools
Reduced security risks
Perfect for AI applications requiring quick access

Advanced security features

Row Level Security (RLS)
Critical for AI applications, Supabase's RLS policies ensure users only access their own data, conversations, and AI-generated content. These policies operate at the database level, providing robust isolation between users' AI interactions and personal data.

JWT token management
Automatic JWT token generation and validation with customizable expiration times. AI applications can securely authenticate API calls to external AI services while maintaining user context throughout complex AI workflows.

Multi-factor authentication (MFA)
Built-in support for TOTP-based MFA adds security for AI applications handling sensitive data or providing access to premium AI models.

Supabase's limitations and considerations

While Supabase is a powerful and developer-friendly backend platform, offering database, storage, authentication, and serverless functions out of the box but it has notable limitations when it comes to enterprise-grade identity and authorization.

No OIDC provider support

Supabase does not support acting as an OpenID Connect (OIDC) Provider. This means:

You cannot use Supabase to federate identity to other systems, i.e. it cannot serve as a central identity provider for other applications.
Supabase cannot issue standards-compliant ID tokens for third-party clients to consume.
It lacks support for custom claims, token introspection, scoped access, or fine-grained session/token management, all of which are essential for OAuth 2.1 / OIDC-compliant systems.

One of Logto customers complains:

In contrast, platforms like Logto, Auth0, or Keycloak can act as a fully compliant OIDC Provider, supporting complex login workflows, SSO federation, and secure token issuance, critical for multi-system identity architectures.

Especially in the AI era, if you want your product to work with AI agents or act as an MCP server, it needs to support OAuth or OIDC. Without this, your product can’t participate in the OAuth-based ecosystem that AI agents rely on, which means missing out on major integration opportunities.

Weak authorization model (RBAC/ABAC)

Supabase also lacks a built-in authorization framework:

There is no native RBAC (role-based access control) system for assigning roles to users or defining permissions.
You must manually implement authorization logic using PostgreSQL Row-Level Security (RLS): a powerful but low-level feature that’s difficult to manage as your product scales.
There is no organization/team hierarchy, no user-role mapping UI, and no ability to apply conditional access policies based on roles, tenant ownership, or permissions.
There’s no concept of access scopes or policies bound to tokens, making it hard to integrate with secure APIs or microservices.

This makes Supabase less suitable for multi-tenant SaaS products, B2B platforms, or anything requiring enterprise-grade access control.

Workarounds and common practices

Because of these limitations, many teams use Supabase together with a dedicated identity provider such as:

Logto – An open-source auth solution with full OIDC Provider support, RBAC, organization management, and multi-tenant auth
Auth0 / Okta – Commercial identity platforms with extensive protocol and security support
Clerk / Descope – Developer-first auth tools with more visual control over identity flows

These systems handle user authentication, SSO, and authorization logic, while Supabase continues to provide data storage, edge functions, and real-time APIs.

Summary: Where Supabase falls short

Capability	Supabase Status	Limitation
OIDC Provider	❌ Not supported	Cannot expose user pool to third-party apps
Token Customization	❌ Minimal	No custom claims, scopes, or introspection
RBAC	❌ Manual via RLS	No native roles/permissions system
Org/Tenant Hierarchy	❌ Not supported	No built-in support for orgs, teams, or role mapping
Visual Policy Management	❌ Missing	Must manage all logic via SQL/RLS manually

In short, Supabase excels at providing a developer-first backend experience, but when it comes to secure identity, SSO, and advanced authorization, it lacks the primitives and abstractions that modern applications demand. If your product involves multi-tenant auth, enterprise SSO, or fine-grained access control, pairing Supabase with a purpose, built identity solution is not just recommended.

Migration path for growing companies

Many AI companies view Supabase as an excellent starting point but plan eventual migration to more specialized services as they scale. This "graduate and migrate" pattern is common, where startups begin with Supabase for speed, then move to enterprise solutions for advanced features.

Future outlook and recommendations regarding Supabase

Ideal use cases for AI startups

Supabase is particularly well-suited for:

AI MVP development: Rapid prototyping and validation
Small to medium-scale AI applications: Up to thousands of users
Developer tools and AI-assisted applications: Where development speed is crucial
Consumer AI applications: Simple user management and data storage needs

When to consider alternatives

AI companies should evaluate alternatives when:

Complex multi-tenancy requirements: Enterprise B2B products with sophisticated permission models
High-scale vector operations: Applications requiring specialized vector database performance
Strict compliance requirements: Industries with specific regulatory needs
Complex integration needs: Applications requiring deep integration with enterprise systems

Strategic recommendations

For AI startups considering Supabase:

Start with Supabase for rapid development and validation
Plan for potential migration as you scale and requirements become more complex
Evaluate permission requirements early to understand if custom development will be needed
Consider hybrid approaches using Supabase for core functionality while integrating specialized services for specific needs

Build AI-Ready applications with Supabase’s backend stack and Logto’s auth system

Supabase has become a go-to for a lot of AI startups, mostly because it helps you move fast when speed matters. It’s probably not where you’ll scale forever, but it’s a solid launchpad that gets the job done—especially when you want to focus on your core AI work, not backend plumbing.

The dev experience is smooth, pricing is reasonable, and the feature set covers most of what you need early on. Just make sure you know where it might hit limits, and have a plan for how you’ll evolve as your needs change.

If your goal is to get from idea to working product as quickly and cost-effectively as possible, Supabase is honestly one of the best ways to do it.

That said, when it comes to auth, especially if you’re building for AI agents or planning to support OAuth/OIDC flows, you’ll want something more purpose-built. That’s where Logto comes in.

It’s open-source, developer-friendly, and designed from the ground up to support modern identity use cases, including AI agent auth and MCP-style infrastructure. If you’re already on Supabase, plugging in Logto gives you a full-featured identity layer without having to build it all yourself.

We’ve put together a simple Logto + Supabase integration guide that walks you through the setup, so you can get sign-up, login, and session management running in minutes.

Top coding agents in 2025: Tools that actually help you build

Xiao Yijun — Mon, 18 Aug 2025 08:00:04 +0000

The software development world is flooded with "AI agents" in 2025. Most promise to write your code, finish your tasks, and ship your app while you sleep. The reality? Some are noise. A few are signal.

But a handful of tools actually deliver real leverage. They fit into your workflow, take things off your plate, and help you build faster, especially when you're short on time or context switching too much. These aren't just copilots or chatbots. They're hands-on agents that help you move from vague ideas to working software.

What makes a good coding agent

Good coding agents don't just autocomplete. They understand context, work across files, and integrate into how you actually build software. The best ones feel like pairing with someone who knows your stack, not fighting with a glorified autocomplete tool.

The tools that work fit into how developers actually build:

They understand your whole project, not just the current file
They can make real changes, not just suggestions
They stay out of your way when you're in flow
They handle the boring stuff so you can focus on the interesting problems

In the following list, I’ll use build a photo gallery app as a prompt to evaluate the output.

1. Cursor - The power tool for developers who live in their editor

Website: cursor.sh

Cursor is a fork of VS Code with AI built in, but not just as a side panel. It can read your whole codebase, navigate across files, and actually change code in ways that feel useful. It's what Copilot could've been if it understood your repo instead of just guessing line-by-line.

Here are a few screenshots showing how Cursor responded when I asked it to build a photo gallery app.

Core features of Cursor

Smart code completion: AI-driven code generation and completion system
Natural language interaction: Intelligent dialogue assistant that understands natural language and provides programming assistance
Code refactoring and optimization: Advanced features for code refactoring, understanding, and optimization

How Cursor differs from traditional IDEs

Cursor is a VS Code compiler integrated with multiple models, not a plugin used within an IDE. It provides more comprehensive contextual understanding, not only performing code completion but also specifically fixing error code and restructuring code architecture.

Pricing and access

Cursor offers flexible pricing plans, including free access with core features and premium tiers that unlock access to the latest Claude models and more advanced capabilities.

What is Cursor best for

Developers seeking a smarter IDE experience
Engineers focused on clean, maintainable code
Builders who want AI help without giving up control

In our previous blog post, we shared a step-by-step tutorial on vibe coding with Cursor, showing how to build a simple app with authentication.

https://blog.logto.io/cursor-logto-auth

2. GitHub Copilot Workspace - Issue → Plan → PR

Website: github.com/features/copilot

GitHub Copilot is another AI agent inside your IDE. Its autocomplete feature was just the beginning — the real game-changer is Copilot Workspace.

The biggest advantage? Copilot is deeply integrated into the GitHub ecosystem. If your team relies heavily on GitHub for planning and maintaining code, Copilot is a solid starting point.

The platform now features an advanced coding agent mode that can make sweeping changes across multiple files by analyzing code, proposing edits, running tests, and validating results.

When GitHub copilot starts to make sense

You're juggling multiple features and don't want to context switch
You want to delegate a "known shape" of work (CRUD, tests, tweaks)
You've got a clear task but don't want to handhold it
Teams already using GitHub ecosystem

GitHub Copilot key features

Multi-model support including Claude 3.5 Sonnet and Google Gemini 2.0 Flash
Agent mode for complex, multi-file operations
Seamless integration with popular IDEs
Real-time code suggestions and completions
Pricing: Starting at $10/month for individual developers

3. Bolt - Multi-agent software building, from the browser

Website: bolt.new

Bolt feels like what would happen if you mashed together Figma, GPT, and a backend generator. You describe what you want: a form, a dashboard, a flow, and behind the scenes, multiple agents handle the pieces: UI, logic, backend, state.

What makes Bolt.new stand out

Fast iterations, even for non-developers
Agents work in parallel to co-build components
In-browser canvas makes it feel less like code, more like building
No setup required, works directly in your browser

What is Bolt.new best for

Early MVPs, internal tools, or when you want to skip boilerplate and focus on core logic. Even if you’re not a developer, you can still build a polished, professional product. In contrast, Cursor offers more advanced configuration options suited for developers who want fine-grained control.

4. Lovable - Natural Language → Full-Stack App

Website: lovable.so

Lovable is simple: describe what you're building, and it gives you a working app: frontend, backend, database, login flow, the works. It's especially useful when you know what you want but don't want to scaffold everything from scratch.

What is Lovable useful for

Indie hackers
Product people building internal tools
MVPs and demos
Getting a working base fast

Lovable is not meant for tweaking every edge case but it gets you a working foundation fast, which is often all you need. Lovable is similar to Bolt.new, but even simpler and more opinionated. It’s tightly integrated with its ecosystem and tools like Supabase. It’s not built for developers who need full control, but rather for indie hackers who want to quickly bring their ideas to life.

In our previous blog post, we shared a step-by-step tutorial on vibe coding with Lovable, showing how to build a simple app with authentication.

https://blog.logto.io/lovable-logto-auth

5. Anthropic's Claude Code - Command line power

Anthropic's Claude Code represents a new approach to coding assistance. As an agentic command line tool, it allows developers to delegate entire coding tasks directly from their terminal, making it particularly powerful for complex development workflows.

Claude Code key features

Command-line interface for seamless workflow integration
Claude Sonnet 4 powering advanced reasoning capabilities
Autonomous task completion
Integration with development pipelines

What Claude is best for

Advanced developers who prefer command-line workflows and need autonomous coding assistance

6. Replit - Quick scripts, simple logic, in the browser

Website: replit.com

Replit’s biggest moat is that it didn’t start as an AI product — it began as a full-featured Cloud IDE that combines editor, terminal, and deployment into one environment.

Open your browser and start coding, running services, using a terminal, or deploying apps
Ideal for teaching, quick prototyping, and running small projects
Supports real-time collaboration and live preview
Extremely beginner-friendly

How Replit got Compared to Bolt Lovable

Replit builds from the ground up as a developer tool : AI is an enhancement, not the core.

Bolt and Lovable start with “natural language to code” as the default. They assume you’re not a traditional developer and may not even want an IDE at all.

What Replit does best

Short tasks, simple ideas
Educational content, walkthroughs
Live collaboration with AI in the loop
Cloud-based development environment
Instant deployment capabilities

What is Replit best for

Beginners, educators, and developers who prefer cloud-based development environments

7. Windsurf - The collaborative alternative

Windsurf, formerly known as Codeium, has evolved into a full-featured AI coding platform that now competes directly with Cursor and GitHub Copilot.

What sets it apart is its focus on the chat-based, agentic experience. While Cursor is still centered around the IDE, Windsurf leans more into conversational interactions, making AI feel more like a coding partner than just a tool.

Windsurf key features

Multi-model AI support
Real-time collaboration features
Extensive language support
Custom model training capabilities
A browser experience controlled by the Windsurf AI agent

Windsurf vs Cursor

Whenever people talk about AI-powered IDEs, Windsurf and Cursor are always part of the conversation. So in this section, I’ll do a detailed comparison between the two.

Category	Cursor	Windsurf
User Experience & Interface Design	Cursor IDE focuses on speed and precision, with fast completions and a Composer mode that turns plain English into code. It’s a more established platform with refined workflows.	Windsurf generally has a cleaner and more polished UI compared to Cursor. It feels like comparing an Apple product to a Microsoft one — those little details make Windsurf feel more refined and intuitive.
Core AI Technology	Cursor provides a flexible approach with multiple interaction modes, offering both direct assistance and task execution via Agent mode or the Composer feature.	Windsurf's Cascade is an AI IDE agent that automatically fills context, runs commands, and remembers user-specific details across sessions. Powered by Codium, it feels like a reliable and intelligent coding partner.
Context Understanding & Code Intelligence	Cursor can lose context after several prompts and sometimes hallucinates. Its rigid structure may limit creative or unconventional coding workflows.	Windsurf often gets things right on the first try, recognizing and using project-specific components accurately. It demonstrates stronger contextual understanding and code intelligence.
Workflow Philosophy	Cursor follows an assistance-first approach. It handles ambiguous prompts well and offers developers more control, making it ideal for those who prefer hands-on involvement.	Windsurf embraces an agent-first philosophy. It takes initiative in handling complex tasks, making it better suited for developers who prefer a more autonomous AI partner.

Which should you choose?

Choose Windsurf if you:

Value clean, refined UI/UX
Want an AI that proactively understands your codebase
Prefer an agent-style approach to coding
Need better context retention across conversations
Want more autonomous AI assistance

Choose Cursor if you:

Need faster code completions and immediate responses
Prefer more control over AI interactions
Work well with ambiguous prompts
Want a more established platform with proven workflows
Are comfortable with a steeper learning curve

The real talk on AI coding tools

Most "AI dev tools" are either too shallow (autocomplete with hype) or too heavy (agents with zero context). The ones that work fit into how you actually build:

Choose based on your workflow:

Cursor if you want a smarter IDE
GitHub Copilot Workspace if you run your life through GitHub
Bolt if you want to orchestrate multiple agents to build features
Lovable if you want a full app without setting up a repo
Replit if you're building in the browser

How to choose the right tool

The best coding agent depends on your specific needs:

For individual developers:

Cursor for deep IDE integration
Lovable for rapid prototyping
Bolt for browser-based development
Claude Code for command-line workflows

For teams:

GitHub Copilot Workspace for GitHub-centric workflows
Windsurf for collaborative features

Best practices for using coding agents

Start with your workflow: Pick tools that fit how you already work, not tools that force you to change everything.

Don't trust blindly: These tools are powerful, but they're not perfect. Always review generated code for accuracy and security.

Use them for leverage: The best coding agents handle the boring stuff so you can focus on the interesting problems.

Stay in control: You're still the developer. These tools should amplify your abilities, not replace your judgment.

The future of coding agents

As we move through 2025, coding agents are becoming more sophisticated and integrated into development workflows. The trend is toward:

Better context understanding across entire projects
More autonomous task completion with less handholding
Specialized agents for specific domains and use cases
Improved collaboration between human developers and AI agents

Conclusion

These aren't toys. They're a new layer in the stack, not replacing developers, but changing the rhythm of how we ship software. The best coding agents in 2025 understand that developers don't need another chatbot. They need tools that actually help them build.

The key is finding the ones that fit your workflow, solve real problems, and stay out of your way when you're in flow. Whether you're building MVPs, managing complex codebases, or just trying to ship faster, there's likely a coding agent that can help you get there.

The future of software development is collaborative, with AI agents serving as intelligent partners that amplify human creativity and problem-solving capabilities. Choose the right tools, use them wisely, and focus on what you do best: solving problems and building software that matters.

After exploring how Cursor, GitHub Copilot, and Windsurf shape the future of coding with AI, one thing is clear: the ecosystem is moving toward more conversational, agent-driven development.

If you’re building modern apps and need authentication done right, Logto fits right into that workflow. It offers seamless auth, user management, and permission controls: all developer-friendly and easy to integrate with any of these AI-powered coding environments.

Less time on auth. More time shipping.