DEV Community: Logto

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.

CAPTCHA provider buyer’s guide 2025

Xiao Yijun — Wed, 13 Aug 2025 03:16:29 +0000

What is CAPTCHA?

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response system used to distinguish human users from automated program or bots. It presents tasks that are easy for humans but hard for machines.

For example, a traditional CAPTCHA might show distorted letters or numbers and ask the user to type them. By leveraging human pattern recognition, CAPTCHAs block most scripts and spam bots from abusing online forms and services.

How does CAPTCHA work?

Classic CAPTCHAs rely on tasks like interpreting distorted text or selecting specific images. The distortion (e.g. warped letters overlaid with noise) foils simple OCR (Optical Character Recognition) algorithms.

Modern CAPTCHA solutions have evolved into several categories:

Interactive CAPTCHA: The user must actively solve a puzzle or perform a specific operation. Examples include “I’m not a robot” checkbox challenges. After clicking the checkbox, it may then prompt the user to select all images with a traffic light or storefront, typing shown characters, or even audio tests. Notably, with Cloudflare Turnstile, a simple checkbox click is enough to verify whether this action is human, without any complicated challenges.
Non-interactive CAPTCHA: These do not interrupt the user with a puzzle or operation. FFor example, with Cloudflare Turnstile’s non-interactive mode, visitors simply see a small widget with an automatic loading bar. It runs a background check and then quietly returns a success or failure result. This approach prioritizes user experience.
Invisible or passive CAPTCHA: These work entirely in the background, without any visible test. For example, Google reCAPTCHA v3 invisibly analyzes user behavior (mouse movements, timing, cookies, etc.) to assign a risk score (0–1) without a direct challenge. Users rarely see anything unless the score is too low.

Should we add CAPTCHA protection into the product?

Using CAPTCHA is a trade-off between security and user experience. When selecting a CAPTCHA service, key considerations include:

Can AI bypass CAPTCHA challenge?

CAPTCHAs are effective against basic bots, but determined attackers have countermeasures. Advanced scripts or AI-driven bots can sometimes bypass CAPTCHAs using OCR/image recognition and machine learning. There are even anti-CAPTCHA or solver services (often called bypass-as-a-service) where attackers pay humans or specialized AI to solve CAPTCHAs at scale. For example, Google once reported that older text CAPTCHAs could be solved by bots over 99% of the time.

However, modern non-interactive and invisible CAPTCHAs, like behavior-based or cryptographic background checks, offer better defense to AI attack. Notably, bot traffic is now enormous: On the order of 51% of all internet traffic, with 37% being malicious. So having some CAPTCHA or bot-detection is important even if it is not foolproof.

Besides, adding multi-layered bot protection is necessary, such as device fingerprinting (e.g., via passkeys), rate limiting, Multi-Factor Authentication.

Does adding CAPTCHA hurt the user experience?

Any CAPTCHA adds friction for users. Studies show only about 66% of humans enter a CAPTCHA correctly on the first try, meaning many may get frustrated or abandon a form. For example, lengthy image puzzles or multiple re-attempts can lower conversion rates.

To mitigate this, modern CAPTCHA providers focus on minimizing human effort. Strategies include:

Only adaptive-challenging users flagged as high-risk.
Using non-obtrusive signals (mouse movements, timing, and more) instead of puzzles.
Offering invisible CAPTCHAs that run quietly.

Cloudflare reports that Turnstile “eliminate the frustrating experience of CAPTCHAs” so real users “no longer have to waste time and effort solving visual puzzles”. In practice, many sites only show a checkbox or image challenge when a user’s behavior looks suspicious; normal users may see nothing at all.

Does CAPTCHA block AI agent access third-party services?

Today, more and more AI agents are emerging, designed to automate tasks and interact with third-party services.

Many domain-specific AI agents connect safely and legitimately to third-party apps using standard protocols like OAuth and MCP (Model Context Protocols). This is a secure, approved way to grant an agent access which make users to authorize smoothly.

However, some ambitious “general-purpose” AI agents aim to fully replace human browsing actions. For example, Manus is designed to automate everything a person might do in a web browser, from filling in forms to signing in with a username and password. In real-world tests, Manus struggle to get past modern high-security CAPTCHAs such as Cloudflare Turnstile and Google reCAPTCHA Enterprise, even if the user tries to “hand off” the session to a real person to solve the challenge manually. If you’re building an AI agent, it’s important to design your authentication flows carefully. Relying on browser automation to log in like a human is increasingly impractical because strong CAPTCHAs are extremely good at blocking bot-like interactions.

How much does adding CAPTCHA increase budgets?

