DEV Community: Mrunank Pawar

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.

Add Authentication and SSO to Your Shiny App

Mrunank Pawar — Mon, 27 Apr 2026 15:00:00 +0000

This blog was originally published on Descope.

Shiny lets you easily build web apps for data science using R and Python without the need for any web development experience. You can deploy these applications on your own web server or use Posit Connect to deploy them directly from your IDE.

Although deploying the applications is straightforward, it's also vital to set up proper access control for these applications to ensure that only authenticated users can view and interact with the data. Integrating single sign-on (SSO) with Shiny apps can provide a seamless authentication experience for the users. As these apps are often used by different business or enterprise users who might need to log in with their own identity provider (IdP), SSO allows them to use their existing credentials to log in.

Descope offers a no-code Customer Identity Platform (CIAM) that lets you easily define a customized workflow for sign-up, login, multi-factor authentication (MFA), SSO, and Security Assertion Markup Language (SAML).

In this tutorial, you'll learn how to implement authentication and SSO in a Shiny app.

Prerequisites

Before starting, you need to do the following:

Install RStudio on your development machine.
Install Posit Connect locally and configure its license. This tutorial uses an on-prem installation of Posit Connect on AWS, but alternatively, you can sign up for Posit Connect Cloud and use it to follow along.
Sign up for a free Descope account.

Set up Descope

Before you can integrate Descope authentication into your Shiny application, you need to define an authentication flow using the Descope portal.

Sign up for a free Descope account if you don't already have one, and follow the Getting Started wizard to create a new flow. In the wizard, first, choose Consumers as the target audience for your app:

Next, choose the authentication methods you want to use. In this tutorial, you'll use Magic Link and SSO as the authentication method. You can change these settings in the future if you like:

Skip the next step that prompts you to choose an MFA method by clicking Go ahead without MFA. In the next step, review the selected settings and click Next to generate the authentication flow:

Create a Shiny app

In this tutorial, you'll create a personal finance application using Shiny and add Descope authentication. The Shiny app will let you upload a CSV file containing month-wise expense data, view a bar chart with monthly expense trends, and also analyze category-wise expenses.

Since the tutorial focuses on adding authentication, you can clone the starter code with the personal finance Shiny app. In the terminal, navigate to the project directory and check out the starter branch.

cd personal-finance-shiny
git checkout starter

Open the application using RStudio and attempt to run the starter app. When you run it for the first time, it will prompt you to install the required packages. After you install the packages and rerun the app, you'll notice that you're directly taken to the dashboard page without authentication:

Next, click on the Publish button in RStudio to deploy the app on Posit Connect.

Before you can publish the Shiny app, you need to connect your Posit Connect account by clicking Add new account and choosing Posit Connect. Enter the Posit Connect server URL and click Next to connect the account.

You'll be redirected to the web browser to confirm the linking between RStudio and Posit Connect. Click Connect to link the account.

After confirming the connection in the browser, navigate back to RStudio and click Connect Account to verify the account.

Finally, select the connected account, provide a title for the app, and click Publish to deploy the application.

The dashboard of the app has the following components:

The left section lets you upload a CSV file containing personal expense data. The GitHub repo contains a sample CSV that you could use for testing.
When you upload the CSV file, the right section lets you view and analyze the category-wise expenses based on the uploaded data.

Implement vanilla authentication with Descope

You've deployed the app to Posit Connect and can now add authentication methods to access it using Descope. In this section, you'll add auth using magic links and email OTP for simplicity. You can configure and use other authentication methods too but we will focus on magic links and OTP for this tutorial.

Descope offers a WebJS component to integrate its auth flows with HTML-based web apps. You can easily integrate the WebJS component with your Shiny app by adding a custom JavaScript widget.

In your R project, create a www/descope-auth.js file, add the following content to create a container for the Descope element, and set success and failure listeners:

// www/descope-auth.js
Shiny.addCustomMessageHandler('initDescopeAuth', function (config) {
  const wcElement = document.createElement('descope-wc');
  wcElement.setAttribute('project-id', config.projectId);
  wcElement.setAttribute('flow-id', config.flowId);
  wcElement.setAttribute('theme', config.theme);

  wcElement.addEventListener('success', function (e) {
    const user = e.detail.user;
    Shiny.setInputValue(config.successInput, user);
  });

  wcElement.addEventListener('error', function (err) {
    console.error('Authentication error:', err);
    Shiny.setInputValue(config.errorInput, err);
  });

  const container = document.getElementById(config.containerId);
  if (container) {
    container.innerHTML = ''; // Clear any previous instances
    container.appendChild(wcElement);
  }
});

