DEV Community: Descope

Best MCP Server Directories for Developers

Mrunank Pawar — Wed, 27 May 2026 21:31:45 +0000

This blog was originally published on Descope.

The Model Context Protocol (MCP) has quickly established itself as an open standard that easily connects AI applications to external data sources and tools. It acts as a universal interface that allows language models to access databases, APIs, or file systems in a standardized way. No custom integrations required. However, with thousands of MCP servers now available on dozens of MCP directories, it's hard for developers to find the right MCP server.

To help you choose, this article compares several MCP directories based on six practical criteria: how easy it is to find the right server, how carefully the entries are compiled and documented, how up-to-date and maintained the catalog is, what security and trust signals are available, how smoothly installation and configuration go, and how active the community is.

In our testing approach, we'll simulate realistic developer workflows that begin with identifying a need, continue with assessing the trustworthiness of a server, and culminate in the actual installation and execution in a standard MCP client.

The MCP registries

Several directories have established themselves within the MCP ecosystem, each with a different focus. The most notable are:

GitHub MCP Registry: The focus of this directory is on standardization and authority, not quantitative breadth. It serves as a reference implementation for the entire ecosystem. The registry ensures adherence to metadata standards, but only includes a selective list of official servers (around 65 directories as of January 2026) and offers little insight into the maturity of third-party tools.

Glama: Glama positions itself as a curated seal of approval for MCP servers. A team uses automated scans and manual reviews to ensure that projects have READMEs, valid licenses, and no known vulnerabilities. These stringent inclusion criteria make the catalog significantly more focused on quality than sheer quantity.

PulseMCP: PulseMCP focuses on discoverability and popularity signals. It aggregates several thousand servers and marks entries as "official" or "community." Popularity metrics, such as estimated visitor numbers and rankings, make it a good choice for browsing and prototyping.

MCP Market: MCP Market is operated by a private provider and positions itself as a comprehensive marketplace with the largest number of listed servers. It ranks servers by popularity and recency and categorizes them into topics like "API development".

Discoverability and finding the right server

To assess how well the various directories are suited for searching, we searched for an MCP server that allows access to a PostgreSQL database. On each platform, we entered the same search term and then examined how quickly a suitable solution could be found, what filtering options were available, and how detailed the respective descriptions were.

GitHub MCP Registry

The GitHub MCP Registry currently lists 87 servers as of March 2026 with a basic search bar, but no categories or filters. For instance, searching for "PostgreSQL" returns a single result: DBHub, a database server supporting PostgreSQL, MySQL, SQL Server, SQLite, and MariaDB. Each listing includes an install button, a short description, the provider, and the repository's GitHub star count.

This directory is useful if you know what you are looking for, and offers limited discoverability.

Glama

Glama offers a search field above the server list and enables an advanced search with a single click on "DeepSearch." For instance, entering "PostgreSQL" returns matching MCP tools (for example, pg_debug_database) and actual MCP servers, and selecting one opens a dedicated details page:

PulseMCP

PulseMCP has a central search field with auto-complete and directly displays how many servers are found for the search term. For example, searching for "PostgreSQL", it lists 100+ results, with the first entry being an Anthropic's reference server, in addition to many other community maintained servers.

It is well-suited for broad discovery with popularity signals to guide shortlisting.

MCP Market

MCP Market is geared towards discovery through presentation and categorization. This makes the platform attractive to developers who want to see practical applications alongside functionality while browsing. For example, when we searched "PostgreSQL," multiple server maps were displayed, each with a star rating and a brief description. Clicking on a map opens a detailed page with tabs for "About," "README," and "FAQ."

MCP Market works best when you're trying to figure out which server variant actually fits what you're doing.

Comparison

Feature	Github MCP Registry	Glama	PulseMCP	MCP Market
Search	Basic search, no filters	DeepSearch, category filters	Auto-complete, classification filters, popularity sorting	Use case categories, star ratings
PostgreSQL results	1 server	2 server & tools	100+ servers	2+ with use cases listed.
Detail page	Install button, description, provider, Github stars	Dedicated page with tool and server separation	Provider, visitor metrics, release date and server.json	About, Readme file, FAQ tabs, implementation guides
Key strength	Official reference	Advanced search	Community servers and ranking signals	Rich contextual details about the server

PulseMCP offers the strongest discovery experience here. It provides over a hundred results for PostgreSQL with popularity sorting and classification filters to give you a quick path from search to install. MCP Market is a solid runner-up: useful contextual details, but only once you're on a page. The other two are limited unless you already know what you're looking for.

Quality standards: curation vs. comprehensiveness

How a directory vets its servers matters as much as what it lists. Our goal is to assess the server's maturity, as well as its documentation, auditing, and user feedback while searching for "GitHub MCP server" on the presented platforms.

GitHub MCP Registry

The GitHub MCP registry performs basic validation for server.json, limited to format and namespace uniqueness, but doesn't evaluate documentation quality or run tests. Users can share feedback by opening GitHub issues against the server's GitHub repository, but the feedback isn't directly visible on the server details page. For example, when you search for "GitHub MCP Server", the details page essentially renders the Readme.md file of the corresponding server repository.

The registry positions itself as an "app store for MCP servers" for clients and deliberately leaves quality assessment to other levels.

Glama

Glama is significantly more curation-oriented than other directories in this test and attempts to answer the question "Is this server mature enough for deployment?" directly within the directory. For example, the GitHub MCP server receives a scorecard with separate ratings for security, license, and quality, including statements such as "no known vulnerabilities" and "Author verified." Its includes criteria in the scores, such as known vulnerabilities, license verification, operability, tool scope, and up-to-dateness.

PulseMCP

PulseMCP shows the provider, official classification, number of visitors, and release date at a glance. For example, with a GitHub MCP server, you immediately notice the provider as GitHub and classification as Official reassuring users about the server's reliability. PulseMCP also explicitly refers to the server.json file for servers as a "standardized, official file format" and positions it as the source for installation, configuration, and usage guidelines.

The platform is particularly suitable for developers who want a wide selection but can quickly create a pre-selection based on "official and frequently used" options.

MCP Market

MCP Market focuses on explaining the fit, helping users quickly decide whether it's worth taking a look at the repository. Consequently, documentation requirements and audit procedures are less prominently displayed. Testing or validation in the sense of "guaranteed to work" is not communicated as a core feature. User feedback is conveyed more through marketplace mechanics like rankings and related recommendations than through a comprehensive review system.

MCP Market primarily caters to the preference for breadth and comfortable browsing.

Comparison

Feature	Github MCP Registry	Glama	PulseMCP	MCP Market
Curation approach	Format validation only	Comprehensive scorecard	Classification & popularity	Marketplace rankings
Documentation requirements	None (only format compliance)	Readme needed	server.json and repository link	None
Quality and user feedback	Github issues	Quality indicators, issue reporting	Shows visitor metrics, but no direct feedback	Rankings

Glama is the only directory that appears to be taking a hands-on approach to curation. Scorecards, vulnerability checks, and license verification mean you can actually evaluate production readiness without leaving the platform to research yourself. Every other contender puts the quality eval on you.

Security and verification: GitHub server test case

Because MCP servers allow deep access to production systems, you need to choose a trusted directory. Platforms differ significantly in how they inspect code, authenticate maintainers, and flag vulnerabilities. Developers should understand the security features offered and where they need to perform their own checks.

GitHub MCP Registry

The official registry provides metadata but no security assessments. It checks whether the server.json file conforms to the schema and the namespace is unique. If users discover abuse or suspicious servers, they can report them via a GitHub issue. Maintainers can then add entries to a deny list. Beyond that, there are no code reviews, vulnerability scans, or verified maintainer badges.

The registry explicitly described itself as a "metaregistry" that delegates security and compliance to underlying package registries and downstream systems. For organizations, the registry recommends setting up private sub-registries with their own security policies.

Glama

Glama performs the most comprehensive check of MCP servers and displays the results as a scorecard. For instance, for the search of the GitHub MCP server, three categories are evaluated: security, licensing, and quality. The platform reported no known vulnerabilities and confirmed that the server functions as expected.

Glama also shows whether a server is inspectable, when it was last updated, and whether a README and license are available. Maintainers can verify their projects via a GitHub login. Until they do so, the message "Author not verified" appears.

PulseMCP

PulseMCP prioritizes openness and popularity signals. The GitHub MCP server is marked as "official" and the listing clearly identifies the provider (GitHub) and the responsible maintainer as GitHub. Visitor numbers and a popularity ranking serve as trust indicators, but there are no automated code or vulnerability checks.

The platform links to the server.json file, which contains installation and configuration instructions, and displays details such as authentication type (OAuth) and transport protocol (Streamable HTTP). Red flags, such as missing maintainer information or severely outdated servers, are not explicitly highlighted. Therefore, users must consult the GitHub repository and other sources themselves for a security assessment.

MCP Market

MCP Market is primarily aimed at developers who want to browse by use case, for example developer tools, API development, and workflow-oriented categories like browser automation, web scraping, and web app testing. The GitHub MCP server is tagged with categories, a short description, and GitHub stars. However, the directory provides no security checks or dependency information, and maintainer verifications are missing.

In addition, multiple entries with similar names can coexist, which can be confusing without additional checks. Security-relevant information, such as CVE scans (checks against the Common Vulnerabilities and Exposures database for known security issues), dependency lists, or "Report Issue" links, is not included in the listing. Developers must therefore rely on the linked repository and external security tools.

Feature	GitHub MCP Registry	Glama	PulseMCP	MCP Market
Vulnerability check	None	Automated, with scorecard	None	None
Verification	None	GitHub login verification	None	None
Trust signals	GitHub stars only	Security / license / quality scores	Official/community classification, visitor count	GitHub stars, rankings
Reporting	GitHub issues, deny list	Issue reporting	None	None
Dependency notation	None	Flagged in scorecard	None	None

Glama is the clear outlier on security: it's the only directory running vulnerability scans (automated, but still viable), verifying maintainers, and surfacing dependency info. The rest of our directories leave that assessment up to you. PulseMCP's official/community classification helps with broad, initial trust signals, but it's not a meaningful substitute for actual code eval. If you're looking at servers for production use, Glama's scorecard saves you a step (depending on your acceptance criteria) that every other directory forces you to do externally.

Maintenance, up-to-dateness, and avoiding dead ends

The MCP landscape is changing quickly. New servers appear daily, while others are decommissioned. Developers need to pay attention to how current the entries in the directories are and whether outdated or broken servers are flagged. The table below shows a quick comparison of MCP server catalog's freshness across the four registries.

Feature	Github MCP Registry	Glama	PulseMCP	MCP Market
Total servers	<100	14K+	~8K	~20k
Last catalog update	Not displayed	<24 hours ago	<24 hours ago	<1 hour ago
Sorting options	None	Date updated	Last updated, recently released	None, but offers latest MCP section

Installation experience, from discovery to running code

The following sections describe the installation and setup of the DBHub MCP server in a development environment. DBHub is a database MCP server that supports PostgreSQL, MySQL, SQL Server, SQLite, and MariaDB. DBHub also offers a demo mode that spins up a local service with sample data using a single npx command, making it easy to test without configuring databases manually. We tested its installation across the four directories using Claude Code CLI on Mac to compare installation steps and time to first successful query.

Let's start by going through the details page of the DBHub MCP server on each of the four directories to understand how developers can discover and install the server.

Github Registry

The GitHub MCP Registry has a deep link that lets you install the MCP server directly in VS Code and use it with GitHub Copilot. But if you wanted to use it with a different agent (like Codex or Claude), the Registry simply displays the Readme.md file, and developers need to search through the file to understand the installation steps. The Readme.md file has quick start information to install dbhub, but it's not clear how one could use it as a MCP in an agent of your choice. After navigating through the Readme.md, I found a link to the installation guide under the Installation section, which in turn contains a section for installation steps with different agents, including Claude Code.

Glama

Similar to the GitHub MCP registry, Glama displays the Readme.md file of the MCP server. It also displays the schema for the MCP server, but apart from the server configuration section, DBHub's schema page mostly contained placeholder text for capabilities, tools, and resources.

The info on the schema page wouldn't help the developer install the MCP, and as a result, the developers will need to rely on the Readme file for installation steps.

Note, that the Glama details page for MCP server also has an Install Server button, but that was disabled for DBHub. Additionally, if enabled, the button will install the MCP to Glama's own web-based agent, not to the agent of your choice.

MCP Market

Similar to other directories, MCP Market displays the server's Readme page. It also has an FAQ section that mentions that DBHub can be installed via Docker or npm, but it doesn't specify instructions for installing DBHub's MCP server. Developers who discover the server in this directory will still need to rely on the server's Readme for installation steps.

PulseMCP

PulseMCP displays the server.json file for the MCP server and recommends viewing the file to see installation instructions, configuration options, and usage guidelines. The server.json file contains the supported env variables, server identifier, and a link to the schema definition, but it's not immediately clear how to install the MCP server using this information. When I fed the entire JSON to Claude code, it tried installing the MCP server with Claude Desktop by editing the claude_desktop_config.json file, but when I ran the desktop app, it failed to load the MCP server. To install the MCP server, devs would need to click on Learn More from the directory's detail page and go through the docs to install it with an agent of their choice.

Installing DBHub with Claude Code

To use the MCP, you first need to install DBHub with npm by executing the following command:

npm install -g @bytebase/dbhub@latest

After installing the package, run the demo server by executing the following command:

dbhub --transport http --port 8080 --demo

Alternatively, you can skip installation and use npx to start a demo server for testing:

npx @bytebase/dbhub@latest --transport http --port 8080 --demo

Once you have a demo server running, you can navigate to the code repository where you want to install the DBHub MCP server and fire up Claude CLI:

claude

Next, use the mcp add command to install the MCP server to the project:

claude mcp add --transport http dbhub http://localhost:8080/mcp

The command will add the MCP server to the project by creating or updating the project's .claude/mcp.json file:

Added HTTP MCP server dbhub with URL: http://localhost:8080/mcp to local config
File modified: /Users/vivekmaskara/.claude.json [project: /Users/vivekmaskara/Documents/Projects.nosync/mdh/mdedit.ai]

Once the MCP server is added, can run the /mcp command to verify the installation:

/mcp

When you execute the command, it should show dbhub as one of the installed tools, and you can press Enter to view more details about the server.

To test the setup, we asked "Which tables are in the database?". Claude Desktop successfully connected to the DBHub MCP server and retrieved a complete list of all tables in the demo database. The response identified six tables: "department", "dept_emp", "dept_manager", "employee", "salary" and "title".

The entire installation, from the initial search to the first successful query, took approximately an hour and 15 minutes, as we initially tried installing the MCP in Claude Desktop. Despite following the official docs, with Claude Desktop, DBHub's MCP server kept crashing due to npx or node compatibility issues. Additionally, after any MCP configuration, Claude Desktop needs to be fully restarted, not just the conversation window. This isn't immediately obvious and can be confusing if the server connection fails. Claude Desktop finally suggested trying DBHub with Claude Code, and when we tried following the installation steps for Claude Code, we were able to get everything working within 5-10 minutes.

Finally, while the demo mode is good for testing, the documentation could provide more detailed information about which databases are included in the demo, how to switch to production databases, and which connection string formats are used for PostgreSQL, MySQL, SQL Server, and SQLite. If port 8080 is already in use by another application, the npx command will fail with a unique error message indicating which port is being used. In this case, users must manually select an alternative port using a parameter such as port 3000.

Feature	GitHub MCP Registry	Glama	PulseMCP	MCP Market
Install method	VS Code deep link	Install button (Glama agent only)	server.json reference	README display
Claude Code support	Not directly; requires README navigation	Not directly; requires README navigation	server.json misled Claude Code into wrong config in our test	Not directly; requires README navigation
Install guidance	README with link to external install guide	README plus schema page (mostly a placeholder)	server.json with env variables and schema link	README plus FAQ mentioning Docker/npm

Our test was only able to complete a full end-to-end install from one directory (GitHub MCP Registry), and even that took 75 minutes before a failed Claude Desktop attempt led to a working Claude Code setup in 10. Glama's install button was disabled for DBHub and only targets its own agent, and PulseMCP's server.json appears to have misled Claude Code into a broken configuration.

None of these directories function as installation tools for anything beyond their preferred client, if that. Expect to end up in the server's documentation regardless of where you discover it.

Community and ecosystem

The vitality of an MCP directory depends heavily on its community. How many people are actively involved? How easy is it to submit new servers? Are there support channels? And how vibrant is the overall environment?

GitHub MCP Registry

The registry code is publicly developed on GitHub and now has over 6,200 stars, 73 watchers, and more than 550 forks. For discussions and questions, the registry documentation refers to the official MCP Discord server.

Glama

This directory positions itself as a platform for "Search, compare, and connect to thousands of MCP servers." Currently, 14,274 servers are listed (as of January 9, 2026, last updated 11:08 AM). New servers can be submitted via "Add Server" in the directory. For discussion and support, Glama refers users to its own community channels, particularly Discord and Reddit.

PulseMCP

This directory describes itself as "Everything MCP: servers, clients, use cases, tools, and newsletters." It lists over 7,600 servers and maintains a blog and a weekly newsletter. There is a submission page ("Submit") where new servers can be added via a form. An editorial curation process chooses "Top Picks." PulseMCP's guides refer to the MCP Discord server and advise users to contact the community with any problems. PulseMCP also publishes tutorials/articles on its website, so community interaction mainly takes place via website content, the newsletter, and Discord.

MCP Market

This portal aggregates more than 19,000 servers, presents star ratings and rankings, but makes little mention of community forums. Adding new servers appears to be done primarily via a submission form. The review process is opaque, and there's no clear public statement about its duration. There are no dedicated forums or Discord servers. It seems more like a website workflow plus any linked project pages (e.g., GitHub), if available.

Side-by-side comparison table

The following matrix provides a quick-reference comparison of the four major MCP directories. Use this table to identify which platform best matches your specific needs and priorities:

Criteria	GitHub MCP Registry	Glama	PulseMCP	MCP Market
Number of Servers (Jan 2026)	~65	14,000+	7,640+	19,000+
Curation Approach	Open	Curated	Open	Open
Security Verification	None	Comprehensive	Basic	None
Search Quality	Basic	Excellent	Good	Good
One-Click Install	Yes	Yes	No	Yes (with compatible clients)
IDE Integration	Per-server basis	Not specified	Not specified	Not specified
User Reviews/Ratings	Yes (GitHub star ratings)	Quality indicators	Visitor metrics	Yes (GitHub star ratings)
Update Frequency	No recency signals	High (timestamped)	High (timestamped)	High (timestamped)
Community Size	6,200+ stars, 73 watchers, 550+ forks	Discord & Reddit community	Discord, newsletter	Minimal
Best For	Official reference, standards compliance	Production deployments, security-conscious teams	Rapid prototyping, popular server discovery	Use-case exploration, comprehensive browsing

Fragmentation and security challenges

After testing four directories across six criteria, the pattern is consistent: each platform optimizes for a different stage of the developer workflow, and none covers the full end-to-end lifecycle.

The GitHub MCP Registry is the reference canonically
Glama is the only directory doing meaningful security and quality assessments
PulseMCP offers the broadest discovery surface
MCP Market gives you contextual detail for evaluating fit

As far as best practices with what we have today, consider using two or three in combination: start with PulseMCP or MCP Market to find candidates, cross-reference against Glama's scorecards for production fit, and check the official registry (if it's on there) for standards adherence.

But the bigger challenge isn't finding MCP servers. Just to go Reddit's /r/mcp sub, and you'll have a dozen dropped on your head before you can even ask. The real problem underlying all these directories is controlling what happens after you connect them.

Every server in this comparison grants AI agents access to sensitive systems, like databases or code repositories. The directories we discussed may tell you whether a server is well-maintained or vulnerability-free, but it's not going to address what an agent is allowed to do once it's authenticated, which tools it can invoke, or whether a human needs to approve potentially risky actions.

Simplifying MCP security with Descope

Finding a server from a directory is easy. Installing, based on our experience, maybe requires a little metaknowledge or a dedicated agent. But actually running it in production? For that, you need identity infrastructure that none of these MCP servers ship with.

The Descope Agentic Identity Hub is a dedicated identity provider for AI agents and MCP servers that enables MCP developers to easily connect their internal and external-facing MCP servers with AI agents.

Securely expose MCP servers to MCP clients with OAuth 2.1 and PKCE.
Use a dedicated Python MCP SDK to add auth to any MCP server built in Python.
Validate access to MCP servers with user auth and consent management.
Support context-aware MCP client registration through DCR and CIMD with agent risk assessment flows.
Assign granular per-agent and per-tool scopes to MCP clients.
Manage, monitor, and delete MCP clients connected to MCP servers.

With Descope, access is granted (or denied) at the function level, not API-wide, and policies adapt without touching your codebase. See how Descope secures agentic workflows, or start building the MCP server flow your project needs with a Free Forever account.

What Is OAuth Token Exchange?

Mrunank Pawar — Tue, 26 May 2026 17:35:21 +0000

This blog was originally published on Descope.