CAPTCHA services range from free to paid. Free plans often limit usage or have basic features. For example:

Cloudflare Turnstile is free with unlimited usage.
Google’s reCAPTCHA Essentials tier is free for up to 10,000 assessments per month; higher-volume or advanced features require upgrading to Standard or Enterprise.
hCaptcha offer a free “Basic” tier and charge for Pro/Enterprise (e.g. hCaptcha’s Pro plan starts around $99–$139 per month for 100K requests).

Be sure to check each provider’s plan limits and pricing for your expected traffic and conversion goals.

Usage scenarios of CAPTCHA

CAPTCHAs are typically deployed wherever bots can cause trouble. Common scenarios include:

Authentication flows: Protecting registration, sign-in, and password recovery flows from bot abuse. CAPTCHA serves as the first line of defense against scripted account attacks. Beyond that, features like sign-in lockout (to stop brute-force password attempts) and adaptive MFA (to add extra layers of verification when risk is detected) can further strengthen security while keeping the experience smooth.
Form submissions: Guarding public forms (e.g., contact us, feedback, comments, reviews). Without CAPTCHA, spammers can flood comment sections or message boards.
High-value actions: Preventing fraud in online polls, ticket sales, promotions, or e-commerce checkouts. CAPTCHAs can limit bulk automated voting or scalping (e.g. one vote per person in a poll, one ticket per person).

By inserting CAPTCHAs at these touchpoints, you significantly reduce automated abuse while keeping the system open to legitimate users.

Compare CAPTCHA providers

CAPTCHA provider	User experience	Plan & pricing
reCAPTCHA v2 (Google)	Users must click a ”I'm not a robot“ checkbox. This click might or might not challenge them with CAPTCHA image puzzles.	Free (Essentials) for up to 10K assessments/mo; then paid tiers (Standard/Enterprise). Enterprise costs $8 up to 100K and $1 per additional 1K.
reCAPTCHA v3 (Google)	Invisible, background risk scoring (no user challenge).	Same pricing tiers as reCAPTCHA v2
reCAPTCHA Enterprise (Google)	Two interactive modes: 1. Score-based (no challenge). 2. Checkbox and adaptive visual challenge.	Volume-based pricing: free up to 10K; $8 up to 100K; $1/1K beyond. Offers extra features like account defender and SMS fraud protection.
Cloudflare Turnstile	Three interactive modes: 1.Managed: Cloudflare logic determines which users see checkbox widget. 2. Non-interactive: All user see auto-loading widget, but never interact with the widget. 3. Invisible: Visitors will never see or interact with the widget. Invisible challenges should take a few second.	Almost completely free. Free plan: Up to 20 CAPTCHA widgets, 15 hostnames per widget, unlimited volume. Enterprise plan: Unlimited widgets.
hCaptcha	Interactive image classification tasks (similar to reCAPTCHA v2). Focuses on privacy, but puzzles can be complex.	Free up to 100k requests per month. Pro plan ~$99/mo. Enterprise custom plans.
FunCaptcha (Arkose Labs)	Gamified micro-games (rotate/slide objects, simple quizzes). More engaging puzzles intended to defeat bots.	No free tier. Only provide Enterprise solution (part of Arkose Bot Management) and contact for pricing.
Friendly Captcha	Fully invisible proof-of-work puzzle. No user action needed with all solved in the background.	Free non-commercial tier (1 domain, 1000 requests). Paid plans: Starter €9/mo (1K req); Growth €39/mo (5K req); Advanced €200/mo (50K req); Enterprise custom.
BotDetect (Captcha.com)	Traditional image or audio CAPTCHA with letters/numbers.	Self-hosted and License-based. No free plan. APT license fee about $99/year.

Among these, Cloudflare Turnstile stands out today. It’s free, easy to integrate, and unobtrusive. Turnstile delivers robust bot blocking without forcing puzzles on legitimate users, and it “never harvests data for ad retargeting”, fully respecting user privacy. For most sites, Turnstile offers the best balance of security, UX, and cost.

Simplify CAPTCHA integration in your sign-in flows

The easiest way to add CAPTCHA is to use an integrated identity platform.

Logto, a developer-friendly IAM solution, supports top providers like Google reCAPTCHA Enterprise and Cloudflare Turnstile, so you can enable CAPTCHA in just a few clicks.

With Logto, your team can secure your entire authentication flows without dealing with complex implementation work, including sign-up, sign-in, account recovery, SSO, MFA, multi-tenant management, etc. Learn more about Logto’s CAPTCHA or reach out to the team if you’d like explore more CAPTCHA provider options.