Next, you need to update the UI definition to include the @descope/web-component and descope-auth.js JS scripts. Update the app.R file by replacing it with the following code snippet:

ui <- fluidPage(
  useShinyjs(), # For dynamic UI control
  tags$head(
    tags$script(src = "https://unpkg.com/@descope/web-component@3.32.0/dist/index.js"),
    tags$script(src = "descope-auth.js") # Include custom JavaScript
  ),
  titlePanel("Personal Finance Dashboard with Descope Auth"),

  # Descope Authentication UI
  div(id = "authContainer"),

  hidden(
    div(
      id = "appContent",
      sidebarLayout(
        sidebarPanel(
          fileInput("file", "Upload Expense Data (CSV)", accept = ".csv"),
          selectInput("category", "Select Category:", choices = NULL),
          actionButton("analyze", "Analyze")
        ),
        mainPanel(
          tabsetPanel(
            tabPanel("Overview", plotOutput("expenseTrend"), tableOutput("summaryTable")),
            tabPanel("Category Analysis", plotOutput("categoryTrend"), tableOutput("categoryTable"))
          )
        )
      )
    )
  )
)

Finally, you need to update the server definition to initialize the Descope web component and implement success and failure callbacks. Add the following code snippet at the start of the server section:

server <- function(input, output, session) {
  # Initialize Descope Auth
  session$sendCustomMessage("initDescopeAuth", list(
    projectId = "<YOUR_DESCOPE_PROJECT_ID>",
    flowId = "sign-up-or-in",
    theme = "light",
    containerId = "authContainer",
    successInput = "user_authenticated",
    errorInput = "auth_error"
  ))

  observeEvent(input$user_authenticated, {
    if (!is.null(input$user_authenticated)) {
      showNotification("Login successful!", type = "message")
      show("appContent")
    }
  })

  observeEvent(input$auth_error, {
    if (!is.null(input$auth_error)) {
      showNotification("Authentication failed. Please try again.", type = "error")
    }
  })
  ...
  # existing server definition
}

Replace YOUR_DESCOPE_PROJECT_ID with your Descope project ID, save the changes, and republish the app to Posit Connect using RStudio.

Test authentication using magic link

When a user clicks the magic link received in their email for authentication, Descope will validate the auth and redirect the user back to the Shiny application. For redirection to work, you need to configure the auth redirect URL in Descope. Head over to Magic link under Authentication Methods and set the Redirect URL to the published URL of your Shiny app.

To test the authentication, open the published content under the Content tab on Posit Connect.

When you run the app, you'll be redirected to the Descope auth screen. You can test the integration by entering your email ID on this screen and clicking the Continue button to log in with a magic link. You'll receive an email with a login link, and upon clicking it, you'll be redirected to the dashboard page of your Shiny app.

Create a new Descope tenant

After integrating vanilla authentication, the next step is to add SSO authentication using Descope. To do this, you first need to create a Tenant. Tenants represent organizations that use your application and make it easier to group and manage users, permissions, and authentication flows within the application. In this tutorial, you'll create a tenant for an example organization and use it to configure the SSO flow.

Navigate to Tenants and click the + Tenant button to create a new tenant.

Implement SSO with OIDC using Descope

OpenID Connect (OIDC) is an extension of the OAuth 2.0 authorization protocol that provides a standardized way for applications to request and receive identity information about users. Instead of managing user credentials for each application, OIDC SSO lets you delegate the authentication mechanism to a single trusted IdP, reducing the maintenance overhead. Once you log in, the IdP returns standardized JSON web tokens (JWTs) on login-containing information about the user's identity. In this section, you'll learn how to set up Descope as an OIDC IdP with Posit Connect.

Create a Descope OIDC application in a separate project

The Descope OIDC application acts as a federated IdP for the users. Based on your needs, Descope can act as a Service Provider (SP) or an IdP. An SP is an entity that initiates an authentication request to an IdP, which verifies the user's identity. After authentication, the SP processes the response from the IdP to determine whether the user should be granted access to the application. In the previous section, you configured the Descope project as an SP entity for auth and SSO.

You'll now create an OIDC application within Descope to turn it into an IdP, and subsequently, you'll also integrate it with your authentication flow. Since you're using Descope for both SP and IdP, to avoid cyclic dependency, both these entities should be configured in separate Descope projects.

First, use the Descope portal to create a new project to host the OIDC application. This tutorial sets the project name as descope-shiny-auth-sso.

You also need to create an OIDC application under the newly created project. Navigate to Applications and click the + Application button to register Generic OIDC Application.

Click Create to create the OIDC application and note the Descope OIDC endpoint configuration, as you'll need it while configuring the SSO tenant in the original project.