OAuth Token Exchange is a grant type defined in OAuth 2.0 (RFC 8693) that allows a client to present an existing security token to an authorization server and receive a new token in return, scoped and addressed for the next destination in a request chain. It operates entirely between services and the authorization server, on the basis of a token already in hand. Most OAuth grant types assume a contained interaction in which a client gets authorized, receives a token, and uses it. OAuth Token Exchange addresses the cases this common model doesn't cover, like when a token needs to travel across service boundaries, change its audience, shed unnecessary permissions, or carry an explicit record of who is acting on whose behalf. The growing relevance of token exchange is directly tied to the rise of agentic identity systems, where a single user authorization may need to propagate through an unpredictable sequence of services and tools.

This post explains how OAuth Token Exchange works, the distinction between its two core patterns (impersonation and delegation), when to use it, and what to consider when implementing it.

How OAuth Token Exchange works

A token exchange request is a POST to the authorization server's token endpoint, the same endpoint used by other OAuth grant types. The client presents a subject token, which is the existing credential representing the party on whose behalf the new token is being requested, along with a parameter identifying what type of token it is. The type identifier tells the authorization server how to parse and validate what it receives: registered types cover access tokens, ID tokens, JWTs in a general sense, and SAML assertions, among others.

Several optional parameters shape what comes back from this initial arc of the flow:

The audience parameter specifies who the new token is for (the aud claim in a JWT), like which resource servers or services the token is valid for. Setting the audience claim in the exchange request pins the issued token to a specific target, preventing cross-server reuse. The scope parameter requests the permissions the new token should carry (typically narrower than what the subject token holds).

An actor token can be included when the requesting service needs to identify itself as a party distinct from the subject, which is the mechanism that enables delegation rather than impersonation (more on that in the next section).

A requested token type parameter tells the authorization server what format to issue.

The response follows the standard shape established by OAuth: the issued token is returned in the access token field, a field name reused for historical reasons since the returned credential is not necessarily an OAuth access token in the functional sense. Crucially, presenting a token for exchange does not invalidate it. The subject token remains valid unless separately revoked. One detail worth mentioning is that RFC 8693 leaves client authentication requirements up to each implementation. The spec permits unauthenticated exchanges, but that flexibility is not a recommendation. Allowing any caller to exchange tokens without proving its own identity means anyone who obtains a valid token can potentially trade it for another one.

OAuth Token Exchange impersonation vs. delegation

The most significant design decision in a token exchange implementation is whether the issued token uses impersonation or delegation patterns. The spec defines both for different contexts, and they each have meaningful considerations for audit trail clarity.

Impersonation: When the requesting service takes on the complete identity of the subject. The resource server receiving the token sees only the original user, with no indication that an intermediate service was involved. This is appropriate when the downstream service has no need for that information, and the intermediate service is fully trusted to act within the bounds of the original authorization.

Delegation: When the requesting service retains its own identity while acting on behalf of the subject. The issued token is a composite: it carries both the subject (the original user or entity, or sub) and the actor (the requesting service, or act). The actor claim is a JSON object embedded in the issued JWT containing claims about the acting party. A resource server processing a delegation token can determine both who authorized the action and which service executed it.

The key difference between these patterns comes down to audit trail clarity. Impersonation produces logs that look more or less identical to direct user actions, which is what you want when the intermediate service should be invisible. It's the opposite of what you want when you need to reconstruct what happened across a request chain, however. For multi-agent systems in particular, where an orchestrator agent may dispatch several sub-agents each calling different downstream services, delegation is the appropriate pattern. RFC 8693 also defines an authorized actor claim (may_act) that subject tokens can carry. A token with this claim pre-authorizes specific parties to exchange it, and the authorization server can inspect it when evaluating whether to honor the request. This gives the original token issuer a degree of control over how and by whom the token can be forwarded.

Whether impersonation or delegation applies is determined by the request itself: a subject token alone produces impersonation, since there is no actor identity to include. Adding an actor token enables delegation, and the authorization server can issue a composite token carrying both identities.

OAuth Token Exchange use cases

Token exchange applies broadly whenever authorization needs to cross a service boundary without re-prompting the user or forwarding a token that wasn't issued for its next destination. The examples below represent the most common patterns (but aren't an exhaustive list).

Microservices and internal service calls: When a request travels through several backend services before reaching its destination, forwarding the original token at each hop creates problems. Most critically, it was issued for a specific client with a specific audience, so downstream services may reject it, and it likely carries more scope than any individual downstream service actually needs. Exchanging tokens lets each service trade the token it holds for one correctly scoped and addressed for the next leg of its journey, while the original user's identity travels through intact.

AI agent delegation: When a user authorizes an agent to act on their behalf, that agent may need to call several downstream APIs or Model Context Protocol (MCP) servers in sequence. Rather than forwarding the original user token or requiring the user to re-authorize at each step, the agent exchanges its delegated token for one scoped specifically to each destination. The delegation chain remains intact: each downstream service can verify who authorized the action and which agent executed it.

Cross-domain federation: When a token is issued by an external identity provider (a SAML assertion from an enterprise identity provider, or a JWT from a third-party service) it cannot be used directly with a resource server that only trusts tokens from its own authorization server. Exchanging tokens bridges the gap: the external token is presented as the subject token, the local authorization server validates it, maps the identity to a local principal (an entity that can be authenticated and granted access, like a user or service), and issues a token in the local trust domain. This is particularly relevant for enterprise federation scenarios where multiple identity providers are in play.

Token exchange in agentic identity

The delegation model maps directly onto how agentic authorization needs to work at scale. When a user grants an agent permission to act on their behalf, that authorization event produces a delegated token identifying both the user and the agent. What happens next is where token exchange becomes the operative mechanism.

Agents rarely call a single service, especially for long-running or complex tasks. An orchestrating agent in a multi-agent system may invoke several tools and sub-agents in sequence, each requiring its own scoped credential. A sub-agent spawned mid-task may need to call a downstream API the user never directly interacted with. In each case, the agent exchanges the delegated token it holds for one scoped and addressed to the immediate destination, rather than forwarding the original credential or requesting a new authorization entirely. The user's identity and the agent's identity both travel through each exchange, satisfying the resource server's need to know who authorized the action and maintaining the full audit trail across every hop.

This also handles the revocation case cleanly. Because each token in the chain is issued with a specific audience and scope, revoking the user's original authorization propagates through the system: the authorization server stops honoring exchanges against a revoked subject token, and downstream services that validate tokens against the issuer's key material will reject any that have expired or been revoked. The chain breaks at the point of revocation rather than requiring per-service cleanup.

Multi-agent systems, where one agent delegates to another (which may delegate yet another sub-agent, and so on), require explicit policy at each hop to prevent scope from persisting unchanged through the chain. The authorized actor claim (may_act) gives each link in that chain a mechanism for pre-authorizing the next actor, but the enforcement logic is an implementation responsibility, not something the spec provides automatically.

Best practices and security considerations

Token exchange introduces a few implementation decisions that affect security posture in ways other grants don't. The considerations below apply across most deployments, though the specific requirements will vary depending on the trust model and pattern (delegation vs. impersonation).

Scope only to what is needed: Exchanged tokens should carry equal or narrower scope than the subject token (and most authorization servers wouldn't allow scope elevation via token exchange by default). Each exchange is an opportunity to narrow scopes to what the next service actually needs.

Authenticate the requesting client: A confidential client performing a token exchange should authenticate at the token endpoint just as it would for the OAuth Client Credentials Flow. Anonymous token exchange means anyone in possession of a valid token (including an attacker who obtained it through other means) can potentially trade it for a new one.

Design explicit policy for multi-hop delegation: The authorized actor claim enables pre-authorization of which actors may exchange a given token, but does not automatically enforce scope reduction across hops. If Agent A delegates to Agent B, which delegates to Agent C, explicit policy at each step is required to prevent the original scope from persisting unchanged through the entire chain.

Revoke input tokens deliberately: A token exchange does not revoke the subject token automatically. After exchange, audit whether the subject token needs to continue being valid. If it doesn't, revoke it. Leaving it live creates a window where two tokens with overlapping authority are both valid.

Prefer delegation over impersonation in agentic contexts: When intermediate services are part of an observable, auditable workflow, delegation produces tokens that accurately reflect what happened: which user authorized the action and which agent executed it.

Implementation example of OAuth Token Exchange

We'll use Descope's integration with Skyflow for MCP servers in the following example. In this scenario, Descope's authorization server exposes a token exchange endpoint as part of its OAuth 2.1 infrastructure. When the MCP server is configured in Descope, the .well-known OpenID configuration includes the authorization, token exchange, JWKS, and Dynamic Client Registration (DCR) endpoints. A Descope access token issued after user authentication and consent is exchanged for a Skyflow bearer token at runtime. That Skyflow token carries contextual information about the user's role and drives row-level security and privacy policy enforcement before any data is returned to the agent. The user identity travels through the exchange; the downstream service makes authorization decisions based on who the user is, not which service is calling.

More broadly, Descope's Agentic Identity Hub features capabilities using the delegation model that token exchange enables. When a user authorizes an AI agent through Descope's consent flow, the agent receives scoped credentials tied back to that user. When the agent calls a downstream service, those credentials include the chain of custody (who authorized the action, which agent executed it, etc.). That traceability is what makes agent access auditable and revocable after the fact.

The value of OAuth Token Exchange in modern identity

OAuth Token Exchange fills a crucial gap that other grant types don't: what happens when authorization has been established and a request needs to move through multiple services before it reaches its destination? By providing a clear answer to and standard for that question, OAuth Token Exchange makes it possible to preserve identity context, enforce least privilege at each hop, and maintain an audit trail across complex request chains without re-prompting the user.

Its relevance has grown exponentially with the rise of agentic identity. The delegation patterns defined in this spec, specifically the actor and authorized actor claims, give agentic systems a principled way to represent the relationship between a user's authorization and the agent acting on their behalf, at every leg of a multi-service (or multi-agent) workflow.

Descope's Agentic Identity Hub is designed to put these patterns into practice, providing the delegation infrastructure, consent flows, and audit streaming integration that makes agent access governable and revocable. To get started securing your agentic project, sign up for a Free Forever Descope Account, join the AuthTown dev community, and reach out to our auth experts to learn more.

FAQs about OAuth Token Exchange

What is OAuth Token Exchange?

OAuth Token Exchange is a grant type defined in RFC 8693 that allows a service to present an existing security token to an authorization server and receive a new one in return. The new token may have a different audience, narrower scope, different format, or carry delegation semantic identifying which service is acting on whose behalf. It operates entirely between services with no user-facing redirect or re-authorization, and is increasingly used in agentic systems where a single user authorization needs to propagate through multiple downstream services.

Is OAuth Token Exchange the same as refreshing a token?

No. Token refresh is for receiving a new access token for the same client, audience, and authorization context. Token exchange is a different mechanism: it takes an existing token and issues a new token that may have a different audience, scope, or format, or carry delegation patterns identifying a separate acting party. Refresh is about extending a session, while token exchange is about crossing a service boundary.

Does token exchange work with non-JWT token formats?

Yes. The spec defines type identifiers for several token formats, including opaque tokens and SAML assertions, in addition to JWTs. The type identifier parameter tells the authorization server what format it's receiving so it knows how to validate the subject token. What format comes back depends on what the authorization server supports and what the client requests via the requested token type parameter.

Can token exchange be used to elevate permissions?

The spec doesn't prohibit it, but it isn't an intended use and most authorization servers won't allow it by default. Token exchange is designed to narrow authorization scope at each hop, not expand it. A deployment that permits scope elevation via exchange would need to be explicitly configured that way, and doing so would undermine the least-privilege intent of the mechanism.

What happens to the original token after exchange?

It stays valid. Performing a token exchange does not revoke the subject token. If the original token shouldn't remain usable after the exchange, it needs to be revoked separately through whatever revocation mechanism the authorization server provides.

What Is PKCE, How It Works & Flow Examples

Mrunank Pawar — Fri, 22 May 2026 15:00:00 +0000

This blog was originally published on Descope.

You'd think the most secure OAuth flow wouldn't need a patch, but the standard Authorization Code flow has a blind spot. It can't guarantee that the app redeeming an authorization code is the same one that requested it. That gap opens the door to interception and Cross-Site Request Forgery (CSRF) attacks. Proof Key for Code Exchange (PKCE) closes it.

In this guide, we'll explore what PKCE is and how it stops these attacks. We'll break down the standard Authorization Code flow, pinpoint where PKCE adds value, and examine why organizations are embracing it, even before it's officially mandatory in the latest OAuth standard.

Main points

Authorization Code flow has a verification gap. It can't confirm the app exchanging the code is the one that requested it.
PKCE binds request and token exchange. A dynamic code challenge verifies the legitimacy of the client.
Public clients need it, all clients benefit. PKCE protects apps with or without client secrets.
PKCE is mandatory in OAuth 2.1. It's no longer optional—it's the new standard.

What is PKCE?

PKCE, pronounced "pixie," is a security extension for OAuth 2.0's Authorization Code flow. While it's designed for scenarios where the client secret cannot be securely stored, all applications can benefit from PKCE. In fact, while it's already recommended in the best practices for OAuth, PKCE is a requirement for all clients using the in-development OAuth 2.1 specification.

As an enhancement for standard OAuth, PKCE can benefit all types of applications for two big reasons:

CSRF attacks: When a malicious site or app initiates an authorization request without the user's knowledge.
Authorization code interception/injection: When an attacker intercepts an authorization code and exchanges it for access tokens before the legitimate application does.

The standard Authorization Code flow and where PKCE steps in

OAuth provides several different "grant types"—standardized methods for obtaining access tokens. Grant types are associated with different scenarios, with each one offering a different balance of security and convenience. One of these is the Authorization Code grant type, widely considered to be the most versatile and secure of the bunch.

Authorization Code flow

The "vanilla" Authorization Code flow is meant for applications that can maintain a server-side component to securely store credentials. Here's how it works:

User initiates login: The user chooses to grant your application permissions via OAuth, such as by choosing "Log in with Service (e.g., Google)" in your app.
Authorization Code request: The client requests an Authorization Code from the authorization server, including information about what the app is and what permissions it's requesting.
Prompt for consent: The authorization server asks the user to authenticate and provide consent for the app to access their resources.
User authentication: The user logs in to the authorization server and approves the requested permissions.
Authorization code return: The authorization server redirects the user back to your application with a temporary Authorization Code
Token exchange: Your application sends this code to the authorization server along with your app credentials.
Access token issued: The authorization server validates everything and returns ID and access tokens
Resource access: Your application uses the access token to request protected resources

In this flow, the application never sees the user's credentials. Instead, the user authenticates directly with the authorization server, which then provides the app with a temporary authorization code.

The security gap

The standard Authorization Code flow has a fundamental flaw: there's no way to verify that the client exchanging an authorization code for tokens is the same client that initiated the request. This raises several concerns:

An attacker who intercepts the authorization code can use it to obtain access tokens because there's no verification that ties the code to the original requesting application.
Even if the application uses a client secret (essentially a password shared between the app and authorization server), this only proves the client's identity, not that this specific client originally requested this specific authorization code.
Since there's nothing binding the initial request to the token exchange, the flow is also vulnerable to CSRF attacks, in which a user could be tricked into initiating an unintended authorization flow.

This security gap affects all types of applications, though it's especially problematic for clients that can't securely store client secrets. This is where PKCE comes in, binding the initial authorization request and the token exchange.

PKCE flow

Without PKCE, OAuth authorization code flows don't have a way to verify which specific client sent this specific request. To understand how PKCE eliminates this vulnerability, we merely need to look at its name: Proof Key for Code Exchange, meaning you need proof you originated the authorization request to exchange the code for tokens.

To achieve this, PKCE has the requesting application create a new type of secret, a "code verifier." This is used to create a "code challenge," which the authorization server uses to confirm which app sent the request. Here's how it works:

User initiates login: Just like in a standard Authorization Code flow, the user initiates the process by selecting the prompt associated with granting your application permissions via OAuth, like "Log in with Service (e.g., Google)."
Code verifier creation: Before starting the flow, your application generates a random secret. This is not the same as a client secret—it's a special component called a "code verifier." Client secrets can still be used alongside it. Your application also creates a "code challenge" by transforming the verifier, usually by hashing it (a one-way process that can't be reversed or decoded).
Authorization code request: The application requests an authorization code from the server and includes the code challenge (along with the hashing method, like SHA-256).
Prompt for user consent: The authorization server prompts the user to authenticate and provide consent for the requested permissions (same as standard flow).
User authentication: The user logs in and approves the permissions (same as standard flow).
Authorization code return: The authorization server redirects back to your application with the code.
Token exchange (with verification): Your application sends the code to the authorization server along with the original code verifier.
Server verification: The authorization server compares the previously shared code challenge to the recently shared original code verifier before issuing any tokens. For example, if the method used was hashing with SHA-256, the server will also hash the code verifier and ensure it matches the code challenge; the two strings should be the same.
Access token issued: If the code verifier matches up with the code challenge, the authorization server returns ID and access tokens.
Resource access: Your application can now use these tokens to request the necessary resources (as in the standard flow).

Using PKCE in your endpoints enables the authorization server to verify that the client requesting tokens is the same one that made the request. Even if an attacker intercepts the authorization code, they can't exchange it for tokens without the original code verifier. Only the legitimate application has this in its untransformed (e.g., unhashed) state.

PKCE in public vs. confidential clients

In OAuth terminology, clients are either "public" or "confidential" based on their ability to securely store credentials. Public clients are apps that cannot safely store a client secret because their code is fully exposed to the user or can be extracted easily. Public apps include:

Single-page apps (SPAs) running entirely in the browser
Native mobile apps
Certain types of desktop apps, like those that don't use TPMs (Trusted Platform Modules) to securely store credentials

Public clients need PKCE because they can't rely on client secrets for security. Confidential clients, on the other hand, can securely store credentials because they either run in controlled server environments or the code and secrets are otherwise inaccessible to end users. So, why would you want to use PKCE for a confidential client?

Protection against authorization code injection attacks and CSRF: As previously mentioned, CSRF and authorization code injection attacks are potential threats to all types of applications. OAuth 2.0 Best Practices recommend PKCE for confidential clients because it "provides strong protection against misuse and injection of authorization codes" and "prevents CSRF even in the presence of strong attackers."
Adjunctive security that complements (not replaces) client secrets: The OAuth PKCE spec makes no bones about it—PKCE is not a replacement for client secrets or authentication. While it was originally designed to protect public clients, PKCE proved useful as an add-on to existing mechanisms by preventing CSRF attacks, prompting the question: "Why not add PKCE if you can?"
Protection against implementation vulnerabilities: In the absence of PKCE, it's possible for a client implementation to fail at properly verifying state parameters (an OAuth mechanism used to deter CSRF attacks). Because PKCE is verified by the authorization server, it provides protection even when client-side verification is flawed or incomplete.

PKCE benefits

PKCE Benefit	Public Clients	Confidential Clients
Eliminates need for client secret	✅ Required — can't store secrets securely	❌ Still uses client secret
Prevents authorization code interception	✅ Essential to prevent token theft	✅ Adds an extra layer of protection
Mitigates CSRF attacks	✅ Protects flows in exposed environments	✅ Strengthens existing CSRF defenses
Recommended in OAuth 2.0 best practices	✅ Strongly recommended	✅ Strongly recommended
Required in OAuth 2.1	✅ Mandatory	✅ Mandatory
Protects against poor client implementations	✅ Helps when state checks are missing or weak	✅ Useful fallback in misconfigured setups

PKCE use cases and examples

Although PKCE was originally developed to secure authorization code flows on public clients, the reasons for adoption can vary across use cases and application types. Even so, there are virtually no scenarios in which an additional layer of seamless security is unwelcome.

Ideal PKCE use cases include:

Native mobile applications: In the original PKCE scenario, native mobile apps are public clients that can't securely store secrets. Without PKCE, these applications couldn't use the authorization code flow without exposing credentials to anyone with the knowledge and tools to find them.
Single-page applications (SPAs): SPAs benefit from PKCE in the same way native mobile apps do: all their code runs in the browser, meaning there's no server-side storage for client secrets. SPAs rely on PKCE to use the authorization code flow safely.
Desktop applications: Some desktop applications can leverage TPMs and other mechanisms to secure client secrets even if the application runs entirely on a user device, but many don't have this design. Like other public apps, these desktop clients need PKCE to use the authorization code flow securely.
OAuth 2.0 best practices and 2.1 compliance: OAuth 2.0 best practices recommend PKCE be used for every client, not just public ones. OAuth 2.1, despite being in its draft stage, has already been adopted by many organizations. It makes PKCE mandatory.

PKCE and MCP adoption

The Model Context Protocol (MCP) is a standardized way for Large Language Models (LLMs) and AI agents to connect with external tools, APIs, and data sources. The authorization specification for MCP formally adopted OAuth 2.1, requiring developers leveraging the protocol to "implement OAuth 2.1 with appropriate security measures for both confidential and public clients." That means using PKCE.

Because MCP serves as the "universal remote" that serves up AI agents to connect with external tools, OAuth was the logical choice for authorization. OAuth already has a strong, proven foundation spanning over a decade, making developing a new standard just for AI use cases a moot point. OAuth 2.1 provides the latest and most secure set of requirements, and PKCE adds a crucial layer of protection to a budding ecosystem still finding its footing.

MCP's embrace of OAuth 2.1 (and thus PKCE) is particularly significant because of the AI protocol's widespread acceptance and sudden rise to prominence. It's already seen adoption by OpenAI's Agents SDK and industry leaders like Google, with the tech giant releasing their own "complementary" Agent2Agent protocol that can work hand-in-hand with MCP. Looking to the future, as MCP becomes more prevalent, so does PKCE.

No-hassle OAuth Authorization Code flows with PKCE

PKCE may sound like a complicated identity concept at first glance, but it's easily integrated with the right tools. Descope is a comprehensive external identity and access management solution that makes complex auth challenges drag & drop simple.

Descope can be configured as an OIDC Provider to easily add PKCE-based flows to your app. Our MCP Auth SDKs help make remote MCP servers OAuth-compliant by implementing OAuth, PKCE, dynamic client registration and more in just three lines of code.

Sign up for a Free Forever account with Descope to see how PKCE-enhanced OAuth flows can enhance your users' auth journey. Got questions about Descope? Book time with our auth experts.

Gemini vs. ChatGPT for Coding: A Developer's Guide

Mrunank Pawar — Wed, 20 May 2026 15:00:00 +0000

This blog was originally published on Descope.

Artificial intelligence (AI) is no longer just a buzzword floating around tech conferences or your Twitter feed. It's sitting right next to you, reviewing your code, naming your functions, and occasionally hallucinating—with surprising confidence. For modern full-stack developers, AI assistants have become essential tools, speeding up boilerplate tasks, helping debug errors, and even suggesting entire architectures when you're just trying to rename a variable.

This three-part series takes a closer look at today's most talked-about AI copilots: ChatGPT, Claude, Gemini, and GitHub Copilot. Part one pitted Claude against ChatGPT. This second installment compares Gemini vs. ChatGPT, focusing on how these two chatbots perform in real-world coding workflows. You'll learn where each shines, how they integrate into your workflows, and whether Google's Gemini is really the serious contender it claims to be.

This article covers:

Gemini vs ChatGPT for coding generation quality
Gemini vs ChatGPT in troubleshooting capabilities
Gemini vs ChatGPT in integration possibilities
Gemini vs ChatGPT in business applications

Gemini vs. ChatGPT at a glance

Before we get into a hands-on comparison of coding tasks between Gemini and ChatGPT, it's helpful to establish some baseline comparisons. Here's what sets these two programs apart at a high level:

	Gemini	ChatGPT
Reasoning, problem-solving, and analytical skills	Gemini 2.5 Pro excels in structured reasoning tasks and breaking down complex problems into manageable steps, making it particularly effective for in-depth analyses and codebase refactoring.	ChatGPT (GPT-4.1) demonstrates superior performance in coding and instruction-following tasks, with significant improvements over previous models that make it highly efficient for software development and debugging.
Document analysis and summarization	Gemini may have a slight edge in processing scale,	ChatGPT excels in summarization quality.
Emotional intelligence and conversation style	Gemini is known to maintain a professional and factual tone, suitable for tasks requiring precision and clarity.	ChatGPT offers a more conversational and adaptive interaction style, capable of adjusting its responses based on user tone and making it ideal for collaborative and creative tasks.
Real-time data and web access	Gemini integrates with Google Search to provide real-time information, enhancing its responses with up-to-date data.	ChatGPT features real-time web browsing capabilities that allow it to access and cite current information from the internet, thereby improving the relevance and accuracy of its responses.
Cost, access, and plans	Gemini 2.5 Pro is available through the Gemini Advanced plan for $19.99/month, which includes Google One storage perks and more. The model is also available for preview in Gemini's free plans, although it is greatly restricted.	ChatGPT offers the smaller GPT-4.1-mini model on the free plan with generous usage restrictions, while the full GPT-4.1 model is accessible on the Plus plan at $20/month and above, providing access to advanced tools like memory, vision, file handling, and plugins.

On the whole, some of the most impactful differences between the models are in the logic factors. Gemini is ideal for comprehensive, structured problem-solving, while ChatGPT is better suited for rapid, code-centric tasks. The two AI coding tools' biggest point of convergence is in document analysis and summary. With a context window of 1 million for the best models available from both chatbots, both models are capable of handling large documents.

Now, let's take a deeper dive into what exactly Gemini and ChatGPT are and how each AI coding tool performs on its own.

Understanding Gemini's utility for coding

Gemini is Google's next-generation family of large language models (LLMs), developed by Google DeepMind. Introduced in December 2023, Gemini is a multimodal AI system capable of understanding and generating text, images, audio, and video. The Gemini models are optimized for various use cases and come in different sizes: Pro, Flash, and Flash-Lite.

The following are its key features and capabilities:

Multimodal processing – Gemini 2.5 Pro natively supports text, code, images, audio, and video inputs, enabling seamless integration across various data types.
Extended context window – It boasts a context window of up to 1 million tokens, allowing for the processing of extensive documents and codebases. This capability is great for improving productivity for tasks that involve multiple, possibly humongous files. More on this below.
Advanced reasoning – Similarly to Claude 3.7, Gemini 2.5 Pro employs a "thinking" approach to break down complex problems into manageable steps, enhancing its problem-solving capabilities.
Enhanced coding performance – Gemini 2.5 Pro excels in code generation and transformation, scoring 63.8 percent on the SWE-Bench Verified benchmark, indicating its proficiency in software engineering tasks.
Integration with the Google ecosystem – It integrates seamlessly with Google Workspace and Cloud services, which eases adoption, especially in Enterprise setups.

Gemini 2.5 Pro utilizes a transformer-based architecture optimized for multimodal inputs. The model's extended context window supports in-depth analysis of large data sets, making it suitable for tasks like summarizing lengthy documents or analyzing extensive code repositories.

Most commercially available models (i.e., Claude's and OpenAI's non-4.1 models) reportedly show significant drops in response quality after using 32,000 tokens, which equates to at least approximately 16 percent of their total context window (Claude offers 200,000, and OpenAI 128,000). If you were to use that ratio for a 1 million context window, you still get to use over 160,000 tokens in a single high-quality conversation, which is much more than the competitors. However, it's important to note that this is only available in the Gemini Advanced plan, not the regular free Gemini plan.

Understanding ChatGPT's utility for coding

ChatGPT is OpenAI's flagship conversational AI, widely used for coding, research, and creative tasks. It's popular across domains like software development, academic research, creative writing, and data processing. Since its debut in November 2022, it has become nearly synonymous with consumer-facing AI tools. ChatGPT supports a range of models from OpenAI's model family, with capabilities spanning natural language, image, and audio inputs.

As of May 2025, the default model in ChatGPT is GPT-4o (short for "omni"), a multimodal model designed for fast, context-rich, and interactive use across text, vision, and speech. However, ChatGPT has very recently (May 14, 2025) started offering its GPT-4.1 and GPT-4.1-mini models.

GPT-4.1 brings significant enhancements over its predecessors. It's designed to excel in coding tasks, instruction following, and long-context comprehension. It supports a context window of up to 1 million tokens, enabling the processing of extensive documents and codebases effectively. It is available to subscribers on ChatGPT Plus, Pro, and Team plans, with the GPT-4.1-mini available to free users.

Its key features are as follows:

Enhanced coding capabilities – GPT-4.1 exhibits superior performance in coding tasks, surpassing previous models like GPT-4o and GPT-4.5 in benchmarks such as SWE-Bench Verified.
Improved instruction following – The model exhibits better adherence to complex instructions, making it more reliable for tasks requiring multistep reasoning.
Expanded context window – With support for up to 1 million tokens, GPT-4.1 can handle large-scale documents and data sets without the need for chunking or summarization.
Multimodal capabilities – GPT-4.1 maintains multimodal functionalities that allow it to process and generate text and image inputs, enhancing its versatility across various applications.

The newly launched GPT-4.1 supports a large context window of up to 1 million tokens (through the OpenAI APIs), bringing it on par with Gemini's offerings. However, the current ChatGPT pricing page reflects that even ChatGPT Plus users are limited to a maximum context window of 32,000 tokens to any OpenAI model, which is quite limited, to say the least.

ChatGPT is built on OpenAI's GPT-4.5 architecture, a transformer-based model fine-tuned through a combination of unsupervised learning, human-in-the-loop supervision, and reinforcement learning with human feedback (RLHF). This setup enhances its pattern recognition and creative generation abilities. However, prompt quality still plays a major role in getting effective results.

Gemini vs. ChatGPT: Code generation quality

Similarly to the comparison of Claude and ChatGPT in part one, we'll use two coding prompts—one for a frontend component and another for a backend script—to evaluate the coding abilities of the two. The prompts will contain requirements but will also be purposefully vague in some aspects to see how (or if) the models fill in the gaps on their own.

From the frontend coding tests, both tools performed well. ChatGPT seems to give ready-to-use, up-to-date code snippets, while Gemini is extremely detailed in its code explanations.

The backend coding tests were more revealing in terms of differences. ChatGPT is great for quick backend tasks like adding an endpoint to an internal app. However, no real security measures were implemented in its code snippet, apart from adding a few headers. Conversely, Gemini has gone all out to make sure it satisfies each requirement on the list. It's great for vibe coding but not very accessible for devs looking for a quick starting point for their app.

Frontend code generation with both AI coding tools

For the first test pitting Gemini against ChatGPT, let's start with the fundamental frontend coding task of creating a React component. Here's the prompt we'll use for this test:

Create a Next.js component that displays a list of products fetched from an API endpoint. Each product should show its name, price, and availability status. Format the price as currency (e.g., $12.99), and display a loading indicator while the data is being retrieved. Ensure the component handles errors gracefully by showing an error message if the API request fails.

Importantly, this prompt:

Specifies a framework (Next.js) as opposed to a plain React component;
Requires API data fetching and asynchronous handling;
Instructs on data formatting (currency);
Includes UI states (loading and error handling); and
Asks for multiple data fields per item (name, price, and availability).

These factors will inform what we look for as we evaluate each tool's outputs.

ChatGPT's response to our frontend coding test

Let's take a look at how ChatGPT's free version responds to this prompt:

ChatGPT first summarizes how it will address the prompt and then generates a code snippet for the Next.js component. Then, it includes a sample backend API response format to make it easy for you to understand the backend data schema that it uses. Finally, it provides a short snippet demonstrating how to use the Next.js component on a page.

Let's analyze the code returned by the prompt.

The first thing that stands out: you cannot plug and play this component in your Next.js app because it uses an imaginary backend URL (/api/fetch). If you already have a backend ready to use at this point, you can replace the value of APP_URI with the URL to your backend and then test this code. In other cases, you would need to redo the fetchProducts function to use a set of dummy values as posts while you're developing the component. Because of this, it wouldn't be fair to call it an "easy-to-use" placeholder for the external data source.

Next, all the mentioned properties are included, and the price has been formatted as requested in the prompt using the JS Intl object, which is a good practice.

Finally, the loading state has been handled appropriately as well.

You'll also find an example API object that the component expects, along with an example of how to import and use the component. These are nice to have, and you can easily construct an API in Next.js using the example object to try out the component.

Gemini's response to our frontend coding test

When tasked with the same prompt, here's what Gemini responds with:

Gemini leads with the code for the Next.js component, followed by a detailed explanation of how it works. Towards the end, it provides the code for an API endpoint you can temporarily create if you want to test out your component with an actual backend API.