To configure OAuth with Posit Connect, you'll also need to create a new client secret. Navigate to the Access Keys page and click +Access key to create a new access key.

Configure Descope tenant to use OIDC SSO

To integrate the OIDC application with the authentication flow, you need to configure SSO under the example.com tenant you created under the original Descope SP project. A tenant lets you configure an authentication method using an OIDC or SAML application. This section discusses how to configure SSO using an OIDC application, and in a later section, you'll learn how to configure SSO using SAML.

Switch back to the Descope SP project and navigate to Tenants, and select the example.com tenant you created earlier. Choose Authentication Methods and select OIDC as the SSO authentication protocol. Make the following changes to configure SSO:

Under Tenant Details, add example.com to the SSO domains.
Update the SSO configuration by adding the following values:
- Provider name: Add a value for the provider. For example, the tutorial uses Descope as the provider name.
- Client ID: Use the Descope project ID for the descope-shiny-auth-sso project.
- Client Secret: Use the access key that you created above.
- Scopes: It sets the permissions for the access level that will be granted to the authenticated user. Add openid, profile, and email as the scopes.
- Issuer: Use the Issuer value from the OIDC application you created in the previous step.
- Authorization Endpoint: Use the Authorization URL value from the OIDC application.
- Token Endpoint: Use the Access Token URL value from the OIDC application.
- User Info Endpoint: Use the Access Token URL from the OIDC application by replacing /token with /userinfo.
Finally, Save the changes for them to take effect.

Configure SSO redirect URL

You also need to configure the Posit Connect application URL as an SSO redirect URL. Since the Shiny app is already configured to use Descope, it doesn't require any new changes. Grab the application URL, navigate to SSO under Authentication methods, and set it as the Redirect URL.

Note that the SSO redirect URL needs to be configured in the Descope SP project.

Test the OIDC SSO integration

Finally, to test the integration, open the application in the browser, enter your email ID, and click on Continue with SSO to initiate the SSO flow. Note that the email ID should use example.com for SSO to work since you didn't configure any other domains in Descope.

You'll be redirected to the IdP login screen, which, in this case, is hosted by the descope-shiny-auth-sso Descope project. You can verify this by comparing the project ID in the address bar with the Descope project ID.

For testing, complete the login using one of the social login options or the magic link, and upon authentication, you'll be redirected back to the Shiny dashboard.

Implement SAML SSO with Descope

SAML SSO is an XML-based open authentication standard that lets users log in to multiple web applications using a single set of credentials. SAML is a mature identity federation standard and is widely supported by legacy or internal enterprise applications. It serves a similar purpose to OIDC, but instead of JSON, it uses XML during authentication or authorization requests between the IdP and the SPs.

In this section, you'll learn how to configure SAML SSO with Descope using a mock SAML application and configuring the tenant to use SAML SSO.

Configure mock SAML tenant for testing

As you learned in the OIDC SSO section, Descope can act as both SP and IdP as needed, but this tutorial uses Descope as an SP and Mock SAML as an IdP. Mock SAML is a SAML 2.0 IdP that can test SAML SSO integrations quickly. If you don't have a SAML SP set up, you can use this tool to test your Descope SAML integration.

Navigate to Tenants and select the example.com tenant you created earlier. Choose Authentication Methods and change the SSO authentication protocol from OIDC to SAML. Make the following changes to configure SAML SSO:

Under Tenant Details, add example.com to the SSO domains.
Update the SSO configuration, select the Retrieve the connection details dynamically option, and set the Metadata URL for IdP to the following:

https://mocksaml.com/api/saml/metadata

Note: If you have a SAML SP setup, you can set the Descope Metadata (URL) of the SAML application instead of a Mock SAML URL.

Test the SAML SSO integration

To test the integration, open the application in the browser, enter your email ID, and click on Continue with SSO to initiate the SSO flow. Note that the email ID should use example.com for SSO to work since you didn't configure any other domains in Descope. If you used a mock URL, you'll be redirected to a MockSAML login page where you can confirm your email ID and click Sign in.

Note: If you configured a Descope SAML application with SP details, Descope will directly handle the authentication.

After logging in, you'll be redirected to the dashboard page.

Access users from Shiny

So you've now added authentication to the Shiny app using OIDC and SAML, but the Shiny application doesn't indicate that the user is logged in. This section discusses how to access the logged-in user metadata and display a welcome message in the UI.

You'll add a UI element to the sidebar and update the server definition to set the welcome message when the user is authenticated. First, add a welcomeText element to the sidebar by updating the sidebarPanel to the following:

sidebarPanel(
  # Add a welcome text element
  h3(textOutput("welcomeText")),
  br(),

  # Existing inputs
  fileInput("file", "Upload Expense Data (CSV)", accept = ".csv"),
  selectInput("category", "Select Category:", choices = NULL),
  actionButton("analyze", "Analyze"),
)

Update the user_authenticated observer under the server definition to set the welcome message:

observeEvent(input$user_authenticated, {
  req(input$user_authenticated)

  user_info <- input$user_authenticated

  # use "name", else fallback to "email", else "User"
  user_name <- user_info$name
  if (is.null(user_name)) user_name <- user_info$email
  if (is.null(user_name)) user_name <- "User"

  output$welcomeText <- renderText({
    paste("Welcome,", user_name)
  })

  showNotification("Login successful!", type = "message")
  show("appContent")
})

Notice that the above code snippet tries to retrieve the user's name from the user_info object and falls back to email if name is not present.

Save and republish the changes to test them. Once you log in to the dashboard, a welcome message will be displayed.

Log out a user

Your users also need logout functionality to enable them to end their sessions. To implement logout, first, add a logout button to the sidebar by updating the sidebarPanel as follows:

sidebarPanel(
  h3(textOutput("welcomeText")),
  br(),

  # Existing inputs
  fileInput("file", "Upload Expense Data (CSV)", accept = ".csv"),
  selectInput("category", "Select Category:", choices = NULL),
  actionButton("analyze", "Analyze"),

  # Logout button
  actionButton("logout", "Logout", icon = icon("sign-out-alt"))
)

Next, add a descopeLogout message handler in the descope-auth.js file that will be invoked when the logout button is clicked:

Shiny.addCustomMessageHandler('descopeLogout', function () {
  const wcElement = document.querySelector('descope-wc');
  if (wcElement) {
    wcElement.logout();
  }
});

Finally, add a logout observer under the server definition to invoke the descopeLogout and initDescopeAuth message handlers.

observeEvent(input$logout, {
  hide("appContent")  # Hide main content
  session$sendCustomMessage("descopeLogout", list())

  session$sendCustomMessage("initDescopeAuth", list(
    projectId = "P2pBl7sYVGg1RWtv4jC7zfO9TnUN",
    flowId = "sign-up-or-in",
    theme = "light",
    containerId = "authContainer",
    successInput = "user_authenticated",
    errorInput = "auth_error"
  ))
})

Save and republish the changes to test them. Once you log in to the dashboard, you'll notice a Logout button being displayed next to the Analyze button.

When you click the Logout button, you'll be logged out of the application and redirected to the Descope login page.

Make Shiny authentication simpler with Descope

Shiny makes it easier for data engineers and scientists to share their work with others as web applications without any HTML or JavaScript experience. Posit Connect is a publishing platform that lets you deploy Shiny apps directly from RStudio with a click of a button, eliminating the need to provision and maintain a web server.

In this article, you learned how to implement authentication and authorization in a Shiny app using Descope. You can find this tutorial's complete source code on GitHub.

Descope is a drag-and-drop customer authentication and identity management platform. Our low- or no-code CIAM solution helps hundreds of organizations easily create and customize their entire user journey using visual workflows—from authentication and authorization to MFA and federated SSO. Customers like Navan, GoFundMe, You.com, and Branch Insurance use Descope to reduce user friction, prevent account takeover, and get a unified view of their customer journey. To learn more, book a demo with our auth experts or join our dev community, AuthTown.

Add Authentication and SSO to Your Flet App

Mrunank Pawar — Fri, 24 Apr 2026 15:00:00 +0000

This blog was originally published on Descope.

Creating cross-platform applications has become much easier with frameworks like Flet. Flet allows developers to build modern web, desktop, and mobile apps using Python. Its simplicity and flexibility help developers focus on creating great user experiences without having to worry about platform-specific complexities.

However, as your application grows, so does the need to secure it. Adding secure authentication to your application helps to protect sensitive data by ensuring that only authorized users can access it. Descope is a modern authentication and user management platform that simplifies the integration of secure authentication features into your application. By providing out-of-the-box support for OAuth 2.0 and OpenID Connect (OIDC), Descope offers a reliable solution for implementing authentication in your Flet app.

In this guide, you will learn how to integrate Descope authentication and single sign-on (SSO) into a Flet application. You'll learn how to add basic authentication to your Flet app using Descope magic links and social login. You'll also configure Descope to use Okta as the identity provider (IdP), enabling SSO for your Flet app.

Why is adding SSO important for these types of apps?

SSO is essential for B2B applications that serve multiple companies. Each company may already use its own IdP—such as Okta, Google, or Azure—for authentication. By adding SSO, your application allows users to log in with existing credentials, which eliminates the need to create and manage separate accounts. This simplifies the onboarding process and enhances security by relying on trusted authentication providers.