Similarly to the ChatGPT response, you cannot plug and play this component in your Next.js app. It uses the imaginary backend URL (/api/fetch) as well. However, it realizes that Next.js supports creating APIs easily and hence also provides an example API code. But if you look at the file location mentioned in the prompt for creating the API route, as well as the function declaration style export default function handler(req, res) {, you'll realize that these are meant for an older version of Next.js. This hints that Gemini might be working with outdated Next.js training data.

The JSX structure of the component looks pretty much the same as ChatGPT's version. However, another important detail it missed is the "use client" declaration at the beginning of the file. It uses hooks in the component, which require the component to be a client-side-only component for them to work in Next.js 13 and above. Gemini missed this detail, most probably because it meant to write the code for a version of Next.js older than 13. The code explanation that it provides is quite detailed, though.

The use of Tailwind classes is a major difference from the ChatGPT response. It's a good practice since the default create-next-app CLI currently gives you the option to install Tailwind when creating a new project. This means it is going to come in handy for a large number of Next.js developers, regardless of whether they are experienced devs or "vibe coders."

For someone coding an app from scratch, this is an excellent starting point. For someone who already uses a different styling system and maybe has more style guidelines to adhere to (such as no icons or a different color scheme), a few more prompts should do the trick.

Backend code generation with both AI coding tools

Here's the prompt for the backend task:

Write an Express.js API endpoint in Node.js that accepts a POST request with a JSON payload containing a product's name, price, and category. The endpoint should validate the input and store the product details in a product database. Also, it should handle errors reasonably. Make sure your implementation considers common security best practices.

As we evaluate each AI coding tool's response, we'll be looking for how well it:

Handles the POST request
Implements validations
Stores the details in a dummy database
Responds with descriptive error details
Uses Helmet to add secure HTTP headers to the response

Let's see how each model performs.

ChatGPT's response to our backend coding test

Here's what ChatGPT's free version responds with:

ChatGPT starts with a quick summary of how it will address the prompt and then provides the code for the endpoint along with an npm command to install the required dependencies. Towards the end, it summarizes the security considerations it took into account when generating the code.

The code snippet works, and the response is quite concise itself, with the code snippet meeting all of the requirements laid out in the prompt. As an added benefit, it uses Joi for validations, which is better than manually writing them in cases like these.

Gemini's response to our backend coding test

Here's what Gemini's free version responds with:

Gemini lists out the components it chooses to build the solution with, then spends some time explaining how to create a new Node.js project and set it up. It also includes a database setup file and detailed instructions on creating validation middleware and the API endpoint. Towards the end, you will also see plenty of instructions on how to test out the API once you have set it up.

As you can see, it's an extremely lengthy response compared to ChatGPT's. It uses Helmet and Joi as well. However, it goes a step further and gives you the file structure of the project, along with a detailed dummy database. The validation setup is quite detailed, providing a surplus of error messages and allowing you to easily remove any that you do not want in your code.

You'll also find detailed instructions on how to set up the code and run the app, along with plenty of explanations on how the code works.

Gemini vs. ChatGPT: Troubleshooting capabilities

Debugging and writing test cases are inherently context-heavy tasks, which make them difficult to evaluate without the specific structure and quirks of a real-world project. This section is based on some hands-on experience as well as widespread community feedback. For instance, many developers on platforms like Reddit have echoed similar sentiments when comparing Gemini and ChatGPT for everyday software maintenance tasks.

On the whole, debugging works differently with each AI coding tool. Gemini is methodical and excellent at sticking to best practices, whereas ChatGPT can be more flexible and adaptable. In a similar vein, ChatGPT has an edge in test generation in complex, dynamic environments.

Both models are generally on par in terms of contextual awareness, with Gemini offering more stable formatting and longer-term memory in extended sessions, while ChatGPT offers more fluid, natural interaction, but sometimes at the cost of precision in code formatting.

Debugging with both AI coding tools

Gemini performs best when debugging is framed as a step-by-step reasoning task. It excels at identifying logical flaws, uninitialized variables, and inconsistent states when given well-structured, isolated code. It is also great at sticking to best practices, which can sometimes help avoid debugging detours on the whole. However, it tends to struggle with ambiguous or incomplete context, especially in cases where understanding a broader system or multiple file relationships is critical. Its debugging output can feel methodical but sometimes lacks flexibility when the problem isn't clearly defined.

ChatGPT handles debugging in a more conversational and exploratory style. It's capable of asking clarifying questions, simulating test scenarios, and even suggesting minimal code diffs. In real-world usage, it tends to be more effective at identifying root causes across loosely scoped snippets and explaining the implications clearly. Its strength lies in adaptability; even when prompts are vague, ChatGPT often gets closer to what the developer intended compared to Gemini. ChatGPT is generally preferred for live debugging scenarios due to its responsiveness, conversational depth, and ability to reason across incomplete or messy inputs.

Comparing Gemini and ChatGPT responses

The tendencies described above illustrate what developers can expect when debugging with Gemini or ChatGPT, respectively. However, these tendencies do not always hold true.

For example, let's take the same problem from the first part of this series, where we saw ChatGPT struggling to provide the right, updated solution:

"I am trying to add a static form as a standalone component to an Angular 19.2 app, but receiving the following error: No provider for HttpClient How do I fix it?"

Here's what Gemini responds with:

Gemini describes the potential cause of the problem and then recommends solutions depending on the Angular version your project is using. Then, to help the users understand the issue better, it also goes on to explain why these solutions fix the problem.

Unlike ChatGPT (and Claude in part one of the series), Gemini is able to pinpoint the issue and the correct, up-to-date solution for it. Surprisingly, if you ask its cutoff date, it turns out to be 2023, when Angular 19.2 was nowhere near release. And yet, it is able to put together the right solution because, in reality, the right solution has been present since Angular 17+, and the old HttpClientModule solution was deprecated only in Angular 18 in 2024.

This means that Gemini demonstrated a better understanding of best practices by sticking to an up-to-date, recommended solution rather than blurting out the solution that it has seen more times in its training data.

For reference, here's what ChatGPT responded with:

ChatGPT recommended the deprecated solution of using HttpClientModule to solve the problem.

Test generation across both AI coding tools

Gemini 2.5 Pro is fully capable of generating unit tests for straightforward components. ChatGPT with GPT-4.1, on the other hand, delivers strong results in small test generation tasks and scales better in more complex use cases. When working with projects that span multiple files or languages, such as a multimodule Android app in Kotlin, ChatGPT can infer dependencies, generate mocks, and select appropriate test frameworks more reliably.

While both tools handle simple unit test generation well, ChatGPT pulls ahead in complex environments where framework compatibility and test coverage matter most.

Contextual awareness of both AI coding tools

Both Gemini 2.5 Pro and ChatGPT (GPT-4.1) demonstrate strong contextual awareness when it comes to understanding and editing existing codebases. As seen in previous examples throughout this article, both tools can infer variable relationships, follow control flow, and suggest changes that align with the logic and style of the original code.

That said, ChatGPT occasionally stumbles with formatting, especially when generating longer code snippets, sometimes introducing typos or indentation issues that wouldn't compile without tweaking. Gemini, by contrast, tends to produce more cleanly formatted suggestions out of the box, though it may require slightly more guided prompting in loosely scoped edits.

In back-and-forth conversations, both tools are capable of maintaining context and building upon prior messages. Of course, it is imperative that the prompts are clear and scoped to a consistent thread. However, ChatGPT (GPT-4.1) can occasionally "forget" or slightly drift from the previous context in complex multiturn exchanges, especially if they involve formatting-sensitive outputs like HTML, YAML, or code blocks.

Gemini vs. ChatGPT: Integration possibilities

The best AI tool is the one that can most easily integrate into your existing workflows. Here's a comparison of Gemini and ChatGPT (and their models) in terms of their integration possibilities.

With respect to integrated development environment (IDE) integrations, both AI coding tools support key capabilities like Visual Studio Code. They also offer a clean and polished feel to all integrations, with the caveat that response quality can vary with prompt complexity.

In terms of API and external connections, each has clear utility. If you're building inside the Google Cloud ecosystem or integrating with Google Workspace tools, Gemini 2.5 Pro is the natural fit. However, for broader adoption, GPT-4.1 provides a more flexible, developer-first API experience with faster onboarding, easier experimentation, and support for a wider range of workflows out of the box.

IDE integrations in both AI coding tools

Gemini offers official support for IDEs, like Visual Studio Code and JetBrains IDEs (including IntelliJ), through its Gemini Code Assist extension. These plugins bring AI-powered autocomplete, code explanations, and debugging tips directly into the development environment. The experience is tightly integrated and designed to reduce context switching, letting developers chat with Gemini, request code completions, or ask for improvements without leaving their editor. However, while Gemini Code Assist is generally reliable, some early reviews have pointed out inconsistencies in code suggestion quality, especially for less common frameworks or languages.

ChatGPT also supports Visual Studio Code through community-developed extensions. These provide live access to GPT-4o for code generation, explanation, and problem-solving tasks. The experience is polished, with ChatGPT typically accessible via a sidebar or command palette. Reliability is strong overall, with consistent results and minimal lag, though (as with Gemini) the quality of responses can vary based on the clarity of the prompt and the complexity of the task.

External service connections in both AI coding tools

Gemini 2.5 Pro is accessible via the Gemini API, hosted on Google Cloud, and supports a wide set of features for developers integrating AI into production environments. Authentication is handled through standard Google Cloud IAM and API key mechanisms, with granular project-level access controls. Gemini's function calling support allows developers to define callable backend functions for setting up AI-powered workflows across applications. Its documentation is polished and enterprise-friendly, though some users may find the setup process more Google Cloud–native than developer-friendly, especially those not already embedded in the ecosystem.

ChatGPT with GPT-4.1, on the other hand, is available via the OpenAI API and is widely regarded for its ease of integration. Authentication uses simple API keys, and the platform supports function calling, tool use, and Retrieval Augmented Generation (RAG) out of the box. GPT-4.1 brings improvements in multistep API workflows and is compatible with custom GPTs, allowing developers to inject external APIs and tools into personalized assistants. OpenAI's developer documentation is extensive, example-rich, and easy to onboard with, even for teams without deep infrastructure experience.

Gemini vs. ChatGPT: Business applications

Gemini, integrated within Google Workspace and Google Cloud, is a useful and easily accessible tool for enterprises looking to boost efficiency and collaboration. For instance, FinQuery, a fintech company, uses Gemini to expedite brainstorming sessions, draft emails more swiftly, manage intricate project plans, and assist engineering teams in debugging code and evaluating new monitoring tools.

Another example is Lawme, a legal tech platform that used Gemini's long-context capabilities to simplify contract drafting and client onboarding, reporting improved efficiency and better context retention across legal workflows.

ChatGPT is widely adopted across various sectors for its adaptability and powerful language processing capabilities. At BBVA, over 3,300 employees across departments—like legal, risk, marketing, and HR—adopted ChatGPT Enterprise. Eighty percent of users said the tool saved them at least two hours per week, significantly improving overall productivity. In healthcare, Radfield Home Care used ChatGPT to support tasks such as staff training, compliance documentation, and client communication, improving service quality while reducing operational load.

Gemini vs. ChatGPT for coding: Final insights

Both Gemini with Gemini 2.5 Pro and ChatGPT powered by GPT-4.1 are formidable AI assistants, but they serve slightly different priorities and ecosystems.

Gemini 2.5 Pro is exceptionally strong in structured reasoning, long-context tasks, and Google Cloud–native applications. Its ability to handle massive token windows and process highly detailed inputs makes it a compelling choice for legal tech, document-heavy workflows, and enterprise systems where integration with Gmail, Docs, or Vertex AI is key. If your team works with complex documentation or large-scale data or already relies on Google infrastructure, Gemini is a natural fit.

ChatGPT with GPT-4.1, in contrast, is designed for speed, flexibility, and general-purpose productivity. It excels in fast prototyping, dynamic API integration, and emotionally intelligent interactions, making it especially valuable in cross-functional teams, client-facing workflows, and creative development. Its wide plugin support and custom GPT ecosystem offer a significant advantage for teams that need quick results across a broad set of tools.

In short, Gemini 2.5 Pro wins on coding depth and scale, while GPT-4.1 wins on versatility and accessibility. However, choosing between Gemini and ChatGPT isn't about which model is better but about which one complements your development style and team culture. As AI continues to evolve, the most successful developers will be the ones who know when to pick the right tool and how to wield it well.

That wraps up the second part of our series comparing leading AI coding assistants. In the final installment, we'll take a look at Microsoft Copilot and explore how it stacks up against the others in terms of real-world development experience.

Get the most out of Gemini and/or ChatGPT

In the Gemini vs ChatGPT for coding debate, both models prove themselves to be excellent AI coding tools that dev teams are already leveraging to great effect. The one you choose will likely come down to ecosystem fit and use case, but it's helpful to understand how they stack up if you have access to both. Our tests found that Gemini tends to excel in high-structure contexts, while ChatGPT tends to be a bit more dynamic and flexible. Looking forward, knowing how to use both will be key to dev success.

For more developer-focused breakdowns and tool comparisons, subscribe to our blog or follow us on LinkedIn, X, and Bluesky.

Developer's Guide to AI Coding Tools: Claude vs. ChatGPT

Mrunank Pawar — Mon, 18 May 2026 15:00:00 +0000

This blog was originally published on Descope.

As AI's capabilities continue to advance, it's playing an increasingly significant role in software development. From writing boilerplate code to debugging, explaining documentation, and even generating entire application components, AI-based tools have greatly impacted traditional app development workflows.

Conversational coding assistants have emerged as particularly valuable tools, allowing developers to use natural language to request code snippets, architectural suggestions, or environment setup instructions, or to help in understanding unfamiliar frameworks. These assistants aim to reduce context switching, boost productivity, and provide an on-demand form of pair programming.

In this three-part series, we'll compare the most prominent players in this space: Claude, ChatGPT, Microsoft Copilot, and Gemini. This first part focuses on ChatGPT and Claude, comparing their strengths, limitations, and usability for day-to-day development tasks. Through some example prompts and the tools' responses, you'll learn how they handle code generation, reasoning, error explanation, integration into your workflow, and more. By the end, you should have a good idea about which tool is a better fit for your development stack.

Claude

Claude is Anthropic's flagship conversational AI assistant, built to prioritize safety, high-context understanding, and transparency. Named after Claude Shannon, the father of information theory, it reflects Anthropic's mission to align AI systems closely with human intent. Designed with developers and knowledge workers in mind, Claude offers a chat interface that excels at long-form reasoning, contextual comprehension, and clear, step-by-step responses.

Like all things AI, Claude has seen significant upgrades since its initial release. Claude 3.7 Sonnet has achieved 62.3 percent accuracy on the SWE-bench Verified test, which evaluates the ability of AI models to solve real software problems. This is a significant improvement from Claude 3.5 Sonnet's 49 percent accuracy. Claude 3.7 Sonnet also introduces other significant enhancements:

Hybrid reasoning model: Claude 3.7 Sonnet introduces a hybrid reasoning approach, allowing users to choose between rapid responses and extended, step-by-step thinking. This flexibility enables the model to handle both straightforward queries and complex problem-solving tasks effectively.
Extended thinking mode: In this mode, Claude takes additional time to analyze problems in detail, plan solutions, and consider multiple perspectives before responding. This feature enhances performance in areas such as mathematics, physics, programming, and other complex domains.
Large context window: Claude 3.7 Sonnet offers a substantial context window, capable of processing up to 200,000 tokens. This capacity allows the model to handle extensive documents and codebases, maintaining coherence over long interactions. However, the free plan has undisclosed limits on context window and message sizes.
Artifacts and Projects: The model includes the features Artifacts for live code previews and collaborative editing, as well as Projects for organizing chat history and collaborative workflows. These are very useful in app development environments where context switching between multiple files and projects is common.
Claude Code: Alongside Claude 3.7 Sonnet, Anthropic has introduced Claude Code, a command line tool for agent-based programming. This tool allows developers to delegate complex programming tasks directly through their terminal, streamlining the development process.

Claude 3.7 Sonnet is also trained using Anthropic's Constitutional AI methodology. This training approach adheres to the model's responses with a set of human-defined ethical principles, helping provide responsible and thoughtful outputs.

As mentioned before, the hybrid reasoning capability allows Claude to switch between immediate responses and more deliberate, in-depth analysis, depending on the task's complexity. This adaptability makes it particularly effective for nuanced, human-like conversations and long-term context retention, which is essential for tasks such as debugging large codebases or conducting in-depth research…

ChatGPT

ChatGPT is OpenAI's flagship conversational AI assistant, widely used for tasks ranging from software development and research to creative writing and data analysis. Often treated as a Google-like synonym for AI, ChatGPT has evolved into a versatile tool since its launch in November 2022. ChatGPT supports multiple models from the large lineup of OpenAI models, offering enhanced capabilities across text, voice, and vision modalities.

As of May 2025, the default model in ChatGPT for free and Plus users is GPT-4o ("o" for "omni"), OpenAI's latest multimodal model. Key features of this model include the following:

Enhanced performance: GPT-4o offers improved performance over its predecessors, making it more efficient for various applications.
Voice mode: The advanced voice mode allows for humanlike spoken conversations, with response times as low as 232 milliseconds.
Image generation: GPT-4o includes native image-generation capabilities, succeeding DALL·E 3, and can create realistic images based on textual prompts.
Accessibility: GPT-4o is available to all ChatGPT users, with free users having access within usage limits and Plus subscribers enjoying higher usage caps.

GPT-4o has a maximum supported context window of 128,000 tokens. However, the context window on the free plan is very limited compared to the paid plans (8,000 on free vs. 32,000 and 128,000 on the paid plans). However, some users also report a maximum context length of about 8,000 tokens, even when accessed via the API on a paid subscription.

At its core, OpenAI's GPT-4.5 architecture, a transformer-based model primarily trained using unsupervised learning, complemented by supervised fine-tuning and reinforcement learning from human feedback powered ChatGPT. This enables it to recognize patterns more effectively, draw connections, and generate creative insights without requiring elaborate prompting… Still, as with any AI chatbot, its effectiveness is greatly impacted by the prompt clarity.

To provide up-to-date and context-rich answers, ChatGPT can employ Retrieval Augmented Generation (RAG). This technique enhances the model's responses by injecting external context into its prompts at runtime, allowing it to access and incorporate real-time information beyond its static training data. ChatGPT excels in various applications, including coding, writing, and data analysis. Its enhanced natural language processing capabilities enable more fluid and humanlike interactions, making it a valuable tool for a wide range of tasks.

General overview of the tools

Before getting into the nitty-gritty of software development, let's quickly compare these two general chatbot skills:

Reasoning, problem-solving, and analytical skills: Claude 3.7 Sonnet outperforms ChatGPT-4o in structured reasoning and complex problem-solving, particularly in tasks requiring precision and logical analysis. Its hybrid reasoning model allows for both quick responses and extended, step-by-step thinking, making it particularly effective for professional, analytical, and detail-oriented tasks such as analyzing complex if/then or case-based conditions or maintaining consistent reasoning across multiple steps.
Document analysis and summarization: Claude 3.7 Sonnet demonstrates superior capabilities in analyzing and summarizing extensive documents, such as legal contracts and historical archives, thanks to its large context window and advanced natural language processing.
Emotional intelligence and conversational style: ChatGPT-4o offers a more engaging and emotionally expressive conversational style, capable of simulating humanlike interactions across text, voice, and vision. However, it's worth noting that recent (April 2025) updates led to overly supportive and sometimes disingenuous responses, prompting OpenAI to roll back certain features to maintain authenticity. So it's been iffy in this regard for a while.
Real-time data and web access: Both options support real-time web access. ChatGPT provides this feature across its platforms. Similarly, Claude has introduced web search capabilities, allowing it to access the latest events and information to boost accuracy in tasks benefiting from recent data.
Cost, access, and plans: ChatGPT is accessible to free users with limited usage and offers a Plus plan at $20/month for enhanced features and higher usage limits. Claude is available through various platforms, including integrations that offer free access, and Anthropic provides a Pro plan at $20/month for additional capabilities.

While they share similar pricing plans and real-time web access capabilities, each tool has distinct strengths: Claude excels at complex problem-solving, while ChatGPT offers more engaging conversations. But what do these strengths mean for software development tasks?

Code generation quality

Let's start by comparing the quality of the code generated by the two. To accomplish this, we will use two coding prompts, one for a frontend component and another for a backend script. The prompts will contain requirements but also be purposefully vague in some aspects for us to understand how (or if) the models fill in the gaps on their own.

Frontend code generation

For the first test, let's try out a simple, age-old task of creating a React component. Here's the prompt that will be used for this test:

Create a React component that displays a list of blog posts fetched from an API. Each post should include a title, author, and published date. Format the date nicely and show a loading state while data is being fetched.

As you can see, the prompt is quite succinct but expects the final result to:

query data externally (or at least leave an easy-to-use placeholder for that);
include some essential properties (title, author, and published date) while leaving it up to the model to add other properties, like a header image, categories, and so on;
format one of the properties nicely, which is quite vague (but a human could interpret some meaning from it); and
show a loading state, which would involve logic for conditional rendering and UI adjustments to accommodate an additional subcomponent (basically, the other set of elements that you will only see when the component is in the loading state).

Let's take a look at how ChatGPT's free version responds to this prompt:

Let's analyze the code returned by the prompt.

First impression: you cannot plug and play this component in your React app. That's because it uses an imaginary backend URL. If you already have a backend ready to use at this point, you can replace the value of APP_URI with the URL to your backend and then test this code. In other cases, you will need to redo the fetchPosts function to use a set of dummy values as posts while you're developing the component. Because of this, it wouldn't be fair to call it an "easy-to-use" placeholder for the external data source.

Next, all the essential properties are included, and the date has been formatted adequately using the JS Date object, which is a good practice. Finally, the loading state has been handled appropriately as well.

Now, let's take a look at how Claude's free version handles the same task. Here's what Claude responds with:

For React (and pretty much all web-frontend-related tasks), you get a built-in preview of the generated code in the Claude UI. This significantly improves the chat-development experience as you can send further prompts to refine the app and watch it change very quickly compared to having to plug in the code in your app and hot reload it.

Here's what the code looks like:

Claude implements all the requirements (essential fields, formatted data field using the JS Date object, and even an emulated external data source that is easy to work with during frontend development). It also does a few extra things on its own:

UI design using Tailwind CSS, following a popularly used layout style (cards)
Icons from the open source project Lucide React for the author and publishing date fields
Basic animations such as spin effects on the loading icon and hover effects on the cards

While Claude definitely seems to be a better experience for frontend development, let's try out a backend development task next.

Backend code generation

Here's the prompt for the backend task:

Write a secure Flask API endpoint in Python that accepts a POST request with a JSON payload, including a user's name and email, validates the input, and returns a confirmation message

Here's what ChatGPT's free version responds with:

The code snippet works, and the response is quite concise, meeting all the requirements laid out in the prompt:

Handle POST request
Run null checks on data
Validate email

Such a response can be great for quick tasks like adding an endpoint to an internal app. However, no real security measures have been implemented in this code snippet. Another tiny detail to note is that ChatGPT struggles with code highlighting in long code snippets. You can already notice that in the line of code below the comment # Return confirmation above, where it incorrectly highlights the formatted string. Now, let's see if Claude does it differently.

Here's what Claude's free version responds with:

Once again, the response is structured better due to the use of Claude Artifacts. Also, the code highlighting seems to be much better than ChatGPT's. The code snippet seems to work and covers everything laid out in the prompt.

However, on a closer look, you can see that Claude tried to implement data integrity verification using HMAC to fulfill the "secure Flask API" requirement. This doesn't make sense for the use case as all of the data is being sent by the frontend at once for storage in the backend. An HMAC signature-based data integrity would work when the data was already present in the database and needed to be verified (for instance, when issuing short-lived, signed URLs).

In this case, implementing CORS or rate limiting to avoid API abuse would have made more sense.

If you prompt ChatGPT to make the endpoint secure, it implements rate limiting. In contrast, when you highlight the issues with Claude's HMAC implementation, it awkwardly updates the code to issue unique confirmation IDs for each new user registration. Upon being given a second nudge, it implements a bunch of security measures:

Adds a password field
Adds input sanitization
Implements rate limiting
Enforces HTTPS
Adds security headers

To sum up, while both tools can generate working and adequate code, Claude beats ChatGPT by a large margin when it comes to developer experience and technical details like best practices. Of course, the response will only be as good as your prompting skills, and you need to be careful to double-check everything, as both tools can hallucinate quite confidently.

Troubleshooting (bug fixing) capabilities

Debugging is one of the hardest tasks to benchmark in isolation. Real-world debugging rarely involves a single faulty line. It requires an understanding of project context, architecture, business logic, and edge cases. So it's difficult to evaluate these AI tools meaningfully without embedding them in a real workflow. This also makes a strong case against using chatbots for debugging: It's not easy to provide a complete project context to a chat-based code assistant when you're working on large projects.

The analysis in this section is informed by prior experience and widely shared public sentiment, including popular discussions such as this Reddit thread, which highlights Claude's advantage in step-by-step reasoning.

Debugging

When it comes to debugging, Claude tends to provide thorough, step-by-step debugging support. It not only identifies errors but also explains root causes and suggests structurally sound fixes, often with helpful comments and design considerations. This makes it a better choice when you're trying to understand why something broke.

ChatGPT is more direct and concise, often spotting basic bugs and producing a clean fix quickly. For simpler issues or when you're short on time, ChatGPT performs well. However, it may need extra prompting to dive deeper into architectural or semantic bugs.

However, it can't be emphasized enough that it's important to be careful when debugging with any AI tool as it can overlook issues or confidently suggest wrong solutions. For example, both Claude and ChatGPT recommend a deprecated solution to the following Angular issue:

I am trying to add a static form as a standalone component to an Angular 19.2 app but receiving the following error: No provider for HttpClient How do I fix it?

Here's what Claude responds with:

And here's what ChatGPT responds with:

Interestingly, when you call out the deprecated solution, Claude is quickly able to figure out the right solution (which, in this case, is to use provideHttpClient), while ChatGPT presents another deprecated solution.

Here's Claude's answer:

And here's ChatGPT's:

It's likely that Angular 19.2 was released after the cut-off date of GPT-4o, and since the free version does not have access to web browsing capabilities, it confidently presents made-up answers.

Test generation

When it comes to test generation, both Claude and ChatGPT perform impressively for small, self-contained functions. They generate unit tests quickly, structure them well, and cover common happy and edge cases with little friction.

However, as soon as the test scope increases—say, when writing tests for a multifile Android project written in Kotlin—Claude has a clear edge. It offers broader coverage, a stronger grasp of framework-specific conventions (like JUnit, MockK, or Espresso), and better test-file organization. Because of a larger context window, Claude is more likely to reference earlier files or set up code when generating integration tests or mocks across modules.

Contextual awareness

Contextual understanding helps when you're working with existing codebases or iterating on complex tasks over multiple turns. As seen in the previous examples, when modifying a React app across files or updating code through a sequence of prompts, both Claude 3.7 Sonnet and ChatGPT-4o demonstrate strong contextual reasoning capabilities.

When it comes to modifying an existing codebase, both tools can follow the project structure, reference variables across files, and update logic coherently. That said, ChatGPT occasionally stumbles on formatting when generating or appending code snippets. These formatting glitches can lead to small but critical typos or indentation errors that break execution unless caught by the developer.

In multiturn interactions, performance is closely tied to context window size. Claude 3.7 Sonnet's 200K-token context window allows it to track and recall large amounts of historical information, spanning full files, architectural constraints, or extended conversation threads. ChatGPT-4o, while generally strong at maintaining continuity over shorter sessions, has a smaller effective window and may start to lose precision or forget earlier turns in long, detailed exchanges.

Integration possibilities

Any dev tool is most powerful when it integrates smoothly into a developer's workflow. Both Claude and ChatGPT offer robust integration options, but their approaches reflect their design philosophies. Claude leans into collaborative structure, while ChatGPT emphasizes breadth and extensibility.

IDE integrations

Claude offers official and community-built extensions for editors like VS Code, allowing developers to query and modify code directly from their editor. Its standout features (Artifacts and Projects) are uniquely designed for collaborative development. As you've seen above, Artifacts provide a live, editable canvas within the chat. Projects group conversations and assets into task-specific threads, making Claude feel more like a long-term pair programmer.

ChatGPT, meanwhile, boasts broader IDE support, with integrations that plug seamlessly into GitHub Copilot, JetBrains, and VS Code ecosystems. These extensions are deeply embedded, offering inline completions, doc references, and context-aware suggestions that adapt as you code. However, the quality of responses in the context of coding remains somewhat inferior to Claude's.

API and external service connections

Claude provides a stable and well-documented API, ideal for embedding AI into apps, chatbots, or backend services. It's especially helpful for generating docs or assisting with schema generation and code commenting.

ChatGPT offers a more extensive API and plugin ecosystem, with support for function calling, web browsing, and even real-time data retrieval through external tools. From scheduling meetings to querying databases, ChatGPT is designed to operate like a general-purpose AI layer across your entire stack.

When it comes to integration, ChatGPT has a pretty strong ecosystem among all AI chatbots and APIs.

Business applications

In startup environments where speed and agility are key, both Claude 3.7 Sonnet and ChatGPT-4o offer significant advantages. Claude is especially effective for rapid prototyping and MVP development, thanks to features like Artifacts for live previews and Projects for persistent context. These make Claude ideal for teams managing evolving requirements. Claude has proven to be useful for companies, like Lazy AI, that have used it to boost internal software development.

ChatGPT, meanwhile, shines in tech exploration and early product development with its fast generation, wide range of integrations, and ability to spin up supporting content like documentation, APIs, and database schemas quickly. Genmab is a great example of how ChatGPT and OpenAI models can help across a wide range of tasks across the operations of a company through features like custom GPTs and support for multimodal content.

In enterprise settings, Claude's large context window and strong reasoning make it well suited for refactoring legacy codebases, standardizing documentation, and automating repetitive tasks with deep context awareness. ChatGPT could be used to complement this by offering real-time data access, plugin integrations, and a flexible API. Both tools serve distinct enterprise needs, depending on whether depth of analysis or breadth of integration is the priority.

Final insights

Both Claude and ChatGPT are powerful AI coding assistants, but the best choice depends on your goals and project context. If you're working on large-scale, high-stakes applications (like refactoring legacy systems, analyzing long documents, or managing evolving architectural decisions), Claude offers the edge with its extended context window, structured reasoning, and collaboration-focused features like Artifacts and Projects. It's particularly well suited for technical leads, backend engineers, and teams that need clarity and consistency across complex codebases.

For developers prioritizing speed, creative flexibility, and broad tool integration, ChatGPT is a more versatile companion. Its real-time data access, plugin ecosystem, and memory features make it ideal for prototyping, research, and generalist workflows. Whether you're experimenting with APIs, generating test data, or writing across disciplines, ChatGPT adapts quickly and helps get things done faster.

Looking ahead, we can expect AI assistants like Claude and ChatGPT to fundamentally reshape software development, making coding more collaborative and turning natural language into a powerful interface for building software. As these tools continue to evolve, choosing the right assistant will become less about raw power and more about how well it fits your team's rhythm, priorities, and stack.

That wraps up the first part of this series on conversational coding assistants. Stay tuned for the next installment, which explores how Google's Gemini fares against ChatGPT!

What Is YubiKey Authentication & How It Works

Mrunank Pawar — Fri, 15 May 2026 15:00:00 +0000

This article was originally published on Descope.

According to the 2024 Verizon Data Breach Investigation Report, 7 out of 10 cybercriminals prefer targeting users over attacking IT infrastructure. This preference isn't surprising: humans, not firewalls, are susceptible to phishing (social engineering attacks that steal login credentials). While MFA (multi-factor authentication) is widely accepted as phishing-resistant using any combination of factors, leveraging possession-based authentication has emerged as the gold standard today. Unlike knowledge-based authentication, the possession factor establishes user presence. Thanks to the proliferation of smartphones, virtually everyone can leverage the possession factor for 2FA (two-factor authentication). But for companies and customers who want to improve their possession-based authentication security even further, YubiKeys provide the perfect combination of resilience and convenience.

This article explores how YubiKeys work, how they differ from other authentication methods, and common YubiKey use cases. Lastly, we'll cover some key benefits to help you determine if they're right for you.

What is a YubiKey?

A YubiKey is a hardware security device that provides strong authentication when accessing computers, networks, and online services. Yubico developed these small USB or NFC-enabled keys as a physical component in two-factor or multi-factor authentication systems.

Like a door key with ridges that turn physical tumblers, YubiKeys unlock digital assets by performing operations using cryptographic keys. When a user attempts to log in to a supported service, the cryptographic keys stored on the YubiKey prove the user's identity. Combined with another factor like a password or PIN, YubiKeys provide possession-based 2FA.

YubiKeys support multiple authentication protocols and systems, including:

FIDO2/U2F: Using the WebAuthn API and CTAP protocol, enables passwordless 2FA.
OTP (One-Time Passcode/Password): Generates single-use codes.
Passkeys: A modern standard for passwordless authentication across devices.

Although they're often regarded as a higher-friction authentication tool, YubiKeys are designed to be fast and user-friendly. They often require little more than a USB connection or a single tap followed by a PIN to authenticate. While some YubiKeys feature built-in biometric scanners (for fingerprint authentication) and are more delicate, most models are extremely resistant to damage. Non-biometric YubiKeys are also built to be more durable than smartphones, with no moving parts or batteries. YubiKeys are resistant to water, crushing, and other forms of physical harm.

YubiKey vs. passkey vs. authenticator app

To fully understand their place in the authentication ecosystem, it's helpful to compare YubiKeys with other popular methods. First, let's discuss their relationship with passkeys, which are a form of cross-device passwordless authentication built atop the FIDO2 protocol.

YubiKey vs. passkey

The most obvious difference between YubiKeys and passkeys is that YubiKeys are physical devices, and passkeys are FIDO2-based credentials. However, YubiKeys and passkeys aren't mutually exclusive. As Yubico's FAQ on passkeys phrases it, "They're the same, and they're different." They're similar because passkeys are built on the same PKI (public-key infrastructure) that YubiKeys used since 2018. YubiKeys can currently store up to 25 different passkeys, though Yubico intends to expand this as the market for passwordless implementation grows.

They're different because YubiKey passkeys and standard passkeys follow different rules for cross-device duplication. Passkeys on most devices can be copied using the associated cloud account's credentials. Passkeys on YubiKeys are bound to the device and can't be copied.

Here's a breakdown of how YubiKeys and passkeys compare with one another:

	YubiKey passkey	Standard passkey
Storage	Device-bound in the YubiKey's hardware, making them impossible to copy.	Stored on cloud services and within each associated device's TPM (Trusted Platform Module), a dedicated component for protecting authentication secrets.
Portability	Tied to the physical device, supporting possession-based 2FA by requiring the key's presence.	Can be synced across trusted devices, offering more convenience but potentially increasing the attack surface.
Security	Designed with hardware-level protection against extraction or duplication.	Rely on the security of the device or cloud service provider.

YubiKey vs. authenticator app

Both YubiKeys and authenticator apps (Google Authenticator, Authy, etc.) provide two-factor authentication, but they differ in several key ways. Let's start with hardware security.

While modern smartphones contain dedicated TPMs, that doesn't make them impervious to malware or remote attacks. Most cybercriminals won't target an authenticator app, but a phone's operating system is comparatively easy to infect—especially when unassuming users install risky apps and allow unfettered access, options that simply don't exist for YubiKeys.

It's worth noting that most cryptographic operations take place in a Trusted Execution Environment (Android) or Secure Enclave (Apple), a portion of the processor that runs its own operating system. However, an authenticator app's secrets needn't be breached to steal an OTP, and the risk of malware is still present. On the other hand, YubiKeys are built to resist attack and live in isolation from other software.

Next is form factor and dependency. The YubiKey is an unpowered, flash drive-sized device dedicated to authentication, and a smartphone is much larger and requires power to function. An authenticator app can add login friction due to its need for electricity, forcing users with dead phones to find a charger and wait.

Last but not least are the OTPs themselves. While authenticator apps and YubiKeys support time-based (TOTP) and counter-based (HOTP) one-time passcodes, their delivery and security features are completely different. YubiKeys produce 44-character OTPs that require minimal user action. The authentication secrets (seeds) a YubiKey uses to generate OTPs are backed by AES-128 encryption, shielding them from direct attack. Conversely, authenticator apps generate six-digit codes that must be entered manually, allowing a scammer to phish them. The security surrounding underlying authentication secrets can vary, with most relying on a combination of dedicated hardware and operating system-specific key storage.

Below is a breakdown of how YubiKeys and authenticator apps stack up with each other:

	YubiKey	Authenticator app (smartphone)
Security	Isolated from vulnerable operating systems and apps.	Although resilient against direct attack, it exists alongside exploitable software.
Dependency	Compact, never needs to be updated, and doesn't require batteries to operate.	Can be bulky, may require software updates, and needs a charged battery.
Durability	Extremely tough against physical force. Difficult to break or crush, and water-resistant.	Able to withstand minor damage, but still fragile and susceptible to water damage.
One-Time Passcodes	Produce 44-character OTPs backed by 128-bit encryption, and automatically enter codes when prompted.	Generate six-digit passcodes that require manual user entry. Encryption of OTP seeds varies based on OS and device.

How YubiKey authentication works

YubiKey authentication leverages the principle of possession-based, two-factor authentication (2FA). It combines something you have (a YubiKey) with something you know (a PIN or password), or in the case of biometric-enabled YubiKeys, something you are (your fingerprint scan). The YubiKey stores authentication credentials and performs cryptographic operations, never exposing the secret keys. This closed-loop process ensures that even if a user's password is compromised, an attacker can't gain access without physical possession of the key and its associated PIN.

Below, we've outlined the steps required to authenticate using YubiKeys with passkeys.

Passkey authentication with YubiKey

Passkeys use public-key cryptography or PKI (public-key infrastructure) to provide a phishing-resistant authentication process. Here's how it works with a YubiKey:

Initiation: The user starts the authentication ceremony by attempting to log in to an app or service that supports passkey authentication.
Challenge creation: The app generates a cryptographic authentication challenge and sends it to the client (the browser or device).
Challenge transmission: The client passes this challenge to the authenticator (in this case, the YubiKey).
Verification request: The YubiKey requests user verification and presence from the client.
PIN entry or biometric scan: When prompted, the user enters their PIN or scans their fingerprint.
Challenge signing: Upon successful verification, the YubiKey (the authenticator) uses its stored private key to sign the challenge. It then sends the signed challenge to the client.
Response submission: The client provides the app with the signed challenge from the YubiKey.
Verification: The service verifies the signed challenge using the corresponding public key associated with the user's account.
Authentication complete: If the verification is successful, the app confirms the authentication, granting the user access.

OTP authentication with YubiKey

YubiKeys can also authenticate using OTPs (One-Time Passwords/Passcodes), but the process is slightly different. Like all OTPs, YubiKeys generate one-time passcodes based on two elements:

A seed, which is a static secret key shared between the YubiKey and the server.
A moving factor, which can be time-based or counter-based, depending on the OTP type (time-based or counter-based, TOTP or HOTP).

For a more extensive exploration of OTPs check out our guide, OTP Authentication Explained: Definition, Uses & Benefits.

Notably, YubiKey OTPs differ from the standard six-digit codes an authenticator app provides. Instead, they are highly complex, 44-character strings with 128-bit encryption, making them nearly impossible to spoof. Here's how it works:

Initiation: The user attempts to log in to an app or service that supports YubiKey OTP.
OTP generation: When prompted, the user connects their YubiKey and activates it. In most cases, this is simply touching a sensor on the YubiKey. The YubiKey generates a unique OTP based on the seed and moving factor.
OTP submission: The client (browser or app) sends this OTP to the service.
Verification: The service validates the OTP, either using Yubico's validation servers or (in the case of an enterprise setup) the organization's validation server.
Authentication complete: After receiving a successful validation result from Yubico or the private server, the app or service grants the user access.

Common YubiKey use cases

Because YubiKeys support both OTP and passkey authentication, they support use cases across a wide range of industries and activities. Below are just a few examples of how phishing-resistant YubiKeys can uplevel security in various scenarios.

Workforce MFA for remote workers

With remote work becoming increasingly common, organizations can use YubiKeys to ensure secure access to company resources from any location. Remote employees can use YubiKeys for stronger authentication, logging in to corporate networks, cloud services, and sensitive applications. Companies with older, legacy frameworks can opt for OTP-based authentication, while more modern systems can benefit from passkey-enabled passwordless login.

Upgrading individual security

Some individuals prefer YubiKeys when logging in to consumer applications, and offering YubiKey support on your app or service can help satisfy these security-conscious customers. Because one YubiKey supports up to 25 different passkeys, these users can benefit from possession-based security across multiple services without adding another link to their real-world keychain. Even if your app isn't ready to support passkeys, you can still work with YubiKeys using OTPs.

Government officials and sensitive industries

YubiKeys can be pivotal in high-security scenarios where protecting privileged data is an operational requirement. Government agencies, defense contractors, and critical infrastructure operators use YubiKeys to secure classified information and sensitive systems. In environments where regulatory compliance demands traditional smart card functionality, YubiKeys can double as a digital and physical access device.

YubiKey benefits

While YubiKeys are certainly multi-faceted security devices, we've distilled their key benefits into three concise categories: security, user experience, and reliability.

Enhanced security

YubiKeys offer robust, resilient protection against numerous cyber threats. They provide phishing-resistant authentication through hardware-bound passkeys, significantly reducing the risk of ATO (account takeover). Unlike smartphones or traditional OTP methods, YubiKeys require physical presence for authentication, effectively eliminating risks associated with remote attacks and credential theft. In short, YubiKeys can't be duplicated, hijacked, monitored, or interfered with. Case in point: Cloudflare stopped a 2022 SMS phishing attack targeting its workforce using FIDO2-compliant Yubikeys.

Improved user experience

While they may appear more cumbersome, YubiKeys can quickly surpass a smartphone's speed and accessibility. Authentication with a YubiKey is often as simple as inserting the key and tapping it or using NFC, then entering a short PIN. This is typically faster and more convenient than a long, hard-to-remember password, and it's much speedier and more secure than manually submitting an OTP. Additionally, YubiKeys don't require a power adapter, their form factor can be extremely compact, and they don't require constant software updates.

Reliability and durability

YubiKeys are designed to withstand much more than daily wear and tear, offering greater protection compared to smartphones. They're resistant to water and crushing, and they have no moving parts or battery to short-circuit. YubiKeys' physical ruggedness makes them ideally suited for a wide range of environments, from field operations to heavy industry. Because of their long lifespan, YubiKeys are a highly cost-effective alternative to issuing company smartphones and are much more secure than a BYOD (Bring Your Own Device) policy.

Easily support YubiKey authentication with Descope

YubiKeys offer a powerful solution for reinforcing authentication security across countless industries and use cases. They're physically tough, phishing-resistant, and built on dedicated hardware proven to defend against cyber threats. With strong authentication options for both passkeys and OTPs, YubiKeys address many of the security obstacles organizations and individuals face daily.

While YubiKey authentication can significantly boost your security posture, integrating it with your systems, service, or app can be difficult and complex. At Descope, we make development easier regardless of the authentication method. Adding passkeys with Descope Flows is as easy as selecting an authentication type, picking a login screen, and deploying.

Descope's flexible platform empowers developers to quickly and effortlessly implement YubiKey authentication, combining the security benefits of possession-based authentication with the accessibility of our drag-and-drop interface.

To get started integrating YubiKeys with passkeys or OTPs using Descope, sign up for our "Free Forever" plan today. Have questions? We're waiting to connect with you at AuthTown, our open developer community.

Next.js vs Remix: What's the Difference?

Mrunank Pawar — Thu, 14 May 2026 15:00:00 +0000

This blog was originally published on Descope.

Anyone who's worked with React knows it's easy to get started with, and you can quickly become quite productive. However, once you move beyond the basics and need full-stack capabilities, like server-side rendering (SSR), selecting a React framework becomes the next step. Two of the most popular frameworks are Next.js and Remix. Both provide powerful tools to build high-performance web applications, but their philosophies and approaches differ.

This article compares Next.js and Remix, helping you get to know both frameworks, including their key concepts, features, architecture, performance capabilities, learning curves, and use cases. By the end, you'll have a solid understanding of how these frameworks stack up against each other and, hopefully, a firm base for choosing the right framework for your specific needs and ways of solving problems.

This comparison reflects the state of Next.js at version 14 and Remix at version 2.

Next.js overview

Next.js was developed by Vercel and was launched in 2016. It has since become one of the most widely used frameworks in the React ecosystem. Next.js is known for its flexibility and extensive feature set. It's built to solve the complexities of SSR and static site generation (SSG), as well as easily handle routing, expose API endpoints, and optimize performance for the end user.

Here are some key features of Next.js:

File-based routing automatically generates routes based on the filesystem structure.
SSR and SSG support gives developers flexibility in choosing between static and dynamic rendering methods.
API routes, which are built-in API endpoints that don't need a separate backend server.
Incremental Static Regeneration (ISR) enables static content updates without rebuilding the entire site.
Edge rendering support allows for even faster responses.

Large companies frequently use Next.js for e-commerce, content-heavy websites, and sometimes enterprise-grade applications. Notable users include Twitch, Hulu, TikTok, Spotify, and Sonos.

Remix overview

Remix was developed by the creators of React Router and was released in 2021. It's built on top of the React Router. The framework is a newer entry to the React ecosystem. It focuses on web standards, performance, and a full-stack data flow, giving the developer a very high level of control. While Remix also supports SSR, it takes a different approach from Next.js, prioritizing progressive enhancement and fine-grained control over data loading and mutations.

Remix offers the following key features:

Loader and action functions efficiently handle server-side data fetching and mutations, avoiding unnecessary JavaScript on the client.
Nested routes are optimized for both layout and data loading, making it easy to build complex user interfaces.
Streaming support enables fast content delivery through streaming HTML directly to the browser.
Web standards focus means Remix emphasizes built-in browser APIs over proprietary abstractions.

Remix is ideal for projects where you want to squeeze out the maximum possible performance from your server-side React solution and want to have a very high level of control in your React application. Some companies that have adopted Remix include ChatGPT, Shopify Hydrogen, and Docker Scout.

Next.js core concepts

At its core, Next.js is designed to simplify SSR and SSG through a file-based routing system. The framework allows developers to build pages by creating files in the app directory. Placing a page.ts|js file in a folder named about enables the Next.js app to show a page when you navigate to the /about URL. This routing method allows you to easily view the project's file structure to see which pages and APIs are routed within the app. It's a straightforward approach that feels familiar to React developers.

Pre-rendering is one of the standout Next.js features, giving developers a choice between SSG, which generates HTML at build time, and SSR, which renders HTML on each request. With ISR, Next.js can also regenerate specific pages after a certain interval, allowing static pages to be updated, behind the scenes, without a full rebuild.

Remix core concepts

Remix uses file-based routing as its conventional route configuration. But Remix also allows manual route configuration for scenarios that the file-based routing isn't flexible enough to cover. On top of this, Remix has a nested routing architecture, which enables seamless data fetching and UI composition.

The framework introduces loader and action functions for each route, where loaders handle data fetching and actions manage form submissions and mutations. This approach decouples the frontend and backend logic, ensuring that the right data is always available without duplicating code across the stack.

Remix excels in delivering optimized and performant user experiences, particularly through its streaming capabilities, which allow pages to load incrementally as data becomes available, significantly improving perceived performance for users.

Boilerplate Next.js

To get started with Next.js, all you have to do is run npx create-next-app@latest and answer some configuration questions for your setup.

The layout file, which defines the shared layout and content for your entire website, is located at /app/layout.tsx. In its simplest form, it looks like this:

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

In this file, the standard React children prop is used to define where the page content will be rendered within the layout. To display a page, you need to add a file at /app/page.tsx with the following content:

export default function Page() {
  return <div>This is the page content</div>
}

Following the routing convention in Next.js, if you want an about page on your website under the URL https://example.com/about, you need to add a page file under /app/about/page.tsx.

Boilerplate Remix

To get started with Remix, simply run npx create-remix@latest to set up a new app.

This generates several files, including /app/root.tsx, which serves as the site's layout:

export function Layout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

export default function App() {
  return <Outlet />;
}

Unlike Next.js, it uses an explicit export to follow React standards rather than relying on conventions.

The root page route is located at /app/routes/_index.tsx and contains the following:

export default function Index() {
  return <div>This is the page content</div>
}

To add an about page in Remix, you add a new file under the path /app/routes/about.tsx.

As you can see, the basic functionality is very similar across the frameworks. It's when you get into more detailed functionality that they start diverging.

Next.js performance features

Next.js offers a range of performance optimization features that are intended to help the developer get a high level of performance by default. The features include SSG, SSR, and ISR, which provide flexibility in how content is rendered. SSG lets you pre-render the whole site into a static web application, resulting in faster loading times. SSR allows custom content to be dynamically served from the server, which provides a seamless experience when navigating the site quickly as a user. This is the same functionality that ensures that search engines get the expected content directly for good search engine optimization (SEO). ISR enables cached content to be served instantly while simultaneously being updated in the background for the following users.

Its image optimization feature automatically adjusts images for the device and screen size, improving load times. Additionally, automatic code-splitting and script optimization make sure that only the necessary JavaScript is loaded on the page.

Edge rendering was also introduced a few versions back as an experimental feature in version 12.2. This allows specific (or all) pages or API routes to be served from geographically distributed edge locations closer to the end user. This also further boosts speed and reduces latency.

From a developer experience perspective, it's worth noting that Next.js was built using webpack for bundling, which has struggled to maintain performance. Therefore, when changing something in the code, reload times can be very slow. For this reason, the Next.js team has been working on getting full compatibility on its own bundler, Turbopack. As of Next.js 14, Turbopack is still considered beta but is much faster than the default experience with webpack.

Remix performance features

Remix is focused on data efficiency and page load speed. The use of loader functions helps to load only the data required for a specific page or API endpoint. This ensures that the data is fetched server-side and eliminates the need for client-side fetching once the page has been rendered. Remix also offers streaming HTML, meaning users can start interacting with content while individual parts of the page continue loading as fast as possible in the background.

Remix avoids client-side JavaScript for form submissions, relying instead on server-side logic. This reduces the overall JavaScript bundle size and improves performance. It also means that the basic functionality of posting a form, with fields and a submit button, can even work on a browser with JavaScript disabled.

Remix also supports serving content from the edge. Since the Remix documentation site is hosted on Fly.io, it achieves time to first byte (TTFB) under one hundred milliseconds, and updates to the site take only a couple of minutes.

Remix supports the bundler Vite, which gives a remarkably fast developer experience. Remix reported that its Hot Module Replacement (HMR) became ten times faster using Vite, for example. Vite will become the default compiler of Remix in the future.

Next.js learning curve

Next.js provides a fairly gentle learning curve, especially for developers already familiar with React. The Next.js teams make it a point to be transparent in that they try to work closely with the React team.

Starting a project with create-next-app is straightforward, and the framework's file-based routing system feels intuitive to most. Simply run npx create-next-app@latest and follow the wizard to have a working project up in no time.

With extensive documentation and a large community, developers have plenty of resources to get started quickly. However, advanced features like ISR and edge rendering can introduce complexity.

Next.js aims to provide good defaults for most choices—such as routing, SSR, data fetching, CSS handling, and much more—that have to be made when starting a project in just vanilla React. However, it has a history of changing defaults, and the community has expressed some frustration—particularly on Reddit—about more fine-grained feature control being unintuitive or even impossible.

Remix learning curve

Remix architecture requires developers to learn new patterns, particularly involving nested routing and loader/action functions.

Remix also has an intuitive CLI called create-remix that allows you to quickly create a new Remix app. You simply run npx create-remix@latest to get started.

Unlike typical React applications that rely heavily on client-side JavaScript to handle forms and data mutations, Remix uses its routing and loader/action functions to handle as much as possible on the server side. While this approach can result in more efficient apps, it introduces a steeper learning curve.

Given that Remix is a newer framework, it has a smaller community and newer documentation, resulting in fewer resources online for learning Remix compared to Next.js.

Next.js ecosystem

Next.js is developed by Vercel, which also provides deployment and hosting for multiple JavaScript frameworks. Given that Next.js is one of Vercel's main frameworks, it's no surprise that the Next.js experience on Vercel is seamless and easy. Vercel detects that the repository contains a Next.js app. Then Vercel takes care of all configurations for the deployment and makes sure the app just works and is available on the internet.

The framework has strong support for integrations with content management systems (CMS), headless e-commerce, and popular third-party services. The wide range of Next.js libraries means you can easily extend its functionality. There is also a whole Vercel Marketplace for integrations.

Remix ecosystem

Remix takes a more minimalist approach, emphasizing web fundamentals over proprietary tools. It encourages using built-in browser APIs and traditional React libraries, allowing developers to build apps without needing Remix-specific integrations. This means that anyone who builds libraries or parts of their solution in plain React can easily plug it into Remix, without worrying about framework-specific quirks or special considerations based on where the Remix application is hosted.

Although the Remix ecosystem is smaller, its focus on standard web technologies ensures long-term compatibility and flexibility as the ecosystem grows. Remix relies on the community to build the resources in the ecosystem over time.

Use cases

As mentioned, Next.js is used by many large organizations, such as Twitch, Hulu, TikTok, Spotify, and Sonos. It handles everything from marketing sites to large, composable commerce platforms for e-commerce and even web applications running server-side functionality, single-page application (SPA) functionality, or a combination of both. It's a good fit for projects that require scalability, SEO optimization, and real-time content updates with ISR.

Remix also has some strong brands using its framework, such as Shopify, Docker, and even the NASA General Coordinates Network (GCN) site. The Remix framework really shines in scenarios where performance and the following fast user experience are critical. Its approach to data loading and form handling is especially useful for projects that need fast, interactive user interfaces and seamless transitions. Similar to Next.js, it also supports a mix of server-side and SPA functionality, as well as robust SEO optimization.

Choosing the right framework

There are many things to consider when deciding whether you should use Next.js or Remix for your project. As is often the case with technology comparisons, there is no clear winner. The decision depends on your specific scenario and needs.

Next.js strengths

Comprehensive feature set includes file-based routing, rendering on both server and client-side, data fetching, and TypeScript support built-in.
Lots of performance features out of the box includes optimizations of images, fonts, bundles, and lazy loading.
Large community and ecosystem with extensive libraries, integrations, and resources available for developers.

Next.js weaknesses

Complexity: Next.js offers many advanced features related to updating data displayed in its apps, like ISR, data revalidation, and automatic caching on data fetching. However, understanding and using these features may require significant time and effort. For example, implementing ISR effectively can be difficult for dynamic content-heavy sites.
Performance in larger applications: As the amount of data and number of pages in your solution grow, so do the build time and performance requirements for hosting. Prebuilding many pages takes more build time. If you revalidate a lot of data on a lot of pages, this requires significant resources on your server, potentially driving up costs.

Remix strengths

Performance-focused: Fine-tuned control over data loading and streaming improves both speed and user experience.
Simplified form handling: Built-in form submissions without JavaScript reduce the need for complex state management and unnecessary client-side scripts.

Remix weaknesses

Smaller ecosystem: Remix has fewer integrations and community resources compared to Next.js.
Steeper learning curve: Developers familiar with standard React patterns may find the unique architecture of Remix harder to grasp initially.

Other considerations

There are some more points to take into consideration for an informed decision on which framework to choose. These points relate more to the long-term success of a project than the previously mentioned strengths and weaknesses, which are more related to how quickly you can pick up the framework and be productive.

SEO is critical for the organic growth and spread of any public website today. When it comes to SEO, both frameworks support robust SEO by allowing you to set metadata related to SEO and render the pages' content server-side. This means that Google and other search engines get the pages' full content and don't have to wait for content to appear step-by-step, which is usually the experience in an SPA.

Performance is an important factor to SEO since Google, and other search engines, use how fast a site shows its pages as a factor to score the website. When it comes to this topic, Next.js probably has a slight edge with SSG and ISR, which allow fast delivery and timely updates of heavily cached content.

For complex routing scenarios, Remix has an edge over Next.js, given that Remix has file-based routing, which is very similar to Next.js. Remix also supports manual route configurations to cover more complex scenarios.

Comparison overview

For an overview of the comparison between the frameworks, we can look at the features in table format. This shows that there are only slight differences between these two very competent frameworks.

	Next.js	Remix
Performance	⭐⭐	⭐⭐⭐
Power of routing	⭐⭐	⭐⭐⭐
Size of ecosystem	⭐⭐⭐	⭐⭐
Ease of learning	⭐⭐⭐	⭐⭐
SEO	⭐⭐⭐	⭐⭐⭐

One of the most important factors to consider when choosing any technology is the skill level and experience of your team relative to the complexity and learning curve of the tool. In this case, it's important to gauge what your team's prior experience of SSR is of React components, which type of routing they've used previously if they're used to working with web standards, and how much they've kept up with the bleeding-edge features of modern versions of React.

If your team's experience with SSR is limited, then both frameworks will require a shift in mindset. If they're used to the React Router, then the Remix routing approach might be more intuitive. If they've been keeping up with the latest patterns, such as React.Suspense, then the patterns in Next.js might be more intuitive.

Conclusion

This article explored the core features, performance features, learning curves, and use cases for both Next.js and Remix. While Next.js provides a robust and flexible toolkit for developers to get started quickly, Remix offers a performance-first approach with a unique take on routing and data management. The decision between the two frameworks ultimately depends on the needs of your project and the skills and experience of your development team.

No matter which framework you choose, any modern web application needs to give the user a unique experience based on who they are. This can be a complex and quite time-consuming problem to handle on your own.

Descope is a service that offers a unique solution through its no-code/low-code visual workflows, allowing developers to quickly create and customize authentication flows without writing extensive code or disrupting the app's architecture. With a strong focus on passwordless authentication—including methods like magic links, one-time passwords (OTPs), and passkeys—Descope not only simplifies the implementation of secure user management but also enhances user experience. Check out our Next.js and Remix resources to get started.

For more framework comparisons and authentication trends, subscribe to our blog or follow us on LinkedIn and Bluesky.

How to Add Authentication in Flask

Mrunank Pawar — Tue, 12 May 2026 14:52:03 +0000

This blog was originally published on Descope.

Adding authentication in Flask is a key step in building secure web apps that users can trust. In this hands-on tutorial, you'll see how to create a complete Flask authentication flow using Python and simple HTML templates. We'll walk through signup, login, logout, and profile features with clear examples that you can use in your own projects. Whether you're just getting started with Flask or want to level up your app's security, this guide will help you build a solid foundation for user authentication.

Prerequisites and setup

Before diving into Flask authentication, make sure you have the basics ready. All the code for this tutorial is available in our GitHub repository, with installation instructions in the README.

If you're new to Flask or Descope, no problem. You can follow along as you build authentication in Flask from scratch. To get started, sign up for a free account on Descope. You may also want to check out the Descope Get Started docs and Flask Quick Start guide for additional background.

How Flask authentication works in this example

In this tutorial, we'll build authentication in Flask using Descope for handling user sessions. The app will let users sign up, sign in, log out, and view a profile page. We'll manage authentication in Flask by combining Python, HTML templates, and a simple decorator that protects routes from unauthorized access.

You'll see how to set up the Descope SDK, refresh and validate session tokens, and connect your Flask routes with secure authorization logic. Let's start by creating the Flask app and building the authentication decorator.

Step 1: Create the Flask app and auth decorator

To manage authentication in Flask, we'll create an authentication decorator that protects sensitive routes. This decorator checks for a valid session token and ensures only authorized users can access certain endpoints.

Here's how we define the token_required decorator in our Flask app:

def token_required(f): # auth decorator
   @wraps(f)
   def decorator(*args, **kwargs):
       session_token = None


       if 'Authorization' in request.headers: # check if token in request
           auth_request = request.headers['Authorization']
           session_token = auth_request.replace('Bearer ', '')
       if not session_token: # throw error
           return make_response(jsonify({"error": "❌ invalid session token!"}), 401)


       try: # validate token
           jwt_response = descope_client.validate_session(session_token=session_token)
       except:
           return make_response(jsonify({"error": "❌ invalid session token!"}), 401)


       return f(jwt_response, *args, **kwargs)

   return decorator

Code snippet: app.py file, token_required decorator

This is the foundation of our Flask authentication logic. It checks for an authorization header, validates the session token using Descope, and either allows or blocks access.

Step 2: Build the HTML templates

Our Flask authentication app uses simple HTML templates for the user interface. These templates handle login, profile display, and navigation.

Start with a base HTML file that loads the Descope SDK. This makes Descope authentication features available across all pages.

<!DOCTYPE html>
<html lang="en">
<head>
   <meta charset="UTF-8">
   <title>{% block title %} {% endblock %}</title>
   <script src="https://unpkg.com/@descope/web-component@latest/dist/index.js"></script>
   <script src="https://unpkg.com/@descope/web-js-sdk@latest/dist/index.umd.js"></script>

Code snippet: base.html file head

This base template provides a clean starting point for building the authentication pages in Flask. You'll extend this file for login, profile, and other views.

Step 3: Add Descope authentication logic

Now let's add the authentication logic in Flask that connects our HTML templates to Descope. First, we create a descope.js file to define global variables and initialize the Descope SDK.

const projectId = ""
const sdk = Descope({ projectId: projectId, persistTokens: true, autoRefresh: true })
const sessionToken = sdk.getSessionToken()

Code snippet: descope.js file

These variables make it easy to manage authentication in Flask:

projectId links to your Descope project.
sdk initializes Descope and manages tokens.
sessionToken stores the user's session token.

We'll use these in the login, profile, and other pages to check authentication status and control access.

Step 4: Protect routes with the auth decorator

Once your token_required decorator is in place, you can use it to secure any Flask route that requires authentication. This helps prevent unauthorized access to sensitive parts of your app.

For example, here's how we protect the /get_secret_message endpoint:

@app.route('/get_secret_message', methods=["GET"])
@token_required
def get_secret_message(jwt_response):
   print(jwt_response)
   return {"secret_msg": "This is the secret message. Congrats!"}

Code snippet: app.py file, get_secret_message endpoint

When a request hits this route, the authentication decorator checks the session token first. If the token is valid, the route logic runs. If not, the user gets a 401 error.

Step 5: Log in with Descope in HTML

The login logic can be found in the login.html file. We import descope.js so we can access the global variables that help manage Flask authentication.

{% extends 'base.html' %}
{% block content %}
<h1 class="title">{% block title %} Login {% endblock %}</h1>
<div id="container"></div>
<script src="{{url_for('static', filename='descope.js')}}"></script>
<script>
  sdk.refresh()
  const container = document.getElementById('container')
  if (!sessionToken) {
    container.innerHTML = '<descope-wc project-id="' + projectId + '" flow-id="sign-up-or-in"></descope-wc>'
    const wcElement = document.getElementsByTagName('descope-wc')[0]
    const onSuccess = (e) => {
      sdk.refresh()
      window.location.href = "/profile"
    }
    const onError = (err) => console.log(err);
    wcElement.addEventListener('success', onSuccess)
    wcElement.addEventListener('error', onError)
  } else {
    window.location.href = "/profile"
  }
</script>
{% endblock %}

Here's how the profile logic works:

<script src="{{url_for('static', filename='descope.js')}}"></script>
<script>
  sdk.refresh()
  const userName = document.getElementById('userName')
  const userEmail = document.getElementById('userEmail')
  const secretMsg = document.getElementById('secretMsg')
  const profileContainer = document.getElementById('profile')

  function getProfileData(){
    fetch('/get_secret_message', { // call the api endpoint from the flask server
      headers: {
        Accept: 'application/json',
        Authorization: 'Bearer ' + sessionToken,
      }
    }).then(data => {
      if (data.status === 401) { // error
        window.location.href = '/login'
      }
      return data.json()
    }).then(jsonData => {
      console.log(jsonData)
      secretMsg.innerHTML = jsonData.secret_msg
    }).catch((err) => {
      console.log(err) // error
      window.location.href = '/login'
    })
  }

  async function setNameEmail() {
    const profile = await sdk.me()
    userName.innerHTML = profile.data.name
    userEmail.innerHTML = profile.data.email
  }

  if (sessionToken) {
    getProfileData();
    setNameEmail()
  } else {
    window.location.href = "/login"
  }

  async function logout() {
    await sdk.logout()
    window.location.href = "/login"
  }
</script>

Code snippet: profile.html file scripts

There are three key takeaways from the JavaScript code:

At the top of every HTML page, we call sdk.refresh() to jumpstart the autorefresh process and use the refresh token to get a new valid session token.
The if statement checks if the session token is invalid and displays the Descope login widget. If the session token is valid, the user is redirected to the profile page.
The onSuccess arrow function captures the login event, calls sdk.refresh() to start the autorefresh process, and redirects the user to the profile page, where we validate the session token.

Let's see how we display our profile information in the profile.html file.

Step 6: Display the profile page

After logging in, users can access the profile page. This page displays user details and a secret message retrieved securely through authentication in Flask.

       async function logout() {
           await sdk.logout()
           window.location.href = "/login"
       }
   </script>

Code snippet: profile.html file scripts

This ensures the user session ends cleanly. You can connect this function to a logout button in your profile template. Logging out removes the session token, preventing unauthorized access if someone tries to revisit a protected page.

Notice how sdk.refresh() is called at the top of the script. This jumpstarts the auto-refresh process, using the refresh token to get a new valid session token.

Step 7: Run and test Flask authentication in your app

With all the pieces in place, you can run your Flask app and test the authentication flow. Start your server and visit the home page.

After login, users are redirected to the profile page where their name, email, and secret message appear.

The profile page showcases our name, email, logout button, and a link back to the home page. The logout button ends the session and returns users to the login screen.

Flask authentication in action

This example shows how authentication in Flask can be simple and secure using Python, HTML, and Descope.

With just Python, HTML, and Descope, you've created a working Flask authentication system that handles signup, login, logout, and profile access. This simple approach to authentication in Flask helps you build secure apps without adding unnecessary complexity.

If you're ready to explore more or want to scale your Flask authentication setup, sign up for Descope or book a demo with our auth experts to learn more.

Does Flask use JWT?

Flask itself doesn't use JWTs (JSON Web Tokens) by default. It's a lightweight web framework that lets you choose how to handle authentication and session management. If you want to use JWTs in Flask, you can easily integrate it with libraries like PyJWT, Flask-JWT-Extended, or third-party services like Descope.

In this tutorial, we showed how to handle authentication in Flask using Descope, which manages session tokens (including JWTs) for you securely behind the scenes.

Is Flask authentication secure?

Flask authentication can be very secure, but it depends on how you implement it. Since Flask is a flexible framework, you're responsible for choosing secure methods for handling login, tokens, and session management.

In this tutorial, we showed how to add authentication in Flask using Descope, which helps you securely manage tokens and user sessions. If you follow best practices like protecting routes, validating tokens, and using HTTPS, Flask apps can provide strong authentication for your users.

Is Flask as secure as Django?

Flask and Django can both be secure, but they take different approaches. Django comes with more built-in security features like CSRF protection, form validation, and user authentication out of the box. Flask is more lightweight and gives you the flexibility to choose and implement your own security tools.

This means Flask can be just as secure as Django if you follow best practices.

Build Secure Multi-Agent Systems With CrewAI and Descope

Mrunank Pawar — Wed, 06 May 2026 15:00:00 +0000

This blog was originally published on Descope.

A single AI agent can summarize, analyze, or plan, but it struggles to scale across domains, maintain context, or specialize deeply enough for complex enterprise use cases. Multi-agent systems address these gaps by distributing responsibility across many specialized agents. Instead of asking one model to do everything, individual agents receive a defined role and scope. Each agent executes its part before results are stitched together. This avoids overload, reduces errors, and produces better outcomes than a single agent working alone.

Case in point: The CrewAI multi-agent platform structures multi-agent systems much like real-world teams. This design keeps workflows clear, predictable, and scalable while exposing the practical challenge of managing identity and access. But once you've got agents interacting, you need to think about safe and reliable orchestration: authentication, identity, permissions, and secure communication.

Enter the Descope Agentic Identity Hub, which helps you manage identity and access control for all agents in such a multi-agent system. Each agent can be managed and assigned the relevant permissions to perform exactly the tasks they are designed for and nothing more. Let's put this in practice!

Implementing Descope for a CrewAI Application

To make this concrete, there's a working example that ties everything together. You can follow the steps in this tutorial, or check out the finished sample app to see the complete implementation in action.

Here's what we'll be implementing:

A CrewAI crew with two different agents corresponding to two independent tasks: Calendar and Contacts
Descope Outbound apps for each API with defined OAuth scopes. Each agent will have its own scope and will only be able to perform actions based on these scopes.
User consent flows for granular permissioning
Backend session validation and secure token exchange
A unified output from the crew that combines results from both agents

Watch the video below or carry on reading!

Prerequisites

You'll need the following tools:

A Descope account: If you don't already have one, you can sign up for a Free Forever account.
Google Cloud APIs: Calendar and People/Contacts APIs
CrewAI: Python framework for multi-agent workflows
Python HTTP library: For API requests (requests, http, etc.)
A simple React frontend to connect the backend to

Configure Google OAuth credentials

For using google contact and calendar APIs, you need to set up google OAuth credentials.

Create OAuth credentials in the Google Cloud Console for the APIs your agents will access.
Go to your Google Cloud Console > APIs & Services > Credentials.
Create a new OAuth Client ID for each service: one for Calendar, one for Contacts.
Copy the Client ID and Client Secret for each app.
Add Authorized redirect URIs pointing back to your Descope Outbound app configuration.

Add Outbound Apps in Descope

Next, configure the outbound apps inside Descope so that each agent can request access tokens for its task. In the Descope Console, go to Outbound Apps.

Add Google Calendar and Google Contacts as new apps.
Paste the Client ID and Client Secret from Google for each app.
Set the redirect URIs to match the Google configuration.

The Descope docs provide more detailed instructions on how to set up outbound applications. While setting up outbound applications, pay attention to scopes. Scopes determine exactly what each agent can access. Configuring scopes in Descope rather than in code makes it easy to audit and update them later.

For this tutorial, we need two sets of scopes:

Calendar app: https://www.googleapis.com/auth/calendar.readonly and https://www.googleapis.com/auth/calendar (so the calendar agent can read existing events and create new ones)

Contacts app: https://www.googleapis.com/auth/contacts.readonly (so the contacts agent can look up user contacts but not modify them)

Keeping scopes granular ensures each task is limited to its responsibilities and prevents over-permissioning.

Configure Descope Inbound Application

Configure an Inbound App in your Descope console. The inbound app protects the front end and also uses the consent flow so that the user can grant consent. The token granted by inbound applications is used by the application backend to securely exchange and fetch outbound app tokens:

Descope already has a template flow that can be used for inbound applications. Start with that and customize as follows:

Insert a consent screen showing requested scopes for Calendar and Contacts.
Consent is stored for auditability and future requests.
Add two Outbound App Connection actions, one for each app. These are required to connect google calendar and contacts during the user login process.

Frontend authentication

When a user signs in through the inbound app, they're guided through the customized Descope Flow. This flow not only authenticates the user but also presents a consent screen showing the requested Google Calendar and Contacts scopes. Once the user approves, Descope connects the outbound apps behind the scenes, tying the user's identity to the exact API permissions required.

The result is a session token returned to the frontend. This token represents a verified user identity and their granted scopes. Every request from the frontend to the backend should include this session token, ensuring that the backend can validate the user and securely exchange it for outbound access tokens later.

Configure CrewAI tasks

With authentication and token management in place, the CrewAI application can now operate as a coordinated multi-agent system. In this setup, we've defined a crew that manages two independent agents, each with a distinct role and scope.

The Calendar Task is handled by the calendar_manager agent, which uses the Google Calendar access token to read or create events. This agent specializes in interpreting user intent around time and scheduling, ensuring that calendar operations are executed precisely.

The Contacts Task is handled by the contacts_finder agent, which uses the Google Contacts access token to search and retrieve detailed contact information. This agent is optimized for matching names, emails, or partial queries, and always returns structured, well-formatted results.

Each task runs in isolation, bound by the specific OAuth scopes granted through Descope. This means the calendar agent cannot access contacts, and the contacts agent cannot alter calendar events. The crew oversees the process, coordinating the agents' outputs and merging them into a unified result for the user.

Backend session validation

On the backend, validate the Descope session token using the Descope SDK. Verify the token and extract the trusted userId and session information. Only validated sessions can request Outbound App access tokens.

def validate_session(session_token):
    try:
        jwt_response = descope_client.validate_session(session_token=session_token, audience=os.getenv("VITE_CLIENT_ID"))
        print("Successfully validated user session:")
        print(jwt_response)
        return jwt_response
    except Exception as error:
        print("Could not validate user session. Error:")
        print(error)
        return None

Exchange session for access tokens

Once the session is validated, the backend exchanges it for scoped tokens for each Outbound App:

Calendar access token scoped to Calendar app permissions.
Contacts access token scoped to Contacts app permissions.

Descope handles OAuth flows and refresh logic, so the backend receives short-lived, scoped tokens without needing to store refresh tokens directly.

def get_outbound_token(app_id, user_id, session_token):
    """Fetch Google Calendar access token from Descope outbound token API."""
    project_id = os.getenv("VITE_DESCOPE_PROJECT_ID")
    management_key = os.getenv("DESCOPE_MANAGEMENT_KEY")
    url = "https://api.descope.com/v1/mgmt/outbound/app/user/token/latest"

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {project_id}:{session_token}",
    }
    payload = {
        "appId": app_id,
        "userId": user_id,
    }

    response = requests.post(url, headers=headers, json=payload)
    if response.status_code != 200:
        raise Exception(f"Failed to fetch token: {response.status_code} {response.text}")

    data = response.json()
    token_data = data["token"]
    access_token = token_data.get("accessToken")
    return access_token