SSO also improves the user experience by providing seamless access to different services within an organization. It allows employees to use their company credentials to log in, which reduces password fatigue and IT support overhead.

For businesses handling sensitive data, SSO ensures centralized access control, which makes it easier to enforce security policies while maintaining a smooth login process.

Prerequisites

To complete this tutorial, you need the following:

A Descope account
An Okta Developer account
Python 3 installed on your local machine
Git CLI installed on your local machine
A code editor and a web browser

Creating a Flet application

This tutorial uses a prebuilt starter template so you can focus on implementing authentication. To clone the starter template to your local machine, execute the following command:

git clone --single-branch -b starter-template https://github.com/kimanikevin254/descope-flet-auth-sso.git

cd into the project folder, set up a virtual environment, activate it, and install the project dependencies:

cd descope-flet-auth-sso

python3 -m venv venv

source venv/bin/activate

pip install -r requirements.txt

Here's an overview of the most important files in this project:

main.py: Sets up a simple Flet app with two views: a main view and a profile view. The MyApp class initializes the app, sets the page theme to light, and handles route changes and view pops. When the route changes (for example, when navigating to /profile), it updates the view accordingly, either showing the profile or the main view. It uses the AuthManager class to handle user authentication (login/logout). The route_handler method switches views based on the current route, and view_pop allows navigating backward through views. Finally, the run method starts the app with the main view.
auth/auth_helpers.py: Defines an AuthManager class that manages the auth-related functions. The handle_login method navigates the user to the /profile route while the handle_logout method navigates the user to the / route.
views/main_view.py: Displays a message with a login button that calls the handle_login method when clicked.
views/profile_view.py: Displays a message with a logout button that calls the handle_logout method when clicked.

You can run the application using the following command:

flet run -w --port 8550

This command opens the web version of the app. To view it, navigate to http://localhost:8550 on your browser, and you should see the demo application homepage with a Login button:

Click the Login button and you should be navigated to the profile page:

Right now, the profile page is accessible to anyone, which is not ideal. In the next section, you'll implement authentication to restrict access to authorized users.

Setting up Descope

To implement authentication in your Flet app, you first need to create a project and design a flow on your Descope console. To get started, launch your Descope console, click the project dropdown, and select + Project to create a new project:

On the Create project page, provide "descope-flet-auth-sso" as the project name and click Create to create the project:

The next step is to design a Descope flow. Flows define the authentication process. You're going to add support for three authentication methods: magic links, social login, and SSO. You need to design a flow that will support all the authentication methods.

Typically, you would need to design this flow from scratch, but to make it easy for you to follow along, this tutorial uses a pre-prepared flow, which is included in the starter template. You can find it in the project root folder in a file named sign-up-or-in.json. You just need to import this flow into the Descope console. To do this, navigate open the default sign-up-or-in flow in the flow editor by navigating to Flows > sign-up-or-in:

In the editor, select Import flow / Export flow > Import flow and upload the flow from your local machine:

The flow you imported presents three login methods on the welcome screen: magic link, SSO, and social login. If the user selects the magic link, an email is sent to the provided address. When the user clicks the link in the email, they are asked for additional details if they're a new user. If they're not new, the flow returns a JSON Web Token (JWT) and ends. For social login or SSO, the user is redirected to the appropriate provider. After successful authentication, they receive a JWT, and the flow ends.

Authentication with Descope

Now that you have implemented the authentication flow in the Descope console, you can go ahead and configure your Flet app to use Descope as an OAuth provider. Flet allows you to implement authentication with any identity provider that supports the OAuth 2.0 Authorization code flow. By default, Flet ships with a few built-in OAuth providers, such as Azure and Google, but it also allows you to configure a custom OAuth provider, like Descope.

To configure a custom OAuth provider, you need to configure the following in your Flet app:

Client ID: A public identifier for the application
Client secret: A secret that is only known to the application and the authorization server
Authorization endpoint: The endpoint that initializes the authorization flow
Token endpoint: The endpoint that exchanges an authorization code for access tokens
User endpoint: The endpoint that retrieves the authenticated user's information
Redirect URL: The URL where the user is redirected to after authentication
User ID function: A function that extracts the user ID from the returned user dictionary

To integrate Descope as the authentication provider for your Flet app, you first need to configure an OIDC app in the Descope dashboard to obtain the necessary endpoints required for the authorization code flow. To do this, navigate to Applications > OIDC default application on the Descope console:

Scroll down to the SP Configuration section and take note of the Client ID, Authorization URL, and Access Token URL. You will use these values in your Flet app.