Orchestrating agent security with Descope

With this setup, you have a secure, multi-agent CrewAI workflow. Each agent operates with least-privilege access, user consent is auditable, and the crew manager produces a unified output efficiently. To explore further or start experimenting right away, the sample app repo contains the complete codebase and configuration.

From here, you can start applying the same pattern to real use cases—for example, a sales workflow where one agent books meetings on Google Calendar while another enriches leads from your CRM, or a support workflow where an agent pulls customer details and another schedules follow-ups automatically. You might also explore adding new agents tied to other APIs, integrating project management or finance systems, or experimenting with CrewAI's orchestration features for more complex collaborations.

In short, this foundation gives you a practical way to scale multi-agent systems securely, while Descope handles the identity and access challenges behind the scenes.

Secure API Calling With Custom GPTs and Descope

Mrunank Pawar — Mon, 04 May 2026 15:00:00 +0000

This blog was originally published on Descope.

OpenAI's Custom GPTs offer a powerful way to create AI agents that can interact directly with your APIs through natural language conversations. Imagine you have a deployed FastAPI application that implements DevOps tools such as triggering CI/CD workflows, getting deployment logs, usage analytics, and other operational tasks. While integrating your API with an LLM sounds like a perfect task for a Model Context Protocol (MCP) server, MCP servers can be complex to implement and maintain, often posing security challenges that necessitate external middleware. Even FastAPI MCP wrappers introduce routing changes, CORS policies, and deployment overhead that quickly becomes its own project.