For the user endpoint, you'll use https://api.descope.com/oauth2/v1/userinfo, which is discussed along with the other endpoints in the Descope documentation.

You also need to generate a client secret. You can do this by navigating to M2M > + Access Key. On the Generate Access Key form, provide the key name, select Generate Key, and copy the value of your key.

Now that you have these values, you can go back to your Flet app and start implementing authentication. First, create a new file named .env in the project root folder and add the following code:

OAUTH_CLIENT_ID="<YOUR-DESCOPE-CLIENT-ID>"
OAUTH_CLIENT_SECRET="<YOUR-DESCOPE-CLIENT-SECRET>"
OAUTH_AUTHORIZATION_ENDPOINT="https://api.descope.com/oauth2/v1/authorize"
OAUTH_TOKEN_ENDPOINT="https://api.descope.com/oauth2/v1/token"
OAUTH_USER_ENDPOINT="https://api.descope.com/oauth2/v1/userinfo"
OAUTH_REDIRECT_URI="http://localhost:8550/oauth_callback"
OAUTH_USER_ID_FIELD="sub"
OAUTH_SCOPES="openid profile email"

Some of the values have been prefilled for you as they will be the same for everyone. However, the client ID and client secret will be unique to you. Make sure you replace the placeholder values with the values you obtained from the Descope console.

You also need a utility file to extract the environment variables and make them available for use in different parts of the application. Create a new file named config.py in the project root folder and add the following code:

from dotenv import load_dotenv
import os

load_dotenv()

class Config:
    @staticmethod
    def get_env_var(name, default=None, required=True):
        value = os.getenv(name, default)
        if required and value is None:
            raise ValueError(f"Environment variable '{name}' is required but not set.")
        return value

    OAUTH_CLIENT_ID = get_env_var('OAUTH_CLIENT_ID')
    OAUTH_CLIENT_SECRET = get_env_var('OAUTH_CLIENT_SECRET')
    OAUTH_AUTHORIZATION_ENDPOINT = get_env_var('OAUTH_AUTHORIZATION_ENDPOINT')
    OAUTH_TOKEN_ENDPOINT = get_env_var('OAUTH_TOKEN_ENDPOINT')
    OAUTH_USER_ENDPOINT = get_env_var('OAUTH_USER_ENDPOINT')
    OAUTH_REDIRECT_URI = get_env_var('OAUTH_REDIRECT_URI')
    OAUTH_USER_ID_FIELD = get_env_var('OAUTH_USER_ID_FIELD')
    OAUTH_SCOPES = get_env_var('OAUTH_SCOPES')

This code loads environment variables from a .env file and defines a Config class with a method to retrieve them, raising an error if a required variable is missing. It then uses this method to set various OAuth-related settings as class attributes.

To define a custom OAuth provider, create a new file named auth_provider.py in the auth folder and add the code below:

from flet.auth import OAuthProvider as BaseOAuthProvider
from config import Config

class OAuthProvider(BaseOAuthProvider):
    def __init__(self):
        super().__init__(
            client_id=Config.OAUTH_CLIENT_ID,
            client_secret=Config.OAUTH_CLIENT_SECRET,
            authorization_endpoint=Config.OAUTH_AUTHORIZATION_ENDPOINT,
            token_endpoint=Config.OAUTH_TOKEN_ENDPOINT,
            user_endpoint=Config.OAUTH_USER_ENDPOINT,
            redirect_url=Config.OAUTH_REDIRECT_URI,
            user_id_fn=lambda u: u[Config.OAUTH_USER_ID_FIELD],
        )

This code defines an OAuthProvider class that inherits from the Flet OAuthProvider class and initializes it with OAuth configuration settings from the Config class.

Open the auth/auth_helpers.py file. Here, you will modify the methods to log in and log out the user instead of just navigating them. First, replace the import statements with the following:

from flet import Page, LoginEvent
from config import Config

Then, replace the handle_login method with the following to trigger the login process using the OAuth provider configured for the page:

def handle_login(self, e):
    self.page.login(self.page.oauth_provider)

Replace the handle_logout method with the following to log the user out by calling the logout function on the page:

def handle_logout(self, e):
    self.page.logout()

In the same class, add the following methods to configure methods that will be called when the user is successfully logged in or out:

def on_login(self, e: LoginEvent):
    if e.error:
        raise Exception(e.error)

    self.page.go('/profile')

def on_logout(self, e):
    self.page.go('/')

These methods handle login and logout events: on_login checks for errors during login and navigates to the /profile route if successful, while on_logout redirects the user to the home route (/).

Open the views/profile_view.py file and replace the get_view method with the following:

def get_view(self):
    return ft.View(
        route='/profile',
        vertical_alignment=ft.MainAxisAlignment.CENTER,
        horizontal_alignment=ft.CrossAxisAlignment.CENTER,
        controls=[
            ft.Column(
                alignment=ft.MainAxisAlignment.CENTER,
                horizontal_alignment=ft.CrossAxisAlignment.CENTER,
                controls=[
                    ft.CircleAvatar(
                        foreground_image_src=self.page.auth.user.get("picture", ""),
                        bgcolor=ft.Colors.GREY_400,
                        radius=40
                    ),
                    ft.Text(value=self.page.auth.user.get("name", "N/A"), size=20, weight=ft.FontWeight.BOLD),
                    ft.Text(value=self.page.auth.user.get("email", "N/A"), size=18),
                    ft.ElevatedButton(text="Logout", on_click=self.handle_logout),
                ],
            )
        ]
    )

This method returns a view for the profile page that displays the authenticated user's profile picture, name, and email in the center of the page, along with a Logout button.

Open the main.py file and add the following import statement:

from auth.auth_provider import OAuthProvider

Add the following line of code to the __init__ method just before self.auth_manager = AuthManager(page=self.page) to create an instance of the OAuth provider and attach it to the current page:

self.page.oauth_provider = OAuthProvider()

Register the event handler you created earlier to the page by adding the following code at the end of the __init__ method:

self.page.on_login = self.auth_manager.on_login
self.page.on_logout = self.auth_manager.on_logout

Finally, you need to protect the /profile page to make sure it cannot be accessed by unauthenticated users. To do this, in the route_handler method, replace the first block of the if statement with the following:

if self.page.route == '/profile':
    if(self.page.auth is None):
        return self.page.go(route='/')
    view = ProfileView(self.page, self.auth_manager.handle_logout)
    self.page.views.append(view.get_view())

This code checks if the current route is /profile; if the user isn't authenticated, it redirects them to the home page. Otherwise, it loads the ProfileView and appends it to the page.

At this point, you should be able to log in to the application using either magic links or social login. In the next section, you will implement SSO.

Implement SSO with OIDC using Descope

OIDC is a simple identity layer built on top of OAuth 2.0. It helps enable SSO by allowing users to authenticate through trusted IdPs, such as Azure or Okta. With Descope, you can easily integrate OIDC SSO into your app, letting users log in securely with their existing credentials, which streamlines access without the need for new accounts.

In this section, you'll implement SSO by configuring Okta as the IdP and Descope as the authentication service. To do this, open your Okta admin dashboard and navigate to Applications > Applications > Browse App Catalog:

On the Browse App Integration Catalog page, search for "descope" and select the Descope app:

On the app details page, select Add Integration:

On the Add Descope page under General Settings, leave the default settings and click Next:

On the Sign-On Options page, select OpenID Connect as the sign-on method, and under Advanced Sign-on Settings, in the Callback URL field, provide the value https://api.descope.com/v1/oauth/callback. This is where the user will be redirected after successful authentication by Okta.

Scroll down to the bottom of the page and click Done.

On the app details page, select the Sign On tab and take note of the client ID and secret.

You'll also need a tenant to use SSO. Back on your Descope console, navigate to Tenants > + Tenant. On the Create Tenant form, provide the tenant name and click Create:

Open the details page of the tenant you just created and under Tenant Settings. Make sure you add your email domain to the list of allowed domains and click Save:

Next, still on the tenant details page, select Authentication Methods > SSO > OIDC. Under Tenant Details > SSO Domains, make sure to provide your email domain. This domain is used to determine which SSO configuration to load once a user chooses to authenticate using SSO.

Scroll down to the SSO configuration > Account Settings section and provide the required values as follows:

Provider Name: Okta
Client ID: The Client ID you obtained from the Okta dashboard
Client Secret: The client secret you obtained from the Okta dashboard
Scope: openid profile email
Grant Type: Authorization code

You also need to provide the required values for the SSO configuration > Connection Settings section. For this, you need to obtain OAuth endpoints from the Okta "well-known" configuration, which provides standardized metadata for OAuth and OIDC integrations. To obtain this, navigate to https://<YOUR-OKTA-INSTANCE>.okta.com/.well-known/openid-configuration on your browser and take note of the issuer and authorization, token, user info, and JWKs endpoints.

Make sure to replace <YOUR-OKTA-INSTANCE> with the correct value, which is your organization's Okta instance ID.

Go back to the Descope console and provide the values you just obtained from the Okta well-known endpoint in the respective inputs under SSO configuration > Connection Settings and save the changes.

To ensure that only authorized users can authenticate via the app and access your Flet application, you assign users to the Descope app you installed in your Okta console. To do this, open the app details page in Okta and select Assignments > Assign > Assign to Groups:

On the Assign Descope Groups page, select the Assign button beside the Everyone group to allow all users in your organization to log in via SSO and click Done to save the changes.

SSO with Okta as the IdP is now fully configured.

Adding a persistent login feature

Currently, the app does not save the access token obtained from Descope. So if a user logs in, leaves the app, and then returns, they will need to log in again. To improve the user experience, you can add a function that saves the access token to client storage.

However, you cannot store the token in client storage as plain text as this would make it vulnerable to malicious actors who could access and manipulate it. Instead, you need to encrypt the token using a secret key and save the encrypted value securely.

Open the .env file in the project root folder and add the following:

OAUTH_TOKEN_SECRET="cv3Gc9RG-9o8icwTBUEDb0HJC7M5A0b2FxT3WpWvg1I="
OAUTH_TOKEN_KEY="auth_token"

Values for these variables have been provided, but you can change them to any string.

OAUTH_TOKEN_SECRET will be used to encrypt the access token before saving it to the client storage, while OAUTH_TOKEN_KEY is the key under which the encrypted token will be saved in the client storage.

To load the environment variables you just created into the Flet application, open the config.py file and add the following attributes to the Config class:

OAUTH_TOKEN_SECRET = get_env_var('OAUTH_TOKEN_SECRET')
OAUTH_TOKEN_KEY = get_env_var('OAUTH_TOKEN_KEY')

Open the auth/auth_helpers.py file and add the following import statements:

from flet.security import encrypt, decrypt

encrypt and decrypt are utility methods provided by Flet for encrypting text data using a symmetric algorithm. This means that the same key is used for encryption and decryption.

Replace the on_login method with the following to modify the on_login method to encrypt and save the token to client storage once a user is successfully authenticated:

def on_login(self, e: LoginEvent):
    if e.error:
        raise Exception(e.error)

    # Save token in client storage
    token = self.page.auth.token.to_json()
    encrypted_token = encrypt(token, Config.OAUTH_TOKEN_SECRET)
    self.page.client_storage.set(Config.OAUTH_TOKEN_KEY, encrypted_token)

    self.page.go('/profile')

This code retrieves the access token, encrypts it using the secret key you set earlier, and stores the encrypted token in client storage. It then redirects the user to the profile page.

Replace the handle_login method with the following to modify the handle_login method to check if a valid token is stored in the client storage before redirecting the user to the sign-in page:

def handle_login(self, e):
    saved_token = None

    # Retrieve token from client storage
    encrypted_token = self.page.client_storage.get(Config.OAUTH_TOKEN_KEY)

    # Decrypt retrieved token
    if encrypted_token:
        saved_token = decrypt(encrypted_data=encrypted_token, secret_key=Config.OAUTH_TOKEN_SECRET)

    # Log in the user
    if e is not None or saved_token is not None:
        self.page.login(provider=self.page.oauth_provider, saved_token=saved_token, scope=Config.OAUTH_SCOPES.split())

This code retrieves the saved encrypted token from the client storage, decrypts it, and passes it to the self.page.login method. This way, if the token is valid, the application will obtain the user's info without prompting the user to reauthenticate.

Lastly, replace the handle_logout method with the following to modify the handle_logout method to make sure that it removes the token from storage when a user logs out:

def handle_logout(self, e):
    self.page.client_storage.remove(Config.OAUTH_TOKEN_KEY)
    self.page.logout()

Persistent login should now be working as expected.

Demonstrating the application

You can run the application to confirm that everything is working as expected.

Run the application using the command flet run -w --port 8550, navigate to http://localhost:8550 on your browser, and click the Login button. You should be redirected to the sign-in page:

Here, you can choose to sign in with any method, and after successful authentication, you will be redirected to the profile page, where your details are displayed:

You can stop the application and run it again. Then, on the home route, click the Login button. You will be redirected to the profile page without being prompted to sign in again.

You can access the full code on GitHub.

Conclusion

Implementing authentication and SSO into your Flet app using Descope is a straightforward process that significantly enhances your application's security and user experience. By integrating features like magic link authentication, social logins, and SSO with OIDC, you can offer your users seamless and secure access, whether they are individuals or part of an organization using their existing credentials.

Descope is a drag-and-drop customer authentication and identity management platform. Our no- or low-code CIAM solution helps hundreds of organizations easily create and customize their entire user journey using visual workflows—from authentication and authorization to MFA and federated SSO. Customers such as GoFundMe, Navan, You.com, and Branch use Descope to reduce user friction, prevent account takeover, and get a unified view of their customer journey. To learn more, join our dev community, AuthTown, and explore the Descope documentation.