With Descope Inbound Apps, you're given a much simpler approach to establishing an OAuth compliant connection between your API and a custom GPT. In this article, we'll walk you through:

Securing your FastAPI backend with Descope JWT validation
Configuring a custom GPT to authenticate and interact with your protected APIs using scope-based authorization
Setting up your FastAPI application to act as a proxy for the Inbound App, so you maintain the authorization and the resource server under the same domain.

What you will build: a secure GPT assistant

By the end of this article, you will have a custom GPT that can securely interact with your prebuilt FastAPI endpoints through natural language conversations. The first time you submit a prompt in the current chat, you will be asked to authenticate and taken through the Descope inbound apps user consent flow. Note that if you configure a custom domain for your Descope project, your Descope-powered authorization server would run on your own custom domain, eliminating the need for this proxy setup. However, for this example, we will implement the proxy approach to understand the OAuth flow mechanics and provide an immediate out-of-the-box solution.

Once you are authenticated, you will be brought to the consent screen, which will display a list of scopes that you can consent to.

After you give consent, you will be seamlessly redirected back to your chat along with access and refresh tokens, which will be used when you call your API routes. The GPT will then ask for authorization to interface with the specific tool(s) which will be called to answer your prompt. Select Allow or Allow Always based on your personal preference.

When you make a request, your custom GPT sends it directly to your API with the access and refresh tokens it has. Your backend server then performs the scope validation and responds accordingly: if the token is invalid or expired, you'll get a 401 Unauthorized error; if the token is valid but lacks the necessary scopes for that specific endpoint, you'll receive a 403 Forbidden error. This approach keeps all the authorization decisions on the server side. In either case, the GPT will explain in natural language which error occurred when trying to generate a response. After you complete authentication and authorization, OpenAI will automatically manage your session. You can view and manually manage the connection and authorization status under Privacy Settings, which you can find in the drop-down menu next to the name of your GPT in the top left corner.

You can continue to submit prompts without reauthenticating until the authorization token issued to you by the Inbound App expires. The default session timeout is set to 10 minutes, but you can learn to adjust this later in the article.

Prerequisites

To complete the tutorial, you will need the following:

Python installed
A deployed FastAPI application; you can find a sample starter app here
ChatGPT Plus account

Setting up a Descope project

To create a new Descope project, sign up or sign in to the Descope console. If you just signed up for a new account, a new Descope project will be automatically created for you and you will find yourself on the Getting Started page of that project. To create a new project, click on your project's name in the top left corner of your Descope console, and select + Project from the dropdown. This is also where you can switch between projects. If you navigate to the Flows section, you will see that a handful of flows have automatically been created for you. Descope Flows are a no-code tool to build user authentication journeys. While you do not need to modify the default flows, you can choose to do so if you want to design a custom user journey.

You can access your project ID at any time by navigating to the Project section of the Descope console. You can copy the project ID from the General tab.

Configuring your application environment

In the root folder of your FastAPI application's project, create a .env file if you do not already have one, and add the following variables:

DESCOPE_PROJECT_ID=<Your Descope project ID> 
DESCOPE_INBOUND_APP_CLIENT_ID=<Inbound App client ID>
DESCOPE_INBOUND_APP_CLIENT_SECRET=<Inbound App client secret>
DESCOPE_API_BASE_URL="https://api.descope.com" # or your custom domain if one is configured in your project settings

Specify your Descope project ID. If you do not know where to find it, reference the previous section of this article. You will fill in the Inbound App client ID and secret later in this article.

Securing your app through token validation

Descope implements its session and refresh tokens as JSON web tokens (JWT). After your Custom GPT obtains a token from your Inbound App through the OAuth flow, your FastAPI backend needs to validate and accept these scoped tokens for authentication and authorization. The advantage of using this OAuth approach with Descope is that you get a complete consent flow and hosted login pages out of the box - no need to build your own authentication UI. You will implement a custom JWT authorizer into your FastAPI app that validates JWTs to make sure its signature is valid, it is not expired, and the audience and issuer claims match the expected resource server. Finally, the authorizer will enforce the scopes embedded in the token to control access to your API endpoints.

First, you will implement a simple exception handler. In your FastAPI application, create a new file and name it exceptions.py. Add these two exception definitions:

from fastapi import HTTPException, status

class UnauthenticatedException(HTTPException):
    def __init__(self):
        super().__init__(status_code=status.HTTP_401_UNAUTHORIZED, detail="Authentication required")

class UnauthorizedException(HTTPException):
    def __init__(self, detail: str = "Not authorized"):
        super().__init__(status_code=status.HTTP_403_FORBIDDEN, detail=detail)

Now let's implement the JWT authorizer. To validate the JWT, you will need to obtain a public key from the Descope JSON web key set (JWKS) endpoint. Your JWKS endpoint will look like this:

https://api.descope.com/<Your Descope Project ID>/.well-known/jwks.json

Create an auth.py file in your FastAPI app and add a TokenVerifier class. This class is used as a FastAPI dependency to validate incoming JWTs and, if requested by a route, enforce OAuth scopes.

At a high level, the TokenVerifier class extracts the bearer token from the authorization header, fetches the public key from your JWKS endpoint, and decodes and validates the JWT. It also uses the SecurityScopes library to validate and enforce the scopes embedded in the token:

from typing import Optional, List
import os
import jwt
from jwt import PyJWKClient
from fastapi import Depends
from fastapi.security import SecurityScopes, HTTPAuthorizationCredentials, HTTPBearer

from app.exceptions import UnauthenticatedException, UnauthorizedException

jwks_url = f"https://api.descope.com/{os.getenv('DESCOPE_PROJECT_ID')}/.well-known/jwks.json"

class TokenVerifier:
    def __init__(self):
        self.config = get_settings()
        self.jwks_client = PyJWKClient(jwks_url)
        self.allowed_algorithms = ["RS256"]

    async def __call__(
        self,
        security_scopes: SecurityScopes,
        # token injected by FastAPI Security, specified in the FastAPI route definition
        token: Optional[HTTPAuthorizationCredentials] = Depends(HTTPBearer())
    ):
        if token is None:
            raise UnauthenticatedException

        token = token.credentials

        key = self._get_signing_key(token)
        payload = self._decode_token(token, key)

        if security_scopes.scopes:
            self._enforce_scopes(payload, security_scopes.scopes)

        return payload

    def _get_signing_key(self, token: str):
        try:
            return self.jwks_client.get_signing_key_from_jwt(token).key
        except Exception as e:
            raise UnauthorizedException(f"Failed to fetch signing key: {str(e)}")

    # helper which calls jwt.decode()
    def _decode_token(self, token: str, key):
        try:
            project_id = os.getenv("DESCOPE_PROJECT_ID")
            issuer_candidates = [
                f'https://api.descope.com/v1/apps/{project_id}', 
                project_id
            ]
            return jwt.decode(
                token,
                key,
                algorithms=self.allowed_algorithms,
                issuer=issuer_candidates,
                audience=project_id
            )
        except Exception as e:
            raise UnauthorizedException(f"Token decoding failed: {str(e)}")

To restrict access to specific API routes based on the scopes carried by the incoming JWT token, add one more method to the TokenVerifier class that checks the token's scope claim. After successful validation, it reads the token's scope claim, compares it to the route's required scopes, and rejects the request if any are missing.

def _enforce_scopes(self, payload: dict, required_scopes: List[str]):
        scope_claim = payload.get("scope")
        if scope_claim is None:
            raise UnauthorizedException('Missing required claim: "scope"')

        scopes = scope_claim.split() if isinstance(scope_claim, str) else scope_claim
        missing = [scope for scope in required_scopes if scope not in scopes]

        if missing:
            raise UnauthorizedException(
                f'Missing required scopes: {", ".join(missing)}'
            )

Now let's hook up our JWT authorizer to the main file where you define your APIs. You can protect your API routes with token validation and/or scoping, restricting specific routes to tokens which have specific scopes. While scoping isn't mandatory for basic authentication, it's highly recommended when working with custom GPTs. This is because they handle 403 error responses fairly seamlessly, and they can gracefully inform users when they lack permissions. The scopes embedded in your access token will be set when creating your Descope Inbound App later in this article. For more insights on implementing robust security controls in enterprise applications, check out our enterprise MCP security challenges blog.

You may already have route protection configured, but if you do not, set it up as follows:

import urllib.request
import os
from app.auth import TokenVerifier

# Set a custom User-Agent to avoid being blocked by security filters or rate limiters.
opener = urllib.request.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0 (DescopeFastAPISampleApp)')]
urllib.request.install_opener(opener)

auth = TokenVerifier() 

@app.get("/api/private")
def private(auth_result: str = Security(auth)):
    # This API is now protected by our TokenVerifier object `auth`
    return auth_result

@app.get("/api/private-scoped/read")
def private_scoped(auth_result: str = Security(auth, scopes=['read:messages'])):
    """
    This is a protected route with scope-based access control.

    Access to this endpoint requires:
    - A valid access token (authentication), and
    - The presence of the `read:messages` scope in the token.
    """
    return auth_result

You should now have a working JWT authorizer implemented with your FastAPI app! For more detailed information on the functionality of this implementation, you can visit our Validating JWTs in FastAPI doc.

Configuring your FastAPI app to be an authorization server

Because the GPT requires the OAuth endpoints and the APIs to be hosted under the same domain name, you will use your FastAPI app as a proxy or middleware between the client application (Custom GPT) and the identity provider (Descope). If you are using a custom domain that's the same root domain as your FastAPI backend, you can skip this step.

You will expose three endpoints that your custom GPT will treat as its OAuth server:

GET /authorize – forwards the browser to Descope's /authorize endpoint
GET /api/oauth/callback – receives the authorization response from Descope and transforms it into the format expected by the custom GPT, including proper state parameter preservation and error handling for a seamless user experience.
POST /token – forwards the GPT's back-channel token exchange to Descope's /token endpoint

Authorization endpoint

The /authorize endpoint acts as the first step in the OAuth authorization code flow. When you initiate authentication through your custom GPT, this endpoint receives the OAuth parameters including response_type, redirect_uri, scope, and state. The endpoint performs several critical functions to ensure a secure OAuth flow:

Validates the incoming request parameters to ensure OAuth compliance and prevents malformed or malicious requests.
Dynamically constructs the callback URL based on the request's host, providing flexibility for different deployment environments.
Transforms the request into Descope's expected format by adding the necessary client credentials and redirect URI.
Redirects you to Descope's authorization server, where you can authenticate and authorize the application.

This proxy architecture provides several key benefits: centralized control over the OAuth flow, enhanced security through request validation and sanitization, and the flexibility to add custom logging and error handling.

@app.get("/authorize")
async def authorize(
    request: Request,
    response_type: Optional[str] = None,
    redirect_uri: Optional[str] = None,
    scope: Optional[str] = None,
    state: Optional[str] = None
):
    """
    OAuth 2.0 Authorization Endpoint - Proxies to Descope

    This endpoint forwards OAuth authorization requests to Descope's Inbound Apps.
    """
    try:
        # Validate required parameters
        if not redirect_uri or not response_type:
            print(f"Missing required parameters")
            raise HTTPException(
                status_code=400
            )

        # Validate response_type
        if response_type != "code":
            print(f"Unsupported response_type: {response_type}")
            raise HTTPException(
                status_code=400
            )

        # Get client ID from environment or use the provided one
        descope_client_id = os.getenv("DESCOPE_INBOUND_APP_CLIENT_ID")
        if not descope_client_id:
            print("OAuth client credentials not configured")
            raise HTTPException(
                status_code=500,
            )

        # Get the base URL from the request
        base_url = str(request.base_url).rstrip('/')
        callback_url = f"{base_url}/api/oauth/callback"

        # Construct query parameters
        params = {
            "client_id": descope_client_id,
            "redirect_uri": callback_url,
            "response_type": "code",
            "scope": scope or "openid",
            "state": state or ""  # Just pass through the state parameter
        }

        # Build the full URL with query parameters
        query_string = "&".join([f"{k}={v}" for k, v in params.items()])
        full_url = f"https://api.descope.com/oauth2/v1/apps/authorize?{query_string}"

        print(f"Redirecting to Descope: {full_url}")

        # Redirect to Descope's authorization endpoint
        return RedirectResponse(url=full_url)

    except HTTPException:
        raise
    except Exception as error:
        print(f"Authorization endpoint error: {error}")
        raise HTTPException(
            status_code=500
        )

Token exchange endpoint

The /token endpoint performs the OAuth 2.0 token exchange process, handling the conversion of authorization codes into access tokens. When your custom GPT sends a token exchange request, this endpoint manages the complete flow from validation to token retrieval. The endpoint handles several key operations during the token exchange:

Parses the incoming request body containing the authorization code, client credentials, and grant type from your custom GPT.
Validates all required parameters including the grant type and client credentials to ensure the request meets OAuth 2.0 standards.
Dynamically constructs the redirect URI to match the original authorization request, maintaining consistency across the flow.
Forwards the validated request to Descope's token server with proper client credentials and authorization code, acting as a trusted intermediary.

This centralized architecture enables detailed request/response logging for debugging, allows for custom validation and transformation of the OAuth flow, and maintains full compatibility with standard OAuth implementations while giving you complete control over the token exchange process.

@app.post("/token")
async def token(
    request: Request
):
    """
    OAuth 2.0 Token Endpoint - Proxies to Descope

    This endpoint forwards token exchange requests to Descope's Inbound Apps.
    """
    print("Token exchange request received")

    try:
        # Parse the request body based on content type
        content_type = request.headers.get("content-type", "")
        print(f"Request content-type: {content_type}")

        if "application/json" in content_type:
            body = await request.json()
        elif "application/x-www-form-urlencoded" in content_type:
            form_data = await request.form()
            body = dict(form_data)
        else:
            # Try to parse as JSON first, then as form data
            try:
                body = await request.json()
            except:
                form_data = await request.form()
                body = dict(form_data)

        grant_type = body.get("grant_type")
        code = body.get("code")
        client_id = os.getenv("DESCOPE_INBOUND_APP_CLIENT_ID")
        client_secret = os.getenv("DESCOPE_INBOUND_APP_CLIENT_SECRET")

        # Validate required parameters
        if not grant_type or not code or len(client_id) == 0 or len(client_secret) == 0:
            raise HTTPException(
                status_code=400
            )

        # Only support authorization_code grant type
        if grant_type != "authorization_code":
            raise HTTPException(
                status_code=400
            )

        # Get the base URL from the request
        base_url = str(request.base_url).rstrip('/')
        callback_url = f"{base_url}/api/oauth/callback"

        # Forward the request to Descope's token endpoint
        token_request_body = {
            "grant_type": "authorization_code",
            "client_id": client_id,
            "client_secret": client_secret,
            "code": code,
            "redirect_uri": callback_url
        }

        descope_url = "https://api.descope.com/oauth2/v1/apps/token"

        async with httpx.AsyncClient() as client:
            print("Sending request to Descope token endpoint")
            response = await client.post(
                descope_url,
                data=token_request_body,
                headers={"Content-Type": "application/x-www-form-urlencoded"}
            )

            descope_data = response.json()

            # If Descope returned an error, log it
            if response.status_code >= 400:
                print(f"Descope token exchange failed: {descope_data}")

            # Return the response from Descope
            return descope_data

    except HTTPException:
        raise
    except Exception as error:
        print(f"Token endpoint error: {error}")
        raise HTTPException(
            status_code=500
        )

Callback endpoint

The /api/oauth/callback endpoint serves as the bridge in the OAuth 2.0 authorization code flow, receiving the authorization response from Descope and transforming it into the format expected by your custom GPT. When Descope redirects the user's browser back to this endpoint, it performs several critical operations:

Extracts the authorization code and state parameter from Descope's callback response.
Validates the received parameters and handles any OAuth errors returned by Descope during the authorization process.
Constructs a properly formatted redirect URL that includes the authorization code and preserved state parameter in the format your custom GPT expects.
Issues a 307 Temporary Redirect response to the user's browser, which automatically follows the redirect to your custom GPT's callback URL.

The 307 redirection mechanism is crucial because it preserves the HTTP method and request body while ensuring that your custom GPT receives the authorization data in exactly the format it needs to complete the token exchange.

@app.get("/api/oauth/callback")
async def oauth_callback(
    code: Optional[str] = None,
    state: Optional[str] = None,
    error: Optional[str] = None,
    error_description: Optional[str] = None
):
    """
    OAuth 2.0 Callback Endpoint

    Handles the callback from Descope and redirects back to Custom GPT.
    """
    try:
        # Handle errors from Descope
        if error:
            raise HTTPException(
                status_code=400,
                detail={
                    "error": error,
                    "error_description": error_description
                }
            )

        if not code:
            raise HTTPException(
                status_code=400,
                detail={
                    "error": "invalid_request",
                    "error_description": "No authorization code received"
                }
            )

        # Custom GPT callback URL - obtained after creating your GPT
        custom_gpt_callback = "<Your GPT callback URL>"

        # Build redirect URL back to Custom GPT
        redirect_url = f"{custom_gpt_callback}?code={code}"
        if state:
            redirect_url += f"&state={state}"

        return RedirectResponse(url=redirect_url)

    except HTTPException:
        raise
    except Exception as error:
        raise HTTPException(
            status_code=500,
            detail={
                "error": "server_error",
                "error_description": "Internal server error"
            }
        )

Setting up an Inbound App

Now we will set up the Descope part of this backend by creating an Inbound App. Inbound Apps enable you to turn your application into an identity provider (IdP). The Inbound App will handle the OAuth flow, endpoints, and consent mechanisms for you, allowing you to easily manage authentication and define granular permission scopes at the user or tenant level. When you configure your custom GPT, it will use a scoped OAuth token generated by your Inbound App to access the APIs that it is authorized to access.

To create a new Descope Inbound App, navigate to the Inbound Apps page of your Descope console. Select the blue + Inbound App button on the right side of the screen, and give your new Inbound App a name and optional description.

Scoping your Inbound App

After you create your Inbound App, you will be able to see all the settings and details. If you scroll down to the Scopes section, this is where you will define what scopes will be embedded in the JWT token provided to your application. The scope names you set here should exactly match the scopes that are required by the API routes that you wish to give your token access to.

Client ID and secret

Next, scroll down to the Connection Information section, and here you will see the configuration data needed to integrate your backend app with the Inbound App. For example, notice the Authorization URL and Token URL are the same URLs that we routed to in the /authorize and /token routes of our FastAPI app. The most important values here are the Client ID and Client Secret. Copy and paste those values into your .env file for your DESCOPE_INBOUND_APP_CLIENT_ID and DESCOPE_INBOUND_APP_CLIENT_SECRET variables, respectively.

User consent flow

Notice also the Flow Hosting URL. This URL points to the exact Descope flow that will be used to define the authentication and consent user journey. If you navigate over to the Flows section of the Descope console, you will see that once you created your first Inbound App, Inbound App consent flows were also automatically created for you. The default user consent flow was the one demonstrated at the beginning of this article.

Custom session token expiration

By default, the session token issued by your Inbound App will expire 10 minutes after the time of issuance. If you want to adjust this, scroll down to the last section of the Inbound App settings, called Session Management. Select the Custom option, and then modify the Session Token Timeout.

Your Inbound App is now fully configured and ready to use!

Configuring your custom GPT

GPTs enable you to create a tailored version of ChatGPT based on custom instructions, actions, or context. For this article, we are going to be configuring a GPT which will act as your personal DevOps assistant. We will essentially be building an AI agent, but one that knows how to interact with your specific APIs. To create a new GPT, open the ChatGPT homepage and select the GPTs tab in the left sidebar. This will bring you to the homepage of existing publicly available GPTs. Select the + Create button in the upper right corner.

Select the Configure tab on your GPT. Enter a name for your GPT, and optionally provide an icon, description, instructions, prompt starters, and knowledge (extra context) on this page.

Configuring OAuth for your GPT

Scroll all the way down to the bottom of the Configure page, and under Actions, select the Create new action button. This action will be the mechanism through which your GPT will interface with your application. Once on the action definition page, click on the Authentication dropdown menu and select OAuth as your authentication type. This will open up a new window, where you will configure the OAuth connection between this GPT and your API. You will need to specify the following:

Authorization URL: this is your API route that handles the initial call to the Descope authorize endpoint (e.g. app/authorize).
Token URL: this is the API route that handles the code and token exchange at the Descope token endpoint (e.g. app/token).
Token Exchange Method: Make sure Default (POST request) is selected. Leave the Client ID, Client Secret, and Scope fields blank. Your backend application will take care of these parts.

Click Save once you have filled out the appropriate fields.

Creating an OpenAPI spec

Once you have configured the OAuth credentials, you will need to provide an OpenAPI 3.1.0 spec in the textbox titled Schema. An OpenAPI spec is a document written in a machine readable format like YAML or JSON that describes your API endpoints and how to call them with the appropriate parameters, request/response formats, authentication methods, and other relevant information. For an example of an OpenAPI spec in either a JSON or YAML format, visit this Descope sample app. FastAPI easily generates a JSON file for you, simply enter the URL where your application is hosted followed by /openapi.json. If you utilize this option, you will have to add a servers object, where you will tell the GPT the URL where it can find your API server.

"servers": [
    {
      "url": "https://<Your base URL>"
    }
]

To complete the process of creating your GPT, click the black Create button in the top right corner. You will then have the option of keeping your GPT private, or sharing it with others. This is up to your personal preference, but sharing it will require you to add a privacy policy. After you create your GPT, navigate to GPTs > My GPTs then click the pencil icon on your GPT and scroll down to the same place where you created your action earlier. Now you should see an action with your base URL listed, and under it you will see a Callback URL. Copy this callback URL and paste it into the custom_gpt_callback variable in the /api/oauth/callback route.

GPTs with Descope

Now you can securely interact with your FastAPI routes through an LLM – all without having to spin up an MCP server. This approach provides a robust, secure, and maintainable way to connect custom GPTs to your protected APIs. By leveraging Descope's Inbound Apps and OAuth capabilities, you can create sophisticated AI agents without the complexity of MCP servers.

To explore Descope further, sign up for a free account, join our developer Slack community, or follow us on LinkedIn.

Authenticating CLI Tools With Descope

Mrunank Pawar — Fri, 01 May 2026 15:00:00 +0000

This blog was originally published on Descope.

Need to add authentication to your command-line tool? Most command-line applications rely on API keys, manual token management, and other methods that create friction for users who just want to get authenticated.

In this blog, we'll walk through the challenges of CLI authentication and how to implement it seamlessly with Descope Inbound Apps. We'll also show how to bring OAuth 2.0 directly to your CLI app with code examples in Go.

What is CLI authentication?

In the context of command-line applications, authentication presents a unique challenge: how do you securely authenticate users in an environment that traditionally lacks the interactive elements of web applications?

Most CLI tools handle this via the tedious storage of API keys in configuration files or environment variables. This approach creates friction for users and introduces security risks as a byproduct of storing credentials in plain text or across systems.

Consider this scenario: You switch to a new laptop and need to set up various CLI applications, such as deployment tools, database clients, cloud service CLIs, and internal company tools. For each of these tools, you will need to generate API keys from different dashboards, make new cryptic environment variables to store these values, and save them in obscure configuration files. Now, you have API keys scattered across config files and tokens with overly broad permissions because of mishandled scoping. And eventually when you leave your company, IT will have no way to revoke access to these tools with these keys. This is the tax of API key storage for authentication and the potential security nightmare.

CLI authentication using OAuth 2.0 solves this by bringing the familiar browser-based authentication flow directly to terminal applications. Users are able to authenticate through the same OAuth providers and flows they use in web applications.

How authentication looks with Descope Inbound Apps

Inbound apps in Descope turn your application into an identity provider, making it compliant with OAuth standards and allowing third-party applications, APIs, and tools to authenticate and access authorized user data through a user consent flow with scope-based access control. They also handle OAuth flows and contain the necessary credentials for OAuth parameters, redirect URIs, and authentication settings. If you would like to learn more, check out our blog on Inbound Apps.

When a user runs an authentication command, or any command that requires authentication to use, the CLI tool generates an OAuth authorization URL corresponding to your Inbound App and opens the link in the user's default browser. The user then proceeds to complete the standard OAuth flow in their browser, signing in and authorizing the inbound app. Finally, the CLI app will receive the authorization callback with the necessary tokens to act on the user's behalf.

Example: CLI authentication in Golang

Now that we understand the purpose of CLI authentication and what our authentication flow looks like with Descope Inbound Apps, we can implement our own sample application.

Prerequisites and set up

Before we dive into our CLI application, make sure you have Go 1.19 or later and a configured Descope Inbound App. If you're new to Descope, no problem. To get started, sign up for a free account on Descope Get started docs.

Step 1: Create your Descope Inbound App

Navigate to your Descope console and click on Inbound Apps in the left sidebar.

Click the + Inbound App button and give your app a name. Once created, you can configure scopes and view your connection information.

Step 2: Set up your Go command-line app with Cobra

To initialize your new Go module and install the Cobra generator, run:

go mod init <your-module-name> &&
go install github.com/spf13/cobra-cli@latest &&
go get github.com/spf13/cobra &&
cobra-cli init

Now, you will see your basic project structure including your main application file (main.go) and a cmd folder containing your root.go file. You should see the following in the root.go file:

package cmd

import (
    "os"

    "github.com/spf13/cobra"
)

var rootCmd = &cobra.Command{
    Use:   "clidemo",
    Short: "A brief description of your application",
    Long: `A longer description that spans multiple lines and likely contains
examples and usage of using your application. For example:

Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.`,
    Run: func(cmd *cobra.Command, args []string) {},
}

func Execute() {
    err := rootCmd.Execute()
    if err != nil {
        os.Exit(1)
    }
}

func init() {
    rootCmd.Flags().BoolP("toggle", "t", false, "Help message for toggle")
}

For the purposes of the demonstration, we will be using the Run in rootCmd in order to run our authentication flow upon program execution.

Step 3: Configuring your Inbound App

Connecting to your Inbound App requires setting up the relevant credentials. The form of the configuration will look like this:

type InboundAppConfig struct {
    Issuer                            string
    JwksURI                          string
    AuthorizationEndpoint            string
    ResponseTypesSupported           []string
    SubjectTypesSupported            []string
    IdTokenSigningAlgValuesSupported []string
    CodeChallengeMethodsSupported    []string
    TokenEndpoint                    string
    UserInfoEndpoint                 string
    ScopesSupported                  []string
    ClaimsSupported                  []string
    RevocationEndpoint               string
    RegistrationEndpoint             string
}

// then, in your Run function, define your configuration
// the base URL and project ID should be defined as environmental variables
config := InboundAppConfig{
    Issuer:                            DESCOPE_BASE_URL + "/v1/apps/" + DESCOPE_PROJECT_ID,
    JwksURI:                          DESCOPE_BASE_URL + "/" + DESCOPE_PROJECT_ID + "/.well-known/jwks.json",
    AuthorizationEndpoint:            DESCOPE_BASE_URL + "/oauth2/v1/apps/authorize",
    ResponseTypesSupported:           []string{"code"},
    SubjectTypesSupported:            []string{"public"},
    IdTokenSigningAlgValuesSupported: []string{"RS256"},
    CodeChallengeMethodsSupported:    []string{"S256"},
    TokenEndpoint:                    DESCOPE_BASE_URL + "/oauth2/v1/apps/token",
    UserInfoEndpoint:                 DESCOPE_BASE_URL + "/oauth2/v1/apps/userinfo",
    ScopesSupported:                  []string{"openid"},
    ClaimsSupported: []string{
        "iss",
        "aud",
        "iat",
        "exp",
        "sub",
        "name",
        "email",
        "email_verified",
        "phone_number",
        "phone_number_verified",
        "picture",
        "family_name",
        "given_name",
    },
    RevocationEndpoint:    DESCOPE_BASE_URL + "/oauth2/v1/apps/revoke",
    RegistrationEndpoint:  DESCOPE_BASE_URL + "/v1/mgmt/inboundapp/app/" + DESCOPE_PROJECT_ID + "/register",
}

This is a blueprint for the Inbound App, identifying it by the aforementioned connection information.

Next, we create a handler for OpenID Connect discovery requests through the .well-known/openid-configuration endpoint.

http.HandleFunc("/.well-known/openid-configuration", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    w.Header().Set("Access-Control-Allow-Origin", "*")
    w.Header().Set("Access-Control-Allow-Methods", "GET, OPTIONS")
    w.Header().Set("Access-Control-Allow-Headers", "Content-Type, mcp-protocol-version")

    if r.Method == http.MethodOptions {
        w.WriteHeader(http.StatusNoContent)
        return
    }

    json.NewEncoder(w).Encode(config) // using our Inbound App config
})

Step 4: Generating an OAuth URL

Creating the parameters for the OAuth URL requires creating an OAuth2 CSRF state, a PKCE code verifier, and a code challenge. The state prevents Cross-Site Forgery attacks, verifying that the state remains the same when starting the OAuth2 flow and when redirecting back to the app. The Proof Key for Code Exchange code verifier is hashed in the code challenge, and the server verifies the two values are corresponding when exchanging the authorization code for tokens.

To create these parameters, we will make a util.go class for the associated functions.

func randomString(n int) string { // used to generate the state & verifier
    b := make([]byte, n)
    rand.Read(b)
    return base64URLEncode(b)
}

func sha256Hash(input string) []byte { // for hashing the verifier
    h := sha256.New()
    h.Write([]byte(input))
    return h.Sum(nil)
}

func base64URLEncode(data []byte) string { // for encoding the string & hash
    return strings.TrimRight(base64.URLEncoding.WithPadding(base64.NoPadding).EncodeToString(data), "=")
}

Then, in root.go, we create the authorization URL using the authorization endpoint and params:

state := randomString(16)
codeVerifier := randomString(64)
codeChallenge := base64URLEncode(sha256Hash(codeVerifier))

params := url.Values{
    "response_type":         {"code"},
    "client_id":             {DESCOPE_CLIENT_ID},
    "redirect_uri":          {REDIRECT_URI},
    "scope":                 {""},
    "state":                 {state},
    "code_challenge":        {codeChallenge},
    "code_challenge_method": {"S256"},
}

authURL := config.AuthorizationEndpoint + "?" + params.Encode()

Step 5: Authorization callback and retrieving tokens

Now, we will set up a channel to receive our authorization code and exchange it for tokens. Go makes this elegant:

codeChan := make(chan string) // channel receiving strings
srv := &http.Server{Addr: ":8080"} // server to listen to

Since the redirect URI is configured to http://localhost:8080/callback (can be configured to a custom redirect URI), we set up an HTTP server listening on port 8080 to handle the OAuth callback response. We then handle the OAuth callback through a couple of steps:

Error handling

Verify that the OAuth provider did not send back any error.

if errorCode := r.URL.Query().Get("error"); errorCode != "" {
    errorDesc := r.URL.Query().Get("error_description")
    log.Printf("OAuth Error: %s - %s", errorCode, errorDesc)
    http.Error(w, fmt.Sprintf("OAuth error: %s - %s", errorCode, errorDesc), http.StatusBadRequest)
    return
}

State validation

Compare the state parameter of the callback URL to the originally generated CSRF state.

if r.URL.Query().Get("state") != state {
    http.Error(w, "Invalid state", http.StatusBadRequest)
    return
}

Authorization code extraction

Look for the code parameter of the callback URL provided after successful login.

code := r.URL.Query().Get("code")
if code == "" {
    http.Error(w, "Missing code", http.StatusBadRequest)
    return
}

Success!

Receive the authorization code and output a success on the page for visual representation.

fmt.Fprintln(w, "Login successful! You may close this browser window.")
codeChan <- code

Opening the browser, posting, and fetching the token

We want the user to interact with the authorization URL to proceed with the callback. In order to open the user browser, we add the following to our util.go:

func openBrowser(url string) {
    var cmd string
    var args []string

    switch runtime.GOOS {
    case "windows":
        cmd = "rundll32"
        args = []string{"url.dll,FileProtocolHandler", url}
    case "darwin":
        cmd = "open"
        args = []string{url}
    default:
        cmd = "xdg-open"
        args = []string{url}
    }

    exec.Command(cmd, args...).Start()
}

The function will call the corresponding shell command to open the user's browser for their respective operating system. Our next steps to retrieve the token response will be to post a request to the token endpoint of the following form:

"grant_type":     {"authorization_code"}, // grant by auth code
"client_id":      {DESCOPE_CLIENT_ID},    // your inbound app client id
"code":           {code},                 // the code fetched from the channel
"redirect_uri":   {REDIRECT_URI},         // your redirect URI
"code_verifier":  {codeVerifier},         // previously calculated verifier

And, putting it all together with a final authentication message on the CLI app:

openBrowser(authURL)
code := <-codeChan
srv.Shutdown(context.Background())

resp, err := http.PostForm(config.TokenEndpoint, url.Values{
    "grant_type":    {"authorization_code"},
    "client_id":     {DESCOPE_CLIENT_ID},
    "code":          {code},
    "redirect_uri":  {REDIRECT_URI},
    "code_verifier": {codeVerifier},
})
if err != nil {
    log.Fatalf("Token exchange error: %v", err)
}
defer resp.Body.Close()

if resp.StatusCode != http.StatusOK {
    log.Fatalf("Token exchange failed with status: %d", resp.StatusCode)
}

var tokenResp map[string]interface{} // response format in Go
if err := json.NewDecoder(resp.Body).Decode(&tokenResp); err != nil {
    log.Fatalf("Invalid token response: %v", err)
}

fmt.Println("Welcome! You have successfully authenticated with Descope")

Visualizing the Flow

Run your application:

go run main.go

Then, your browser will open a new page:

Next, you will see the browser output after authenticating the user and successfully authorizing the Inbound App:

Login successful! You may close this browser window.

Finally, the CLI app will print a success message after receiving the authorization callback:

Welcome! You have successfully authenticated with Descope Inbound Apps.

If you would like to see the full sample code, it is available in our Github repository.

CLI authentication made simpler with Descope

CLI auth with Descope Inbound Apps makes your command-line authentication flow smoother, safer, and free of user friction. Users will be able to authenticate with the same OAuth providers and flows they use in web applications, providing a seamless and familiar experience. Sign up for a Free Forever Descope account now to start creating frictionless CLI authentication flows. You can also dive into more auth best practices by joining AuthTown, our community of developers building better identity experiences. Got questions about Descope? Book time with our auth experts.

Adding Authentication Middleware With Descope

Mrunank Pawar — Wed, 29 Apr 2026 15:00:00 +0000

This blog was originally published on Descope.

Looking to implement authentication middleware in your app? Most modern frameworks support middleware functions that let you intercept user requests, verify tokens, and control access—all in a centralized way.

In this blog, we'll walk through how authentication middleware works and how to implement it effectively using code examples in Node.js and Python. Once you understand the basics, we'll show how Descope's tools can streamline the process with out-of-the-box support for token validation, role checks, and more.

What is authentication middleware in web apps

In the context of web development, authentication middleware is a function that intercepts incoming requests and runs logic before or after those requests reach your application's core handlers. Middleware gives you a centralized way to manage access control, freeing up developer time to focus on business logic instead of duplicating auth checks across routes.

Most modern frontend and backend frameworks support this concept. You typically register a function—similar to a callback—that's triggered with every request. This can happen before the request reaches a controller or after the response is generated.

Within this middleware function, you can inspect request headers (like Authorization) and validate session tokens or permissions before allowing access to protected routes.

Example: Authentication middleware in Node.js

Let's look at how to build simple authentication middleware using Express in a Node.js app. This middleware intercepts requests, checks for an authorization header, and validates the session token before passing the request to the next handler.

var express = require('express')
var app = express()

var validateJwt = function(token) {
  // validation logic
  return true;
}

var authMiddleware = function (req, res, next) {
  req.isValidSession = validateJwt(req.headers.authorization)
  next()
}

app.use(authMiddleware)

app.get('/', function (req, res) {
  var responseText = 'Hello World!<br>'
  responseText += '<small>Session Valid:' + req.isValidSession + '</small>'
  res.send(responseText)
})

app.listen(3000)

In this example, the authMiddleware function runs on every request. It extracts the token from the Authorization header, runs a validation check, and attaches the result (isValidSession) to the request object. This setup gives you a lightweight way to apply authentication logic across all routes in your Express app.

Adding Descope authentication to Node.js middleware

Now that we understand how middleware works, we can use it to implement robust authorization and authentication middleware by validating user sessions on every request.

Descope makes this easier by providing SDKs that handle session and token validation. Instead of repeating auth logic across your app, you can centralize it in a single middleware function. That way, each incoming request is automatically checked for a valid access token or refresh token before hitting protected routes.

Here's how to build authentication middleware using the Descope Node.js SDK:

authentication.js

import DescopeClient from '@descope/node-sdk';

export class DescopeMiddleware {
  constructor(projectId) {
    this.descopeClient = DescopeClient({ projectId: projectId});
  }

  validate(token) {
    try {
      const authInfo = await descopeSdk.validateSession(sessionToken);
      console.log("Successfully validated user session:");
      console.log(authInfo);
    } catch (error) {
      console.log("Could not validate user session " + error);
    }
  }
}

app.js

import express from 'express';
import DescopeMiddleware from './authentication.js';

const app = express();
const authMiddleware = new DescopeMiddleware('__PROJECT_ID__');

app.use(authMiddleware.validate());

app.get('/', (req, res) => {
  res.send('main');
});

app.listen(3000, () => {
  console.log("Express Running port 3000")
});

This pattern helps you manage authentication in one place. It also improves maintainability by offloading session validation to Descope's SDK, allowing you to focus on application logic.

Using Descope decorators in Python

Python decorators are a powerful way to wrap additional behavior around existing functions, making them especially useful for building authentication middleware in Python web frameworks.

A decorator takes a function as input, extends or modifies its behavior, and returns a new function. This allows you to centralize logic, such as logging, validation, or—in our case—authentication, without cluttering every route with repeated code.

Here's a basic example of how decorators work:

def my_decorator(func):
    def wrapper():
        print("Something is happening before the function is called.")
        func()
        print("Something is happening after the function is called.")
    return wrapper

@my_decorator
def say_hello():
    print("Hello!")

say_hello()

To use a decorator, you simply annotate a function with @decorator_name. When you call that function, Python actually runs the wrapper logic defined inside the decorator. In this case, calling say_hello() produces the following output:

> Something is happening before the function is called.
> Hello!
> Something is happening after the function is called.

This structure is ideal for building authentication middleware in frameworks like Flask, FastAPI, or Django, where decorators can be applied directly to route functions to enforce login or permission checks.

Example: Descope Python decorator

You could write your own authentication middleware using decorators in Flask, FastAPI, or Django. But to save time, Descope provides prebuilt decorators that handle session validation, role enforcement, and other identity checks out of the box.

Here's an example of using Descope's @descope_validate_auth decorator to protect a route that requires authentication:

# This needs authentication
@APP.route("/private")
@descope_validate_auth(
    descope_client
)  # Can add permissions=["Perm 1"], roles=["Role 1"], tenant="t1" conditions
def private():
    return Response("<h1>Restricted page, authentication needed.</h1>")

This decorator automatically checks the user's JWT. If the token doesn't meet the conditions—such as having the correct roles or permissions—Descope will return a 401 Unauthorized response without running the route handler.

Descope also provides other decorators that extend the behavior of your routes. For example, the @descope_full_login decorator can trigger a Descope Flow:

@APP.route("/login", methods=["GET"])
@descope_full_login(
    project_id=PROJECT_ID,
    flow_id="sign-up-or-in",
    success_redirect_url="http://dev.localhost:9010/private",
)
def login():
    # Nothing to do! this is the MAGIC!
    pass

Need to handle logout? The @descope_logout decorator clears the user's session:

@APP.route("/logout")
@descope_logout(descope_client)
def logout():
    return Response("<h1>Goodbye, logged out.</h1>")

With just a few lines of code, you can use decorators to handle user authentication and session flow without repeating logic across your app.

Authentication middleware made simpler with Descope

Authentication middleware lets you centralize and automate how your app handles access control. By intercepting requests and validating tokens before they hit protected routes, middleware simplifies security and improves the user experience.

Descope gives you tools to build and manage this layer more efficiently. Whether you prefer writing your own middleware or using prebuilt decorators, you can plug in Descope's SDKs and flows to streamline session validation, role enforcement, and login logic.

Want to add authentication to your app without reinventing the wheel? Sign up for a Free Forever Descope account to get started. If you have questions or want to learn more about authentication best practices, book time with our auth experts.