alisha-tingle

Alisha Tingle is a Senior Customer Advocate at Auth0 with 10 years of client-facing experience in the tech industry. In her role, she focuses on reigniting self-service customer growth, expanding self-service reach to developers, and generating enterprise growth. Outside of work, Alisha is passionate about teaching pilates and spending time with her family.

Senior Customer Advocate, DLG

Alisha Tingle

Discover the key signals that show your product is ready to move beyond the Auth0 Free plan. Learn how upgrading can enhance security, ensure compliance, and unlock new opportunities for growth.

Is Your Product Hitting Its Limits? A Guide to Upgrading Your Auth0 Plan

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Learn what DPoP is and how it works under the hood to enhance your application security and  mitigate the effects of access token theft.

As a developer, you're likely familiar with OAuth 2.0 and the use of access tokens to secure APIs. As you may know, the usage model for traditional OAuth 2.0 access tokens is defined in [RFC 6750](https://tools.ietf.org/html/rfc6750), where a **bearer token** is defined as a simple string that grants access to the "bearer" of the token.

For years, this has been the standard way to use access tokens. It's simple and effective, but it has a fundamental weakness: if a token is stolen, an attacker can use it to impersonate the legitimate user or application. Tokens can be leaked in numerous ways: through a compromised client device, insecure log files, a [person-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack), or a malicious browser extension. Once leaked, a bearer token is a golden ticket for an attacker.

## Beyond Bearer Tokens

To address this critical vulnerability, the concept of **sender-constraining** tokens was developed. The goal is to ensure that a token can only be used by the party it was originally issued to. If we compare an access token to a keycard to access your hotel room, it's like using a keycard that only works when accompanied by your unique fingerprint. Several mechanisms have been proposed to achieve this, but one has emerged as a flexible, powerful, and modern standard: **Demonstrating Proof-of-Possession (DPoP)**, standardized in [RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html).

DPoP is a security mechanism that cryptographically binds access and refresh tokens to the specific application instance that requested them. It does this by requiring the client to prove it possesses a secret private key every time it uses the token. This proof is lightweight, works at the application layer, and is perfectly suited for today's diverse application landscape, from server-side web apps to mobile apps and Single-Page Applications (SPAs).

This article will take you on a deep dive into DPoP. We'll explore the security threats it mitigates, dissect its inner workings with code examples, compare it to other sender-constraining methods, and walk through a practical guide on how to implement it in your applications using Auth0.

## The Benefits of DPoP

Adopting DPoP isn't just about adding another layer of security; it's about fundamentally hardening your application against a whole class of common attack vectors. The benefits are tangible and address real-world threats.

### Enhanced security against token theft

This is the primary reason DPoP exists and is also recommended by the [Best Current Practices for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700#name-sender-constrained-access-t). Let's consider a few concrete scenarios where bearer tokens are vulnerable and how DPoP protects them:

* **Cross-Site Scripting (XSS):** An attacker injects malicious code into a web page, which then steals an access token from the browser's local storage or memory. With a bearer token, the attacker can now make API calls on behalf of the user. With DPoP, the stolen token is useless because the attacker doesn't have the client's private key required to generate the DPoP proof.  
* **Compromised Log Files or Databases:** A developer might accidentally log an `Authorization` header containing a bearer token. If these logs are breached, the token is exposed. Similarly, if a database storing tokens is compromised, they are all at risk. A DPoP-bound token, even if exposed, cannot be used without the corresponding private key, which should never be logged or stored alongside the token.  
* **Malicious Browser Extensions:** A seemingly harmless browser extension could have permissions to inspect network traffic or memory, allowing it to exfiltrate tokens. Again, using DPoP, the stolen token is inert without the proof-of-possession key.

By binding the token to the client's key, DPoP prevents an access token from being used by an unauthorized party.

### Flexibility for modern applications

Other attempts at sender-constraining, like [Mutual TLS (mTLS)](https://auth0.com/docs/secure/sender-constraining/mtls-sender-constraining), operate at the transport layer (the [TLS handshake](https://auth0.com/blog/the-tls-handshake-explained/)). This is very secure but also rigid. It requires managing X.509 certificates on the client, which is straightforward for server-to-server (confidential) clients but a nightmare for public clients like SPAs running in a browser or mobile applications. Browsers provide very limited APIs for managing cryptographic keys and client certificates, making mTLS impractical for these use cases.

DPoP, by contrast, operates at the **application layer**. The "proof" is just a JWT sent in an HTTP header. This means:

* **Any client can implement it:** JavaScript in a browser can use the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API), a mobile app can use native cryptographic libraries, and a backend server can use standard JWT libraries.  
* **It works through intermediaries:** Modern infrastructure often includes proxies, gateways, and load balancers that might terminate the original TLS connection from the client. In such a setup, the mTLS binding is lost. DPoP, being part of the application-level data (i.e., HTTP headers), passes through these intermediaries untouched, maintaining end-to-end security.

### No complex Public Key Infrastructure (PKI) required

mTLS relies on a [Public Key Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) (PKI). This means clients need to obtain a certificate from a trusted Certificate Authority (CA), which vouches for their identity. This involves generating certificate signing requests (CSRs), managing certificate lifecycles (issuance, renewal, revocation), and configuring trust stores. For large-scale applications with thousands or millions of clients, this operational overhead is significant and costly.

DPoP completely sidesteps this complexity. Each client application instance simply generates its own public/private key pair on the fly. There is no CA, no certificate chain to validate, and no complex infrastructure to maintain. The resource server trusts the public key for the lifetime of the token because the client proved possession of the private key at the time of the token request.

### Protection for high-value refresh tokens

Refresh tokens are often more valuable targets than access tokens because they are long-lived and can be used to mint new access tokens. DPoP can also be used to sender-constrain refresh tokens. When a client uses a DPoP-bound refresh token to get a new access token, it must also provide a DPoP proof. This ensures that even if a refresh token is stolen from a client's storage, it cannot be used by an attacker to maintain persistent access to the user's account.

### FAPI 2.0 ready

Sender constraining is one of the requirements of [FAPI 2.0](https://openid.net/specs/fapi-security-profile-2_0-final.html), the security framework built on top of OAuth 2.0 and designed for high-security applications to protect sensitive data and financial transactions. DPoP is one of the mechanisms allowed in FAPI 2.0 to implement sender constraining.

> Auth0 provides you with support for FAPI 2.0 through [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity). Read [this blog post to learn more about Auth0’s support for FAPI 2.0](https://auth0.com/blog/fapi-2-0-the-future-of-api-security-for-high-stakes-customer-interactions/).

## How DPoP Works

The magic of DPoP lies in a special, short-lived JSON Web Token called the **DPoP proof JWT**. This ephemeral JWT serves as irrefutable evidence of the client's ownership of a specific private key. When a client intends to access a protected resource, it first generates this DPoP proof JWT, signing it with its private key. This signed proof is then transmitted alongside the access token to the resource server.

To understand the behavior of DPoP, we need to look at its key parts. Our exploration will start with a detailed examination of the DPoP proof JWT's structure, becoming familiar with the various claims that contribute to its cryptographic integrity. Following this, we will analyze the DPoP flow, considering two stages: 

* the initial **access token request**, where the client obtains its access token while simultaneously establishing its cryptographic identity,   
* the subsequent **token usage**, where the client leverages both the access token and the DPoP proof JWT to securely interact with the resource server.

## The Anatomy of a DPoP Proof JWT

A DPoP proof is a standard JWT, but with specific claims and header parameters tailored for this purpose.

The header identifies the token as a DPoP proof and contains the public key. Here is an example of a decoded header:

```json
{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": {
    "kty": "EC",
    "x": "l8tFrhx-34tV3hRICRDY9zC_qjKipZWEvVunexs60A8",
    "y": "Hlnr5TL2ncfXj_i9W2nL1pW2QYj45s4T2l5MIa4WVKw",
    "crv": "P-256"
  }
}
```

Here is the meaning of the claims:

* `"typ": "dpop+jwt"`: This type explicitly declares the JWT's purpose. Servers can immediately reject any JWT in the `DPoP` header that doesn't have this type.  
* `"alg"`: This specifies the signing algorithm. It **must** be an asymmetric algorithm (e.g., ES256). Symmetric algorithms are forbidden because they would require the server to know the client's secret, defeating the purpose.  
* `"jwk"`: This is the [JSON Web Key](https://datatracker.ietf.org/doc/html/rfc7517), which is the public key corresponding to the private key used to sign the proof. This is how the client shares its public key with the server for validation.

The payload contains claims that bind the proof to a specific HTTP request, preventing it from being stolen and replayed in a different context. Here is an example of DPoP proof payload:

```json
{
  "jti": "5a2c4187-2418-4568-a5b7-f4a4d61858b1",
  "htm": "POST",
  "htu": "https://your-tenant.auth0.com/oauth/token",
  "iat": 1678886400
}
```

Here is the description of the claims in the payload:

* `"jti"` (JWT ID): A unique identifier for this specific JWT. This is crucial for **replay prevention**. A server should keep track of jti values it has recently seen and reject any duplicates.  
* `"htm"` (HTTP Method): The HTTP method (GET, POST, PUT, etc.) of the request to which this proof is bound. This prevents a proof created for a GET request from being used on a POST request.  
* `"htu"` (HTTP Target URI): The full URL of the endpoint being called, excluding query parameters and/or fragments. This can be the token endpoint or the API endpoint, as you will see shortly. This ensures a proof intended for `https://api.example.com/orders` cannot be used for `https://api.example.com/users/delete`.  
* `"iat"` (Issued At): A timestamp indicating when the JWT was created. Servers should reject proofs that are too old (e.g., older than a few seconds) to further mitigate replay attacks.

> Optionally, at the request of the [authorization server](https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-server-provid) or the [resource server](https://datatracker.ietf.org/doc/html/rfc9449#name-resource-server-provided-no), the payload of the DPoP proof JWT can include a nonce claim. Its value is generated by the server and sent to the client via the DPoP-Nonce HTTP header. The nonce aims to mitigate replay attacks in public clients, i.e., SPA and native apps.

The final part of the JWT is the signature, created by signing the base64-encoded header and payload with the private key that corresponds to the public key stored in the `jwk` claim of the header. **This is the cryptographic "proof" of possession**.

## Requesting a DPoP-Bound Access Token

Now that we know the structure of a DPoP proof JWT, let’s see how to use it for protecting our requests and access tokens. As we mentioned earlier, we will analyze the DPoP flow in two stages. The first stage is about requesting an access token from the authorization server. Following the diagram below, let’s analyze the steps of the flow.

![A sequence diagram illustrating the OAuth 2.0 security flow for requesting a DPoP-bound access token, showing the key generation and DPoP proof submission.](https://images.ctfassets.net/23aumh6u8s0i/7ERtf626Ra1xdORkMXxJsB/2a86d45120dc10a673253c6b0d149f9c/access-token-request-with-dpop.png)

1. In the first step, the client application **generates a new public/private key pair**.  
2. The client **constructs the DPoP proof JWT** for the token endpoint. The DPoP proof JWT is signed with the client’s private key and contains the corresponding public key.  
3. The client makes a POST request to the `/oauth/token` endpoint. It includes the standard parameters (`grant_type`, `code`, etc.) and adds the newly created `DPoP` proof in a DPoP HTTP header. The following snippet shows an example of access token request with the DPoP header:

```HTTP
POST /token HTTP/1.1 
Host: your-tenant.auth0.com 
Content-Type: application/x-www-form-urlencoded 
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...  

grant_type=authorization_code 
&code=3LgurgEWbtafaqTn2VxkASV 
&redirect_uri=https%3A%2F%2Fapp.example.com
```

4. The authorization server validates the DPoP proof JWT by verifying the signature using the public key stored in the `jwk` claim of the header. It also verifies that the target URL and HTTP method of the current request match the `htu` and `htm` claims in the payload.  
5. If the request is valid, it generates an access token. The authorization server also generates a SHA256 [thumbprint of the client's public key](https://datatracker.ietf.org/doc/html/rfc9449#name-jwk-thumbprint-confirmation-). This information will be used to confirm the binding of the client's public key with the issued token. In case the issued access token is an opaque string, the authorization server includes this information in the response returned by the [token introspection endpoint](https://datatracker.ietf.org/doc/html/rfc7662). If the issued token is a JWT, the authorization server adds a `cnf` (confirmation) claim to the access token's payload, as shown in the following snippet:

```json
{
  "iss": "https://your-tenant.auth0.com/",
  "sub": "user|12345",
  "aud": "https://api.example.com/orders",
  "exp": 1678890000,
  "iat": 1678886400,
  "scope": "read:orders",
  "cnf": {
    "jkt": "N_i4l4295g9kE2xStSIyYAnr727xO0I5n82x4NaIphE" // SHA-256 thumbprint of the JWK
  }
}
```

The access token is ready to be used by the client to securely access the user’s resources.

## Using the DPoP-Bound Access Token

Let’s see how the access token is used to access a protected resource by following the numbered steps in this diagram:

![A sequence diagram showing how a DPoP-bound access token is used to prevent access token theft during an API call, highlighting the DPoP proof validation at the resource server.](https://images.ctfassets.net/23aumh6u8s0i/5GgT1vzY4xdEHmvs9DjdiM/d3551f170703e51a6b8d81083c6306df/api-call-with-dpop-bound-token.png)

1. As the first step, the client application **creates a new DPoP proof JWT** using the same key pair previously generated. This is a critical point. The client cannot reuse the old proof. For every API request, it must create a **new** DPoP proof with a fresh `jti` and `iat`, and with `htm` and `htu` matching the API endpoint it's about to call.  
2. The client application **sends the request to the resource server** (the API). It includes two important headers:  
   * `Authorization: DPoP \<access\_token\>`. Instead of the classic `Bearer` scheme, the `DPoP` scheme is used. This signals the server that it must perform DPoP validation.  
   * `DPoP`: The newly generated DPoP proof for this specific request.

The following is an example of an API request with a DPoP-protected access token:

```HTTP
GET /protectedresource HTTP/1.1 
Host: api.example.com 
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K0pXVCIsImNuZiI6eyJqa3QiOiJybW56aTJvSWNYW...
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...
```

3. When the resource server receives the request, it performs a **comprehensive validation**. To the usual [token validation checks](https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens), it adds the following ones:  
   * Checks for the presence of the `cnf` claim. If it's missing, this isn't a DPoP-bound token.  
   * Verifies the DPoP proof's signature using the `jwk` in its header.  
   * Computes the SHA-256 thumbprint of the `jwk` from the DPoP proof and compares it with the `jkh` value inside the access token's `cnf` claim. **They must match.** This is the step that confirms the presenter of the token is the same one it was issued to.  
   * Validates that the `htm` and `htu` in the DPoP proof match the current API request's method and URL.  
   * Checks the `iat` and `jti` to prevent replay attacks.  
4. Only if all these checks pass, the API processes the request and **returns the protected resource**. A stolen token will fail to access a DPoP-protected resource because the attacker cannot produce a valid DPoP proof signed by the correct private key.

> Take a look at [this interactive tutorial, which shows the full DPoP flow](https://dpop.info/) for getting an access token and calling a protected API.

<include src="ebook-ads/Oauth2OidcGuide" />

## Conclusion

The era of relying solely on bearer tokens is drawing to a close, especially for applications handling sensitive data. The risks of token theft are too significant to ignore. DPoP provides a robust, flexible, and developer-friendly solution to the problem of sender-constraining tokens. It effectively mitigates threats from XSS, compromised devices, and log leaks by cryptographically binding tokens to the client that requested them.

By operating at the application layer, DPoP offers broad compatibility across all types of clients&mdash;from back-end services to browser-based SPAs and native mobile apps&mdash;without the heavy infrastructure requirements of transport-layer solutions like mTLS.

With platforms like Auth0 offering built-in support, implementing this advanced security measure is no longer a daunting task. By enabling DPoP, you take a significant and proactive step towards building more secure, resilient applications that protect both your users and your systems.

Protect Your Access Tokens with DPoP (Demonstrating Proof of Possession)

william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

This post explores why traditional APIs are insufficient for AI agents. It highlights how MCP resolves issues like excessive choices and manual translation, while also addressing new security considerations for agent-based architectures.

Developer’s building with AI have probably had this thought when a new standard like Anthropic's [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) (MCP) comes along: "This looks interesting, but why can't I just use an API like I always have?"

It's a fair question, and the logic holds up on the surface. Why not just give a large language model (LLM) an OpenAPI spec and let it figure out how to make the right requests?

The problem is that this approach runs into some major real-world roadblocks. An interface built for a human developer to write code against fundamentally differs from a protocol an AI agent needs to reason with.

Here’s the bottom line: a traditional API is a set of instructions for you, a developer. MCP is a language for your AI agent. Let's break down why that distinction is so crucial for building applications that actually work.

## Where Traditional APIs Fall Short for Agents

Using a standard API to give an LLM a new capability can feel like a square peg in a round hole. Here are some of the real-world friction points you'll run into.

**1. The "Paradox of Choice" Kills Performance:** You'd think giving your agent more tools would make it smarter. It doesn't. It just makes it more confused. An enterprise API can easily have 75-100 endpoints, and LLMs are surprisingly bad at choosing from a long list of options. Faced with too many choices, they slow down, struggle to differentiate between similar tools, and often pick the wrong one or fail to act at all. You're then forced to manually curate a tiny list of tools, which defeats the purpose of having a rich API in the first place.

**2. The Manual Translation Burden:** Your API docs are written for a human developer who can infer context and Google things. An AI agent can't do that. So, you become a full-time translator, writing a wrapper for every tool and meticulously describing its purpose, parameters, and output. This isn't just tedious; it's a brittle system that breaks every time the underlying API changes.

**3. Your Agent is Flying Blind:** Your agent can't ask your API, "What's new?" or "What can you do for me?" It only knows about the tools you've hard-coded for it. This prevents your agent from adapting or taking advantage of new capabilities, limiting its potential autonomy and usefulness.

![](https://images.ctfassets.net/23aumh6u8s0i/49MGI1wViFinBA4RIf5njS/dfd22ed0f3a5443914fcc77c88847af2/5.png)

## How MCP Solves These Problems

MCP isn't just a different API; it's a different approach designed specifically for how an agent "thinks."

**1. It Abstracts Complexity for Better Reasoning:** This is where MCP really shines. Instead of overwhelming the LLM with 100 low-level tools, you give it a handful of powerful, high-level capabilities. For instance, you wouldn't give it separate tools for `createUser`, `updateUserAddress`, and `resetUserPassword`. Instead, you'd offer one simple capability: `manageUserProfile`. Your agent invokes that one capability, and the MCP server handles the underlying logic. This simplifies the agent's job and lets it focus on the goal, not the implementation details.

A perfect example is creating an AI-native workflow that wouldn't make sense in a standard API. An LLM is bad at writing complex SQL. Instead of a single `run_sql` tool, an MCP could offer a multi-step `database_migration` capability that first stages the SQL on a test branch, asks the LLM to verify it, and only then commits it with a final command. This guides the agent to success by meeting it at its level of reasoning.

**2. It Enables Dynamic Discovery:** An agent can connect to an MCP server at runtime and ask, "What can you do?" It can learn about the capabilities available to it on the fly. This makes your whole system more adaptable, allowing you to add new tools without having to redeploy your agent's code.

**3. It Standardizes Communication:** Using the "USB-C for AI" analogy, MCP creates a universal protocol for agent-to-tool communication. This reduces the need for custom wrappers for every service, leading to a more robust and scalable ecosystem.

![](https://images.ctfassets.net/23aumh6u8s0i/6AJJCeSj8TLKSft8zueg2y/6041a58a24c29bf76615020b0069f09c/4.png)

## The Security Question: Who is This Agent, Anyway?

This new architecture brings new security questions to the forefront. When an agent can discover and use tools on its own, you need to be able to answer:

* How do we ensure the agent is truly authorized to act for a specific user?

* How do we enforce granular permissions so an agent can only use the tools it's been allowed to, for the user it's serving?

These aren't just theoretical questions; they represent the next real-world challenge for AI security. To solve them, we need to think about how to apply familiar identity concepts in this new agentic context. This means using established patterns like OAuth 2.0 for token delegation to give an agent specific, limited permissions and ensuring a user's identity is securely bound to the entire lifecycle of a conversation.

To learn more about the core principles of securing AI applications, explore the Auth0 [Auth for GenAI documentation](https://auth0.com/ai/docs/).

For a practical, hands-on example of implementing these security patterns, read our guide on [how to secure and deploy a remote MCP Server with Auth0 and Cloudflare](https://auth0.com/blog/secure-and-deploy-remote-mcp-servers-with-auth0-and-cloudflare/), which walks you through the entire process of building a secure bridge between an AI application and an external API.

<include src="LinkCard" link="https://auth0.com/blog/secure-and-deploy-remote-mcp-servers-with-auth0-and-cloudflare/" title="Secure and Deploy Remote MCP Servers with Auth0 and Cloudflare" description="Learn secure and deploy a remote MCP Server with Auth0 and Cloudflare" img="https://images.ctfassets.net/23aumh6u8s0i/4Zx5ftWCROXV42kSnTRh1L/9cba9c24f32d1b2c3baf86759c653f80/Co-Branded_Template_-_Cloudflare.png" />

## MCP Is the Right Interface for Your AI Agent

Ultimately, MCP is not a replacement for your API, but a necessary abstraction layer designed for a new consumer: the AI agent. Building an effective server requires more than just a one-click conversion of an OpenAPI spec. The emerging best practice is a hybrid approach: start with your existing spec, but aggressively curate the toolset to avoid overwhelming the LLM. Abstract your low-level endpoints into high-level, task-oriented capabilities, and commit to continuous evaluation to ensure your agent performs reliably. This thoughtful design is the key to unlocking the true potential of autonomous AI applications.

Why Can't I Just Use an API? Because Your AI Agent Needs MCP

raphael-do-vale

Raphael has more than two decades of experience in developing enterprise systems including coding, project planning, architecture, and specification. His technology stack includes Java, Spring, Python, Relational Databases, JavaScript, DevOps, and Artificial Intelligence. He has a PhD and Master's degree in the Semantic Web, winning awards during his studies. He also worked with Description Logic, Prolog, RDF, and OWL tech.

Raphael do Vale

Learn how to build a secure tool-calling AI agent using LangChain, FastAPI, and Python. You’ll learn how to protect a FastAPI API with Auth0 and to implement agent frontend that uses LangChain tool calling to interact with it securely.

In this tutorial, you’ll learn how to integrate LangChain into your existing stack even if your endpoints require authenticated users with specific roles.

By the end of this post, you’ll have two running projects built with FastAPI: an API, protected with Auth0 as the application backend, and a small frontend, that will use LangChain for tool calling and will be used by users. The frontend will send user prompts to be processed by LangChain that in turn will invoke the protected API.

The code is available [in this repository](https://a0.to/zoo-ai) for you to follow along. The code already has most of the system implemented, with placeholder sections designed to guide you through implementing authentication via LangChain. The repository will have two branches to help your study: one to begin with and another with the end result, to compare to what you have done.

If you are getting started with tool calling, I recommend you read the blog post linked below  before continuing to better understand tool calling in AI agents and how security is currently handled.

<include src="LinkCard" link="https://auth0.com/blog/genai-tool-calling-intro" title="Tool Calling in AI Agents: Empowering Intelligent Automation Securely" description="Discover how AI agents are taking center stage by seamlessly integrating with multiple digital tools like Gmail, Calendar, Slack, and Google Drive to be more efficient. Learn why it is important to secure them and how to do it." img="https://images.ctfassets.net/23aumh6u8s0i/4LrNhImjPcdPVpmCIrhlG9/4efed8dfb26630e6cf48b4a478a1f550/genai-tool-calling-intro.png" />

## Zoo AI: Our Demo Application

For this tutorial, we created a system solely for demonstration purposes. Zoo AI is a fictional zoo management platform that helps staff manage daily operations and respond to various situations. The platform has four main roles: 

* Veterinarians - Handle animal health and medical care.
* Coordinators - Oversee operations and can trigger emergency protocols.
* Janitors -  Maintain cleanliness and hygiene.
* Zookeepers - Provide daily care and feed the animals.

Any staff member can interact with our AI to report when something is happening or when some staff may need to take actions. Also, anything that happens to the animals needs to be logged.

## Prerequisites

You will need the following tools and services to build this application:

* Python 3.11 or later
* [Poetry for dependency management.](https://python-poetry.org/) Check [how to install](https://python-poetry.org/docs/#installation).
* An Auth for GenAI account. [Create one](https://a0.to/ai-content).
* An OpenAI account and API key. [Create one](https://platform.openai.com/) or use any [other LLM provider supported by LangChain](https://js.langchain.com/docs/integrations/llms/).
* [Our git repository](https://a0.to/zoo-ai), cloned 

## Zoo AI Technological Stack

The Zoo AI management platform consists of two projects: API and Agent. Both projects have a similar stack to make the platform as simple as possible for demonstration purposes.

Both projects will also use the same Poetry environment to simplify set up. Poetry is completely optional but makes dependency management easier. You can check [the Poetry website](https://python-poetry.org/) for more details.

#### API Project (auth0-zoo-ai/api) Stack

*   **FastAPI**: Web framework for building the REST API
*   **Auth0-fastapi-api**: Authentication and authorization backend with the [Auth0 FastAPI SDK](https://github.com/auth0/auth0-fastapi-api)
*   **TinyDB**: Local NoSQL database for persistence
*   **Pydantic**: For data validation and serialization

Once you setup Auth0 following the steps on this blog post the API will work without requiring updates to the code so you can focus on what really matters: the agent we are building.

#### Agent Project (auth0-zoo-ai/agent) Stack

*   **LangChain**: Framework for building the AI agent
*   **OpenAI**: Language model integration
*   **FastAPI**: Web framework for exposing agent endpoints
*   **Requests:** Library for HTTP requests
*   **Auth0-fastapi**: Authentication and authorization for Web Applications

This provides the base structure for the Agent and you are going to make some modifications to it in order to securely perform tool calls, continue reading to learn how.

## Getting Started

Clone [the repository](https://a0.to/zoo-ai) and install the dependencies. All dependencies needed are already 
set in `pyproject.toml`.

```bash
git clone https://github.com/auth0-samples/auth0-zoo-ai
cd auth0-zoo-ai
git switch step1-firstparty-toolcalling
poetry install
```

Using branch `step1-firstparty-toolcalling` you’ll have both projects configured with all dependencies. To test it, we need to set up authentication and a few environment variables.

## Setting Up Auth0 Authentication for the FastAPI API

Before moving forward, we need to set up a few things in the Auth for GenAI account you created in the prerequisites section.

Note: Since Auth for GenAI is in developer preview, you need to use [this link](https://a0.to/ai-content) and sign up for a new tenant as it will have enabled all the features you’ll need.

We need to create a new API. The Agent will use this API to obtain an access token to perform actions on behalf of the user. Go to the API section in **Applications** and click on **Create API**.

![API creation in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/54zmd09YFHooDo4JsKc7A7/3d211e86b43af40c9abbd47a5ef8708e/Uploaded_from_2025-06_AI_Content_Doc)

We need to set the name and the identifier. The identifier is the audience of the token. We will use it to set the audience of the token in the Agent project. Although the identifier is similar to a URL, it doesn’t have to be. It is just a string that will be used to identify the API.

* Name: Zoo Management API
* Identifier: [https://zoo-management-api](https://zoo-management-api)

![API creation form filled](https://images.ctfassets.net/23aumh6u8s0i/6ulWc71y62kZOLYfVzCX7t/a6b16a55c964d20ad8eccd0c1df0d51d/Uploaded_from_2025-06_AI_Content_Doc)

After clicking Create you’ll be taken to the API page. Navigate to the Settings tab check **Allow Offline Access** so we can generate Refresh Tokens for this API.

![Allow Offline Access toggled ON](https://images.ctfassets.net/23aumh6u8s0i/22ZOSvZnWKYcY2T9uctL1l/583580d7179192c730bc0158644f0357/Uploaded_from_2025-06_AI_Content_Doc)

Now we have to set up roles and inject them into our application access token.

In the Auth0 Dashboard, go to the **User Management** section and click in **Roles**.

![Roles page on the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/4gNAovUJIyUjSKVGfIovaL/7037fd9f84d99ebd66a34cf0a77e00e0/Uploaded_from_2025-06_AI_Content_Doc)

Now, click on **Create Role** and set the name `COORDINATOR`.

![Role creation form](https://images.ctfassets.net/23aumh6u8s0i/3bHDEmwnuoiuPlrZcYVn8p/66098d134f34ad9096eb9c2474b7b581/Uploaded_from_2025-06_AI_Content_Doc)

Do the same for all remaining roles: janitor, veterinarian, zookeeper. Keep the same name for both as they will be identified by it.

![List of all created roles](https://images.ctfassets.net/23aumh6u8s0i/545npYHoaQPzrE2mhBcxlM/e74b44e85f756e52afa125bdbf094aa5/Uploaded_from_2025-06_AI_Content_Doc)

To finish, we need Auth0 to add the role as a custom claim in the ID and access tokens.

<include src="LinkCard" link="https//auth0.com/blog/adding-custom-claims-to-id-token-with-auth0-actions/" title="Adding Custom Claims to ID Tokens with Auth0 Actions" description="Learn how to create a new custom action that will add a custom claim to your Auth0-issued ID Token" img="https://images.ctfassets.net/23aumh6u8s0i/1hMPYApOKrcrGV6Koi2Ekt/041eb09b09ae149d3d497beae72ee221/Introducing_Auth0_Actions02A.png" /><br>

Go to **Actions > Library** section. In the **Create Action** button, select **Build from scratch**.

![Menu to create new Action](https://images.ctfassets.net/23aumh6u8s0i/1oRq3RuWvQPgyPjXOUElxC/9b8dfef26ba16edd3c21881d628417c5/Uploaded_from_2025-06_AI_Content_Doc)

Give the action a name (e.g. _Add user role_) and select the **Trigger Login / Post Login**

![Action creation form](https://images.ctfassets.net/23aumh6u8s0i/5Ner8Wa4sTU2Oet4Xwt3hK/b8dfe18ec1f6042250d7e4db26891e1d/Uploaded_from_2025-06_AI_Content_Doc)

You will be prompted to a code editor screen. Add the following code:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://zooai/roles';
  if (event.authorization) {    
    api.accessToken.setCustomClaim(namespace, event.authorization.roles);
    api.idToken.setCustomClaim(namespace, event.authorization.roles);
  }
};
```

Click on **Deploy** and the code will be ready to be used.

To actually use the Auth0 Action you just created, we need to set up a **Trigger** for it. Go to **Actions > Triggers** and click on the post-login trigger.

![Actions Triggers](https://images.ctfassets.net/23aumh6u8s0i/BzZLQtBwuXjHLDZpVL9MQ/fcaf0331537bb69ef09d4e7abc54f4f0/Uploaded_from_2025-06_AI_Content_Doc)

Now, just drag and drop the custom action **Add user role** to the authentication flow and hit **Apply**.

![Adding action to the flow](https://images.ctfassets.net/23aumh6u8s0i/2pdwtSApg2K0KbckaP7TPY/4d5adc372c5a7199890842f436ae65f7/Uploaded_from_2025-06_AI_Content_Doc)

The action code will then be executed every time a token is generated and will add the claim `https://zooai/roles` to the access and ID tokens. You should always use a namespace (e.g. `https://zooai/`) to avoid conflicts with other claims.

Auth0 is configured. Now we need to test our code before making changes to it.

## Setting up API Project

Create a `.env` file in the `api/` folder with the following content:

```bash
AUTH0_DOMAIN=YOUR_AUTH0_TENANT_DOMAIN
API_AUDIENCE=https://zoo-management-api
```

To get `AUTH0_DOMAIN` you can access any **Application**, access Settings menu and copy the **Domain** value.

![Application page in the Dashboard](https://images.ctfassets.net/23aumh6u8s0i/OnjeEV9YsTYyZ1b3GnQYb/f5c472e360adce8c0d9c1b177141f778/Uploaded_from_2025-06_AI_Content_Doc)

Now run the API by typing the following instructions at the terminal:

```bash
cd api
poetry run uvicorn main:app
```

## Setting up Agent Project

Create the `.env` file in the agent folder:

```bash
touch agent/.env
```

And add the following content to it:

```txt
# Auth0
AUTH0_DOMAIN="YOUR_AUTH0_DOMAIN"
AUTH0_CLIENT_ID="YOUR_AUTH0_CLIENT_ID"
AUTH0_CLIENT_SECRET="YOUR_AUTH0_CLIENT_SECRET"
APP_BASE_URL="http://localhost:3000"
APP_SECRET_KEY="use [openssl rand -hex 32] to generate a 32 bytes value"
# OpenAI
OPENAI_API_KEY="YOUR_OPEN_AI_KEY"
API_AUDIENCE="https://zoo-management-api"
API_BASE_URL="http://localhost:8000"
```

Now, run the Agent service. The API project should still be running as both will communicate with each other:

```bash
cd agent
poetry run uvicorn main:app --reload --port 3000
```

Before using the application, we need to create some users in Auth0, each one with the roles you need. Go to **User Management > Users** and create as many users as you want. In the user page, go to the **Roles** tab and assign the role you desired. The project only supports one single role per user:

![Role assignment](https://images.ctfassets.net/23aumh6u8s0i/4PTlzT0lHoGxNJ9DibluZ4/1377dff7c22c4415efdc04dc0d964fab/Uploaded_from_2025-06_AI_Content_Doc)

Now, go to the browser and open the URL [http://localhost:3000/](http://localhost:3000/). You should see the application running. On the first time, you will be redirected to the Auth0 login page. After login, you will be redirected to the application and you should see the notifications for the user role. Go play with it and see how it reacts to many different queries. However, the LLM will only be able to talk with you without any access to our API. For that, we need to implement tools.

## Implementing Secure LangChain Tool Calling in Python

In our agent project, we need to create the `zoo_tools.py` file. This file will have all the tools that will call our API. Most importantly, these tools will be able to get the access token of the current user and forward it to the API.

Put the following code inside this file:

```python
import logging
import os

import requests
from dotenv import load_dotenv
from langchain_core.runnables import RunnableConfig
from langchain_core.tools import tool
from pydantic import BaseModel, Field

load_dotenv()

logger = logging.getLogger(__name__)

API_BASE_URL = os.getenv("API_BASE_URL")


def _get_headers(config: RunnableConfig) -> dict:
	access_token = config.get("configurable", {}).get("api_access_token")
	return {"Authorization": f"Bearer {access_token}"}
```

The section above contains the imports and the environment variable we are going to use to set the API base URL. We also defined the `get_headers` function, which is responsible for retrieving the user access token and creating a header for the API. We are going to explain how this access token is passed later. Now, we must define the tools that translate the API endpoints into LangChain tools.

```python
@tool
def list_animals(event: str, config: RunnableConfig) -> list[dict]:
	"""Get the list of all animals and their IDs."""
	try:
    	    logger.info("list animals %s", event)
           response = requests.get(f"{API_BASE_URL}/animal",    headers=_get_headers(config))
    	    response.raise_for_status()
    	    return response.json()
	except Exception as e:
     	    logger.exception("error")
    	    raise e
```

The LangChain Tool is a decorator that indicates that this function can be used by GenAI. You should always add docstrings so the agent can understand what the function does, that’s how the LLM will pick between one tool or the other. 

```python
class UpdateAnimalStatusArgs(BaseModel):
	animal_id: str = Field(..., description="ID of the animal to update")
	event_description: str = Field(
    	..., description="Clear and concise description of the event"
	)


@tool(args_schema=UpdateAnimalStatusArgs)
def update_animal_status(
	animal_id: str, event_description: str, config: RunnableConfig
) -> str:
	"""Add an event to an animal."""
	logger.info("add animal event %s", event_description)
	response = requests.post(
    	f"{API_BASE_URL}/animal/{animal_id}/status",
    	headers=_get_headers(config),
    	json={"status": event_description},
	)
	response.raise_for_status()
	return "event added"


class NotifyStaffArgs(BaseModel):
	event: str = Field(..., description="Event to notify staff about")
	staff_role: str = Field(
    	...,
    	description="Role of the staff to notify. Can be COORDINATOR, VETERINARIAN, JANITOR or ZOOKEEPER",
	)


@tool(args_schema=NotifyStaffArgs)
def notify_staff(event: str, staff_role: str, config: RunnableConfig) -> str:
	"""Notify a staff group about an event at the zoo."""
	logger.info("notify staff %s", event)
	response = requests.post(
    	f"{API_BASE_URL}/staff/notification/{staff_role}",
    	headers=_get_headers(config),
    	json={"description": event},
	)
	response.raise_for_status()
	return "notification sent"
```

We need to define the arguments that will be passed to the `update_animal_status` tool. We use Pydantic to define the arguments and the tool decorator to indicate that this function can be used by the LLM. LangChain will automatically parse the arguments and pass them to the function and the configured GenAI will be able to understand each argument. The `notify_staff` tool is similar to the `update_animal_status` tool. Since we need the exact name values for the role, we instruct the LLM which values are allowed.

Now, let's take a look at the `agent.py` file. This file will have all configuration of our LangChain with features like memory and graph (from LangGraph) definition. We need to make two changes to it. 

First, we need to register our tools into the tools list. You can change the following code:

```python
tools = [
	## ADD YOUR TOOLS HERE
]
```

To this:

```python
from zoo_tools import list_animals, notify_staff, update_animal_status

tools = [
	list_animals,
	update_animal_status,
	notify_staff,
]
```

Moreover, we need to pass the access token to the Configuration used by LangChain to pass and receive context between the graph.

Change this:

```python
config = {
    	"configurable": {
        	"thread_id": user_id,
    	}
}
```

To this:

```python
config = {
    	"configurable": {
        	"thread_id": user_id,
"api_access_token": token,
    	}
}
```

The token variable is already passed as an argument to our function, you can check in `main.py` file how we obtain it using Auth0 libraries.

Now you can test the agent again by running the command below:

```bash
poetry run uvicorn main:app --reload --port 3000
```

Your application should be ready to be used. You can login with the user you created in Auth0 and you should see the notifications of the user role. Go play with it and see how it reacts to many different queries!

![Zoo AI notification page](https://images.ctfassets.net/23aumh6u8s0i/72zb9J8kaSLY7mJD0x0lGn/e3dfb70457480a2436c1479ab5c63f9b/Uploaded_from_2025-06_AI_Content_Doc)

Note: All the code is on branch `step2-firstparty-toolcalling` of our repository.

## Recap

In this blog post you learned how to create a FastAPI API with the use of Dependency Injection and [Role-Based Access Control (RBAC)](https://auth0.com/docs/manage-users/access-control/rbac) with OAuth and Auth0. To use this API, you learned how to set up and deploy a LangChain application integrated with OpenAI and Auth0. This application enabled the LLM to securely connect to your API with context.

If you are building with GenAI you should check out our brand new product [Auth for GenAI](http://a0.to/ai-content), to enable AI agents to securely access tools, workflows, and data with fine-grained control and just a few lines of code.

You can take a look at [the code that was used in these demos on GitHub](https://a0.to/zoo-ai) to try it out for yourself and stay tuned because we will have more content on tool calling in Python in future blog posts.

Secure LangChain Tool Calling with Python, FastAPI, and Auth0 Authentication

Bradford Peirce

Product Marketing Manager, Retail

Artificial intelligence is here to stay in the retail industry. It must be secured.

Securing AI Agents: Retail's Next Big Challenge

Dive into the structure of an OAuth 2.0 authorization request to understand its key parameters and why this knowledge is crucial for developers, even when using SDKs.

While modern SDKs and libraries abstract much of the complexity of OAuth 2.0, a good understanding of the underlying authorization request structure remains essential for developers. When issues arise, such as unexpected redirects, token rejection, or other error messages, having insight into the raw request helps in troubleshooting.

This mostly depends on [what type of developer you are](https://auth0.com/blog/zen-and-the-art-of-identity-management/), of course. It's like opening the hood of your car to diagnose a problem. You don't have to be a mechanic or even an engineer to understand every little detail of your car's engine. But being able to determine whether the engine is overheating because of insufficient coolant or the car won't start because a battery cable has come loose can help you speed up the troubleshooting process, sometimes even without the need for expert intervention.

Let's take a look at what's under the hood of an OAuth 2.0 authorization request.

## The Authorization Request Under X-Ray

I assume you have a basic understanding of OAuth 2.0. If not, you can read a quick [introduction to the authorization framework](https://auth0.com/docs/authenticate/protocols/oauth) and [its flows](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use). If you want to go more in depth, check out [OAuth 2.0 and OpenID Connect: The Professional Guide](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide).

> While this article mentions OAuth 2.0, you will also find details related to OpenID Connect and other OAuth extensions. This is because it’s very common to see the two protocols interconnected. After all, OpenID Connect is nothing but an OAuth 2.0 specialization.

It all starts when a client application redirects a user's browser to the authorization server to begin the authorization process. The authorization request is usually a GET HTTP request sent to the authorization endpoint of the authorization server, although it may be a POST HTTP request too.

The following picture shows a typical authorization request:

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/3AdUXr1YF3wbKqCw1ajkht/8b088f0ddfe7da8232906b89230172a6/authorization-request-breakdown.png" alt="Diagram of an OAuth 2.0 authorization request showing the endpoint and parameters like client_id, response_type, and scope." style="width:80%; margin: .9em auto;">
</picture>

As you can see from the picture above, the authorization request structure expresses what the client application wants to achieve. You can highlight the main elements of its structure with something vaguely reminiscent of the [5 Ws](https://en.wikipedia.org/wiki/Five_Ws) of journalism:

* **Who** is making the request?  
* **What** artifact is requested?  
* **How** is the artifact returned?  
* **Where** will the artifact be sent?  
* **Why** is the artifact needed?

In addition to these fundamental elements of the request, there are other elements that help improve its security posture.

## The Core of an Authorization Request

With reference to the authorization request example mentioned in the previous section, let’s break down the elements that compose it.

### The authorization endpoint

The first element of the request we analyze is the authorization server URL: `https://my-tenant.auth0.com/authorize`.

This is an ordinary URL that includes the authorization server’s domain (`my-tenant.auth0.com`) and the authorization endpoint (`/authorize`). As in any common HTTP request, this URL identifies the server’s endpoint to which the client is sending its authorization request.

In the URL example, I’ve used an Auth0 subdomain as the authorization server domain, but in general it will be the domain where the authorization server is reachable. In the context of Auth0, you can use your [custom domain](https://auth0.com/docs/customize/custom-domains), for example.

Regarding the authorization endpoint, while the `/authorize` endpoint is pretty common, this name is not required by the specifications, which leaves OAuth 2.0 server implementors [free to use the name they prefer](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1).

> In an OpenID Connect context, you can take advantage of the [discovery protocol](https://openid.net/specs/openid-connect-discovery-1_0.html) that allows you to use the `/.well-known/openid-configuration` document to find the authorization URL and other configuration settings.

### The client ID

The parameter `client_id` responds to the question, **Who** is making the request? It identifies the client application that submits the authorization request. The authorization server generates this ID for your application and uses it to retrieve its specific configuration settings.

This is a **required** parameter.

### The response type

The parameter `response_type` answers the question, **What** artifact is requested? It specifies the [type of authorization flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) desired and determines what information will be returned by the authorization server (the artifact).

The parameter can take one of the predefined values `code` or `token`. The value `code` indicates that the client application wants to receive an authorization code, and consequently use the [Authorization Code flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) or its [variant with PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). The value `token` requests an access token and refers to the [Implicit flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post), which is generally no longer recommended except in very specific cases.

The parameter `response_type` can also have [a custom value](https://datatracker.ietf.org/doc/html/rfc6749#section-8.4) as a sequence of strings separated by spaces. For example, OpenID Connect, which is an extension of OAuth 2.0, [defines the value `id_token` and some combinations of values](https://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html).

This parameter is **required**.

### The response mode

The parameter `response_mode` tells the authorization server **how** the requested artifact should be returned. This parameter [has been added later to the original OAuth 2.0 specification](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html), and its possible values are:

* `fragment`. This value tells the authorization server to attach the requested artifact as a fragment to the `redirect_uri` (see below). In other words, you will get for example an authorization code as follows:

  `https://my-app.com/callback#we7fhHdi2rl6Adywyy1p0ff`

  The value `fragment` is associated with the Implicit flow and is not recommended for several reasons, including information leaking and size limitations.  
* `query`. This value tells the authorization server to return the requested artifact as a parameter of the query string of the `redirect_uri`. The following is an example of authorization code returned as a parameter in the query string:

  `https://my-app.com/callback?code=we7fhHdi2rl6Adywyy1p0ff`

  Returning the artifact as a parameter of the query string has similar security concerns as the fragment option, although techniques like [Proof Key for Code Exchange (PKCE)](https://datatracker.ietf.org/doc/html/rfc7636) help mitigate the risks.

* `form_post`. This value requests the authorization server to return the artifact as an HTML form value and send it via POST. This value [has been added](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) to overcome the security concerns affecting the `fragment` and `query` modes.  
  The following is an example of response from the authorization server:

```http
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-cache, no-store
Pragma: no-cache

<html>
 <head><title>Submit This Form</title></head>
 <body onload="javascript:document.forms[0].submit()">
  <form method="post" action="https://my-app.com/callback">
    <input type="hidden" name="state"
     value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
    <input type="hidden" name="id_token"
     value="eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiw
       iYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLC
       ...
       0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNRe0iKb47XRXaoz5acA"/>
  </form>
 </body>
</html>

```

The `response_mode` parameter is **optional**, so what is the default response mode from the authorization server when the parameter is not specified? It depends on the response type sent by the client application. The following table summarizes the default response mode corresponding to each `response_type` value:

<style>
  table {
    width: 80%;
    margin: 2.4rem auto !important;
    border-collapse: collapse;
    font-size: 15px;
  }
  table, td, th {
    border: 1px solid;
  }
  table th {
    line-height: normal;
    padding: .8em;
  }
  td {
    padding: .8em;
    line-height: normal;
  }
</style>

| *response\_type* | default *response\_mode* |
| :---- | :---- |
| code | query |
| token | fragment |
| id\_token | fragment |
| code token | fragment |
| code id\_token | fragment |
| id\_token token | fragment |
| code id\_token token | fragment |

> Note that the upcoming [OAuth 2.1 specification will deprecate](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13) the `token` response type, so all the response types containing `token` will be deprecated as well.

### The redirect URI

The `redirect_uri` parameter specifies **where** the authorization server will send the artifact. This is a very important parameter that defines the exact address in your application where the artifact is expected to be returned. Since this URL will receive sensitive data (authorization code or tokens), it is imperative to use HTTPS. OAuth 2.0 and OpenID Connect are strict about `redirect_uri` validation: the URI specified in the request must be an exact match of a pre-registered value on the authorization server. This strictness prevents malicious actors from hijacking tokens by redirecting them to an unintended location.  
This parameter is **required**.

### The scopes

The `scope` parameter explains **why** the client application is submitting this request. Consider that OAuth 2.0 (and consequently OpenID Connect) enables a client to work on behalf of a user, so the client must specify the user permissions it needs to perform its activities.

The value of the `scope` parameter is a sequence of strings separated by spaces expressing the needed permissions. OAuth 2.0 does not define the syntax of these strings, so you can freely define them. However, OpenID Connect defines [a few reserved scopes](https://auth0.com/docs/get-started/apis/scopes/openid-connect-scopes).

This parameter is **optional**, however it is [highly recommended to use it to enforce the principle of least privilege](https://auth0.com/blog/oauth2-access-tokens-and-principle-of-least-privilege/). If you don’t specify the `scope` parameter in your authorization request, the resulting behavior is [up to the specific authorization server](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3).

## The Security Parameters

The parameters described in the previous section are the core parameters of an authorization request. They reflect the essential elements the authorization server needs to formulate a response after the user’s approval.

However, additional parameters are crucial too to guarantee the security of the request/response transaction. Let’s explore the most common ones.

### The state

The `state` parameter has a unique value generated by the client application. Its primary function is to maintain session state between the client’s request and the server’s response, and to mitigate [Cross-Site Request Forgery (CSRF) attacks](https://auth0.com/blog/cross-site-request-forgery-csrf/). The authorization server must  include the same value in its response to the client to ensure that it’s related to the original request.

This parameter is not mandatory but **recommended**.

### The nonce

The `nonce` parameter has been introduced by the OpenID Connect specifications and it acts as an alternative to the `state` parameter for preventing CSRF and token injection attacks. Its unique value is generated by the client at request time. The authorization server will include the exact value of the `nonce` parameter in the `nonce` claim of the ID token. By comparing the value of the parameter with the value contained in the ID token, the client application is guaranteed that the ID token comes from its original request.

This parameter is **required** for the [Implicit flow](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest) and in some cases of the [Hybrid flow](https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest), while it’s **optional** in other flows.

### The PKCE protection

An authorization request can include the `code_challenge` and `code_challenge_method` parameters. These parameters are needed to implement [Proof Key for Code Exchange](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) (PKCE), an OAuth 2.0 extension that prevents authorization code interception attacks.

To implement PKCE, the client application generates a unique `code_verifier` value and sends its hashed version (`code_challenge`) to the authorization server. The client also includes the `code_challenge_method` parameter to let the authorization server know what hashing algorithm it used. The possible values for the `code_challenge_method` parameter are:

* `plain`, which means no hash,   
* `S256`, which means that the SHA256 algorithm has been used.

The `S256` value is the recommended value.

When the client application will exchange the authorization code for an access token, it will provide the `code_verifier` to prove it is the original requester.

PKCE also acts as a protection measure against CSRF attacks, so it may be used as an alternative to the `state` and the `nonce` parameters, assuming that the authorization server supports it.

The `code_challenge` parameter is **required** for public client like mobile and browser apps using the Authorization Code flow and unable to secure client secrets. While optional for confidential clients, it’s highly **recommended**.

## Additional Parameters

The parameters discussed so far can be considered the minimum essential parameters for formulating an authorization request and ensuring its security. However, you may encounter other parameters whose necessity and meaning depend on specific contexts. We won't examine all the other possible parameters you might find in an authorization request, but we'll simply mention a few to give you an idea of what to expect

### The prompt

The `prompt` parameter has been introduced by OpenID Connect and tells how the authorization server should interact with the user during authentication. Its possible values are:

* `none`. The authorization server must not display an authentication window. If the user is not already authenticated, an error will be returned.  
* `login`. The authorization server prompts the user for authentication even if they are already authenticated.  
* `consent`. The authorization server prompts the user for their consent before returning back to the application client.  
* `select_account`. The authorization server prompts the user to select an account if they have multiple of them.  
* `create`. The authorization server shows the user creation form instead of the login form.

Values for the prompt parameter can be combined. For example, you can find `prompt=login consent`, which tells the authorization server to always show the login and the consent forms. Of course, you can’t combine other values with `none`.

### The login hint

The `login_hint` parameter tells the authorization server what username to use to authenticate the user. Its value is used by the authorization server to prepopulate the login form. For example, you can find `login_hint=john.doe@example.com`, telling the authorization server to show a login form with the username set to `john.doe@example.com`.

### The request URI

The `request_uri` parameter has been introduced by the [Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126) (PAR) specification. This is a special parameter because it essentially replaces all other parameters except `client_id`. It is used in specific contexts where a high level of security is required. To learn more, I recommend reading [this article about Pushed Authorization Requests (PAR)](https://auth0.com/blog/what-are-oauth-push-authorization-requests-par/).

In short, PAR allows the client application to pre-register an authorization request and receive a request identifier from the authorization server. The `request_uri` parameter allows you to specify the identifier of the already registered request and thus express the authorization request, as in the following example:

```bash
https://my-tenant.auth0.com/authorize?
client_id=32tqG0PwnSoA2Ly4sw
&request_uri=urn%3Aietf%3Aparams%3Aoauth...4ltcg4eY28s
```

The authorization server will use the identifier specified in the `request_uri` parameter to detect the registered authorization request and consider the associated parameters.

<include src="ebook-ads/Oauth2OidcGuide" />

## Conclusion

Understanding the anatomy of the OAuth 2.0 authorization request is a foundational skill for any developer working with modern authentication and authorization. While SDKs simplify much of the implementation, knowing the purpose of each parameter—from `client_id` and `response_type` to `scope` and `nonce`—empowers you to troubleshoot effectively, design secure applications, and adapt to evolving standards like OAuth 2.1 and OpenID Connect. This knowledge moves you beyond simply using a library to truly mastering the underlying security flows that protect your applications and users. 

Anatomy of an OAuth 2.0 Authorization Request

Learn how to enable your customers to customize the login experience of your B2B SaaS application and integrate it into their systems by accessing your APIs.

Throughout this series, we've journeyed through [the foundational aspects of B2B identity](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), including multi-tenancy and onboarding, then delved into [granular access control with RBAC, ABAC, and ReBAC](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/), and most recently tackled [the critical demands of enterprise integration and advanced security](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/). Your Business-to-Business (B2B) Software-as-a-Service (SaaS) application is now robust, secure, and ready for demanding clients.

However, the ultimate success of a B2B application often hinges on its adaptability and seamless integration into a customer's environment. This means more than just functionality; it means brand consistency and programmatic access.

In this concluding article, we will explore the essential aspects of customization and extensibility, focusing on how to tailor the user experience and secure your backend APIs for machine-to-machine communication, ensuring your application is truly integrated and personalized for every customer.

## Branding and User Experience Customization

Your B2B customers will often expect a seamless brand experience, even on the login page. They want their users to feel like they are interacting directly with their application, not an external provider. This is also reflected in your application’s login pages: **How can I customize the login pages to match my customers' corporate identities?**

To be honest, in my previous experience in building a B2B SaaS application, we had a couple requests of this type. At that time, we decided to implement an additional set of login and reset password pages. Basically, they were customized versions of our default login page. As a result, we had to maintain more code and keep in sync with any updates we were going to apply to the default pages. It worked with some additional maintenance, but only because we had very few such requests. As a developer, you know that the more code you have, the more trouble you may get.

[Auth0's Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is designed for extensive customization, allowing you to maintain a consistent brand experience across all your customer organizations. Customizing Auth0 Universal Login for individual Organizations is a powerful feature for B2B SaaS applications, allowing you to provide a truly branded experience for each of your customers. You can customize it at different levels: 

* With a **no-code approach**, which allows you to change the logo and colors of the login page.  
* With an **advanced approach** by customizing the Universal Login page template with Liquid.  
* With more powerful control by using the **Advanced Customizations** for Universal Login feature, which gives you control over every pixel of your Universal Login experience.

But that’s not all. Auth0 also allows you to customize the emails that users receive from the platform very easily.

> Read the following documents to learn more about customizing the login experience for your customers:
> 
> * [Customize Universal Login](https://auth0.com/docs/customize/login-pages/universal-login)  
> * [Advanced Customization for Universal Login](https://auth0.com/docs/customize/login-pages/advanced-customizations)  
> * [Customize Prompts and Email Templates for Organizations](https://auth0.com/docs/manage-users/organizations/create-first-organization#customize-prompts-and-email-templates)

## API Security for Your SaaS Backend

In the context of customization, it is likely that some customers will ask you to access your application's APIs to connect them with their systems, for example, to exchange data automatically. The challenge now becomes: **How can I protect my backend API so that my customer’s applications can only access their data securely?**

Auth0 enables you to implement this feature by providing Machine-to-Machine (M2M) Access for Organizations. To determine the Organization your API is scoped to, you will find an `org_id` claim in the access token sent by the customer’s application.

> Here is more information about securing your API in the context of Organizations:
> 
> * [Machine-to-Machine (M2M) Access for Organizations](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications)  
> * [Work with Tokens and Organizations](https://auth0.com/docs/manage-users/organizations/using-tokens)

## Real-time User Lifecycle Management with Event Streams

Beyond offering your customers direct API access and UI customization, your B2B SaaS application may need to react to changes in user identity in real time. Imagine needing to synchronize user data with your CRM, trigger welcome emails based on signup events, or update internal billing systems when a user's status changes. Relying on polling APIs or manual data exports is inefficient and can lead to inconsistencies.

The challenge here is: **How can I reliably and efficiently propagate user lifecycle events from Auth0 to my internal systems or third-party applications?**

[Auth0 Event Streams](https://auth0.com/docs/customize/events) provide a solution to this. Event Streams allow you to subscribe to a real-time feed of events generated by Auth0, such as:

* User creation  
* User updates (e.g., profile changes)  
* User deletions  
* Password changes  
* Login successes and failures

These events are delivered to a destination of your choice, such as Amazon EventBridge or an HTTP endpoint. This enables you to build event-driven architectures, ensuring that your other services are always up-to-date with the latest identity information without complex polling logic. By leveraging Event Streams, you can automate critical workflows and maintain data consistency across your B2B SaaS ecosystem.

> Learn more about Auth0 Event Streams:
> 
> * [Auth0 Event Streams](https://auth0.com/docs/customize/events)  
> * [Discover User Lifecycle Changes via Event Streams – Now in Early Access](https://auth0.com/blog/user-lifecycle-changes-via-event-streams-in-early-access/)

# Conclusion

Our journey through the identity landscape of B2B SaaS has traversed from the fundamental need for user authentication to the sophisticated demands of enterprise integration and bespoke logic. What might initially seem like a peripheral concern — simply letting users log in — quickly reveals itself as the bedrock upon which the security, scalability, and ultimate success of your B2B application are built.

We started by understanding that **B2B identity is fundamentally different** from Business-to-Customer (B2C), centered around organizations rather than just individual users. We then progressed through key developmental phases: from [laying the foundation with multi-tenancy support](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/) to exploring [different approaches for granular access control](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/); from tackling the non-negotiable [integration needs for enterprise customers](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/) to facing the customization and extensibility requirements.

By embracing a robust identity solution from the outset, you’re not just solving a technical problem; you're laying a strategic foundation for your B2B SaaS application to thrive in a competitive and security-conscious market. Your focus can remain on delivering exceptional business value, confident that your users and their data are in safe hands.

I hope this series has provided valuable insights and practical solutions for navigating the complex world of identity in B2B SaaS.

Ready to secure your B2B SaaS and accelerate your development with a trusted identity partner? Explore [Auth0's comprehensive offerings](https://auth0.com/b2b-saas) and see how they can transform your approach to identity and access management.



B2B SaaS Identity Challenges: Customization and Extensibility

Delve into the specific challenges you may encounter to incorporate your B2B SaaS solution with an enterprise customer’s IT systems.

In our previous posts, we established [the foundational elements of Business-to-Business (B2B) identity](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), including multi-tenancy and streamlined onboarding, and then deep-dived into [granular access control using RBAC, ABAC, and ReBAC](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/). We've laid the groundwork for managing users and their internal permissions effectively.

Now, as your B2B Software-as-a-Service (SaaS) application matures and attracts larger enterprise customers, their expectations for security and integration will significantly increase. They won't just want a secure application; they'll demand it integrates seamlessly with their existing IT ecosystem. This article will focus on meeting these high-stakes requirements, exploring the critical aspects of enterprise integration and advanced security measures that are non-negotiable for large-scale B2B adoption.

## Single Sign-On (SSO): The Enterprise Mandate

You've successfully managed user authentication and authorization in your SaaS app, but sooner or later your first major enterprise customer will come to you with a non-negotiable demand: "Our employees must log in using their existing corporate credentials. We will not manage separate passwords for your application." This is the moment you confront the reality of [**Single Sign-On (SSO)**](https://auth0.com/docs/authenticate/single-sign-on). The new challenge is: **How can I enable my customers to use their existing enterprise identity provider without having to create custom integrations for each individual customer?**

In my past experience as a B2B SaaS developer, integrating with existing identity providers was a critical and challenging task. The code was getting more complicated every day because it had to take into account different protocols and configurations from customer to customer — not to mention the difficulty of testing the integrations.

Fortunately, Auth0 supports SSO through [Enterprise Connections](https://auth0.com/docs/authenticate/enterprise-connections). Auth0 acts as a universal adapter, supporting a wide array of enterprise protocols: SAML, OpenID Connect, WS-Federation, Active Directory/LDAP. By offloading this complexity to Auth0, you avoid becoming an SSO integration specialist for every customer, significantly accelerating enterprise onboarding and reducing development overhead.

> Some resources to learn more about SSO and Auth0 Enterprise Connections:
> 
> * [What Is Single Sign-On Authentication (SSO) And How Does It Work?](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/)  
> * [The Developer’s Guide to Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/auth0-guide-to-single-sign-on-sso)  
> * [Enterprise Connections](https://auth0.com/docs/authenticate/enterprise-connections)

## Delegated Administration: Empowering Your Customers

Having features like Enterprise Connections that save you from having to implement external IdP integrations for every customer is great, but having to interact with your B2B application support team for every change or new integration isn’t ideal for your customers. Now the challenge is: **How can I allow my customers to manage their own users, roles, and SSO configurations within my application without involving my support team?**

Delegated administration is the answer to this question. You should build a custom dashboard for your customers so that they can autonomously manage their users and configurations. Beyond giving your customers more control over their users and application configuration, delegated administration reduces the support burden on your side.

The B2B product I worked on in the past was limited to granting the customer delegated administration of their users. Other configuration settings had to go through our support, primarily due to the complexity of implementation.

Auth0 offers a few options to enable delegated administration for your customers, reducing the implementation complexity:

* **Custom Admin Portal with Auth0 Management API**. For more granular control or to tightly integrate user management into your existing application's admin interface, you can build a custom delegated administration portal using the [Auth0 Management API](https://auth0.com/docs/api/management/v2).
* **Self-Service Administration features**. Some features are specifically designed to allow your customers to be autonomous. One example is [Self-Service SSO](https://auth0.com/docs/authenticate/enterprise-connections/self-service-SSO), which enables customers to set up their own SSO connections. More self-service features are coming soon, so stay tuned to this blog for more.

> Here are some documents to learn more about enabling delegated administration with Auth0:
> 
> * [Empower Your Enterprise Customers to Set up Their Own SSO Implementations](https://auth0.com/blog/empower-your-enterprise-customers-to-set-up-their-own-sso-implementations/)
> * [Unlock Enterprise Readiness: How to Add Self-Service SSO to Your SaaS App](https://auth0.com/blog/how-to-add-self-service-sso-to-your-nodejs-saas-app/)
> * [Auth0 Management API](https://auth0.com/docs/api/management/v2) 

##  Enhancing Security: MFA, Adaptive Auth, and Threat Detection

The more enterprise customers you have, the higher the demands on the level of security your application offers in terms of account protection, threat prevention, and access monitoring. This is certainly your next challenge: **How do I protect my customers' data and accounts from common threats and enforce strong security policies without creating undue friction for legitimate users?**  
Auth0 provides a suite of security features designed to protect your application and its users:

* **Multi-Factor Authentication (MFA)**, which adds an additional layer of security beyond just a password, supporting a wide range of MFA factors (SMS, Push Notifications via Auth0 Guardian, Google Authenticator, Duo, WebAuthn/FIDO2, etc.).  
* **Adaptive MFA and Risk-Based Authentication**: a mechanism that prompts the user for MFA even if it's not normally required. This happens when an access attempt is deemed unusual or high-risk based on signals such as a new device, an unfamiliar location, a suspicious IP address, etc.  
* **Attack Protection**, which are built-in features that automatically detect and mitigate common threats: brute-force protection, breached password detection, bot detection, etc.  
* **Audit Logs**.  Auth0 provides comprehensive, immutable audit logs of all authentication and management events.

> To learn more on advanced security features supported by Auth0, check out these resources:
> 
> * [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication)  
> * [Attack Protection](https://auth0.com/docs/secure/attack-protection)  
> * [Auth0 Logs](https://auth0.com/docs/deploy-monitor/logs)

## Conclusion

In this third installment of "B2B SaaS Identity Challenges," we've navigated the complex landscape of enterprise-grade security and integration. We highlighted the imperative of Single Sign-On (SSO) for larger clients, demonstrating how Auth0's Enterprise Connections streamline this often-daunting task. We also explored how delegated administration empowers your customers to manage their own users, significantly reducing your support burden, and discussed critical security features like MFA, adaptive authentication, and threat detection.

With your B2B SaaS now equipped with robust authentication, granular authorization, and enterprise-level security, the final frontier often involves tailoring the user experience to meet diverse customer expectations. In our [next concluding article](https://auth0.com/blog/b2b-saas-identity-challenges-customization-and-extensibility/), we will explore how to personalize the login experience and secure machine-to-machine communication, ensuring your application not only functions flawlessly but also truly feels like an integral part of each customer's ecosystem.



B2B SaaS Identity Challenges: Enterprise Integration and Security

Learn about Relationship-Based Access Control (ReBAC): how it works, its benefits for flexible authorization, and how Auth0 FGA helps implement it effectively.

You know how on a git repository your permissions feel so intuitive? You're not just a generic 'user' across the whole application. You might be the owner of your own repo, a maintainer with merge rights on a team project, and only have permission to help organize the bug reports and feature requests on an open-source library you contribute to.

This whole system, where your permissions change based on your specific connection to a repo, a pull request, or an organization is the core idea behind Relationship-Based Access Control (ReBAC). It’s an authorization model based on how users work together. Access is defined by your relationship to the resource and not just what role you’re assigned.

ReBAC isn't the only choice for access control. It's one tool in a toolbox that includes other models like [RBAC](https://auth0.com/docs/manage-users/access-control/rbac) and [ABAC](https://auth0.com/blog/what-is-abac-and-how-to-implement-it-rails-api/#What-Is-Attribute-Based-Access-Control--ABAC--). As a developer, you might then ask, 'Which one is the right tool for my job?'"

To help you navigate that choice, we've put together a detailed post on [how to choose the right authorization model for your SaaS application.](https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application/)

## Understanding How ReBAC Systems Function

A ReBAC system is built on three main concepts that link together, which we'll break down using a git repository as our example.

**1. Subjects in a ReBAC System**

First up, you have the "Subject." This is the person or service that's trying to do something.

*Example:* A developer's account, `user:jane-doe`.

*Example:* An automated service, like `service-account:git-actions`.

**2. Objects: the Resources Controlled by ReBAC**

Next, there's the "Object." This is the resource the Subject wants to interact with or change.

*Example:* A whole repository, like `repo:acme-corp/webapp`.

*Example:* A specific pull request, like `pr:123`.

**3. Relationships: the Core of ReBAC**

Finally, and most importantly, you have the "Relationship." This is the piece that connects a subject to an object. It’s a simple, stored fact that describes their association. This isn't the permission itself, but a label defining the connection.

These relationships come in two main types:

* A **direct relationship** is a simple, stored fact, like a direct assignment.

*Example:* `user:jane-doe` is a maintainer of `repo:acme-corp/webapp`.


* An **indirect relationship** is where the system connects the dots for you. This is often called inherited permission.

*Example:* Dave gets `write_access` to a repo indirectly simply because he's a member of a team that has that access.

## How Does ReBAC Grant Permissions?

So if the relationship isn't the permission, how is a decision actually made? The system uses a separate set of rules that it checks against the facts.

Let's walk through a real git repository scenario:

* **The Ask:** Jane (`user:jane-doe`) tries to merge a pull request into the main branch of the `acme-corp/webapp repo`.

* **The System Checks:** The system doesn't ask, "Is Jane an admin?" Instead, it asks, "How is Jane connected to this specific repo?"

* **It Finds a Fact:** The system sees the stored fact: (`user:jane-doe`, `maintainer`, `repo:acme-corp/webapp`).

* **It Checks the Rulebook:** The repository's rules say something like: "Anyone with the maintainer relationship is allowed to `merge_pull_request`."

* **The Result:** The fact matches the rule, and the merge is allowed.

The power of this model is its flexibility. It means you can tweak your enforcement rules in GitHub (like requiring two reviews before merging) at any time, without having to go back and change the underlying relationship facts for all your developers.

## Challenges of Implementing ReBAC in Your Authorization System

Thinking about using ReBAC? Here's a quick heads-up on the common challenges you might run into.

### Performance Considerations for Scaling ReBAC

To check one permission, a ReBAC system might have to look up several different relationships that connect together. For example, checking if a user can see a file might involve checking their team memberships, which in turn involves checking the team's parent organization, and so on.

This can sometimes lead to slow queries and performance hits. As your application grows, it takes lots of engineering work to keep those lookups from slowing everything down.

### Designing Effective ReBAC Models

What makes ReBAC so great is its flexible, graph-style structure, but that's also what makes it tricky. The complexity isn't in a long list of rules, but in the designing of the relationship model itself.

Figuring out the "right" way to model your permissions (e.g., should a manager automatically inherit the permissions of everyone on their team?) is a big deal to start with. A poorly designed model can be hard to understand and even harder to change later on.

### Ensuring Audibility in Complex ReBAC Models

A side effect of a complex model is that auditing permissions can be tough. Answering a seemingly simple question like, "Why does Jane have access to this document?" can feel like untangling a ball of yarn. You might have to trace a path through five different indirect relationships involving teams and groups, which can make security reviews and debugging a pain.

### Keeping Your Data in Sync

Another roadblock you could run into is the dual-write problem. If your app's source of truth includes who's on what team or who owns what file lives in your main database and your ReBAC system is a separate service with its own database, it will need its own copy of that data to know what's going on.

And that’s how to get into the dual-write problem. When a manager moves someone to a new team, you've got to update that info in two places: your app's database and the authorization system. So, what happens if the write to your database succeeds, but the one to the auth system fails? Now you've got a user whose status is out of sync with their permissions. That can cause confusing bugs or, even worse, a security risk.

> This is a well-known problem in distributed systems If you want to see the different patterns for solving it, check out this blog post on ["Handling the Dual-Write Problem in Distributed Systems".](https://auth0.com/blog/handling-the-dual-write-problem-in-distributed-systems/)

All of these challenges point to the same advice. Using ReBAC successfully means putting in serious thought at the design stage. It trades the ongoing complexity of other systems for a thoughtful investment in your initial model.

## How Auth0 FGA Helps with ReBAC

So how do you actually use these concepts in a real tool? Let's look at [Auth0 FGA](https://a0.to/auth0-fga-content), a managed service for ReBAC. It provides the tools to get hands-on with the concepts we've been talking about and is built on the open-source [OpenFGA](https://a0.to/fga-content) (inspired by Google's Zanzibar).

Let's model our git scenario to show both direct and indirect permissions.

## Defining the ReBAC Authorization Model in Auth0 FGA

First, we define our authorization model in the Auth0 FGA Model Explorer. This is where we'll spell out the concepts we talked about earlier in the blog post. By defining the types of **objects** to be protected and the possible **relations** a **subject** can have with them. For example, a key **relation** in our model is `can_write`, which grants access if a **subject** has either a direct `maintainer` relationship with the **object**, or an indirect one by being a `member` of a `writer` team.

```js
model
  schema 1.1

type user

type team
  relations
    define member: [user]

type repository
  relations
    define maintainer: [user]
    define writer: [team]    
    define can_write: maintainer or member from writer
```

This model sets up our rule:

* A user gets `can_write` permission directly if they are a `maintainer`.
* A user gets `can_write` permission indirectly if they are a `member` of a `team` that is a designated `writer`.

## Creating Relationship Tuples in Auth0 FGA

Remember how we described a relationship as just a simple, stored fact? Now, it's time to actually store some of those facts in our system.

In the world of Auth0 FGA, each one of these "facts" is stored in something called a Tuple. Think of a Tuple as a single line-item that records one specific relationship, it's the raw data that connects a user to an object and solidifies their connection. You can use **Tuple Management** in the Auth0 FGA dashboard to add Tuples

```js
[
  // 1. Anne is a direct maintainer of the "webapp" repo
  {
    "user": "user:anne",
    "relation": "maintainer",
    "object": "repository:webapp"
  },
  // 2. The "developers" team is a writer on the "webapp" repo
  {
    "user": "team:developers",
    "relation": "writer",
    "object": "repository:webapp"
  },
  // 3. Bob is a member of the "developers" team
  {
    "user": "user:bob",
    "relation": "member",
    "object": "team:developers"
  }
]
```

### Verifying Access in Auth0 FGA

Now for the test. We ask the system simple questions, and it uses the model and the facts to give us an answer. In Auth0 FGA, we write assertions for this.

**Check #1 (Direct Relationship)**

* **Question:** Can Anne write in the "webapp" repo?
* **Answer: Yes.** The system checks the `can_write` rule. It sees that `maintainer` is a type of `can_write`, finds the fact that Anne is a `maintainer`, and grants access.

**Check #2 (Indirect Relationship)**

* **Question:** Can Bob write in the "webapp" repo?
* **Answer: Yes.** This is where the power of the model shines. 

The system checks:

1. Is Bob a direct `maintainer`? No.

2. Is Bob a `member` of a `team` that is a `writer` on this repo?

3. It finds the fact that the `team:developers` is a writer on `repository:webapp`.

4. It then checks if `user:bob` is a `member` of `team:developers`. Yes, it finds that fact.

5. The indirect rule (member from writer) is satisfied. Access granted.

Bob never got permission directly, but the system figured it out by traversing the relationship graph. If you want to get your hands dirty and build this yourself, the [Auth0 FGA documentation](https://docs.fga.dev/getting-started) is the best place to start.

You can see what each of these steps look like in Developer Mode of the Auth0 FGA playground.

![](https://images.ctfassets.net/23aumh6u8s0i/CQLIiE44n6iPLE7wP6xeo/1c02f3f14fc626d391a0b8ab8de5ab71/Screenshot_2025-06-13_at_11.57.21_AM.png)

## Final Thoughts on Relationship-Based Access Control

To bring it all together, ReBAC is an approach for modeling permissions that mirrors how your application actually works. Instead of relying on broad, static roles, it focuses on specific relationships: who owns a document, who is a member of a team, or who is assigned to a task. 

It does need more thought upfront to design that relationship model well. But the payoff for that initial work is an authorization system that's ultimately easier to use and change. When your app's features change, you often end up adding new relationships rather than rewriting hard-coded permission logic.

[Auth0 FGA](https://a0.to/auth0-fga-content) is a tool that provides the high-performance infrastructure for this approach, but the essential first step is always the work of designing a solid model that fits your application's needs.

What Is Relationship-based access control (ReBAC)?

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Senior Developer Advocate

Carla Urrea Stabile

The dual-write problem exists in distributed systems. Let's look at what it is and some of the most common strategies to mitigate it using authorization as an example.

When working on any distributed system, you might need to write data into different sources and guarantee that there is still consistency across all systems. Focusing on **authorization**, if you have your authorization system completely separated from your application, let’s say you’re using something like [Auth0 FGA](https://a0.to/auth0-fga-content), you could end up with an inconsistent state where, in your primary application, you could have updated the user’s access to a specific resource, for example, but it hasn’t yet been updated in your authorization system, so what can you do to avoid this issue? 

<include src="SignupCTA" text="To try Auth0 FGA, " linkText="sign up here" />

In this blog post, you’ll explore** the dual-write problem in the context of authorization** and learn about different strategies for mitigating it.    

> Keep in mind that Auth0 FGA is Auth0’s highly available and scalable solution built on top of [OpenFGA](https://a0.to/fga-content). This blog post might refer to OpenFGA specifically, but you can extrapolate that into your Auth0 FGA instance.

## What is the Dual-Write problem? 

Let’s start by talking about distributed systems. A distributed system is one in which **a collection of components communicate with each other only by passing messages, and they appear to their users as a single coherent system**. This leads to a few characteristics, such as concurrency of components, meaning different parts of your system can perform tasks at the same time, or independent failure of components, where different parts of the system could fail and recover without affecting other components.

The dual-write problem comes when **you need to write data to multiple systems atomically**. Because you’re dealing with a distributed system, you can’t use atomic transactions, so if one write fails, the other system can be left in an inconsistent state. Imagine a user making an order online, and they need to update their address. The system needs to update both the user database and the shipment service - if either fails, the shipment will not go where the user expected it to be.

Another example of leaving your system in an inconsistent state is when writing to a database and publishing an event to RabbitMQ, so it propagates through other systems. What if publishing the event fails? You’ll get an inconsistency between your database state and your events, and now you have yourself a dual-write problem. 

Note that the dual-write problem doesn’t only happen when writing to a database and emitting events; it is one of the most common scenarios. This problem can occur anytime you’re trying to write to two (or more) separate systems or when dealing with asynchronous operations where having a single transaction with a rollback is not feasible.

In the context of authorization, even if your application is a monolith, you’ve decided to use an authorization system like OpenFGA, you could also run into this problem. Let’s say you completely delegate authorization decisions to OpenFGA, but also keep a copy of the data in your application. Writing data in one place or the other might fail, and then one of your systems would be inconsistent with the other. 

For example, imagine you have a system where you want a user to be the editor of a document, and you store this information in your database. You need to tell OpenFGA that this user has an editor relationship with the document. Something could go wrong while updating the relation in OpenFGA. For example, there could be a network issue, and OpenFGA might never be updated. This will cause your application to end up in an inconsistent state, where your application knows the user is an editor of the document. Still, OpenFGA doesn’t know about this relationship, so if another part of your application checks against OpenFGA, you will get a different result than expected. In this case, you can’t simply roll back because the error could have happened at any stage, and traditional database transactions don’t work in these types of systems, as they are entirely independent of each other. 

To understand how to mitigate the dual-write problem, let’s consider a piece of the example above:

![Diagram illustrating the dual-write problem between an application database and OpenFGA](https://images.ctfassets.net/23aumh6u8s0i/4ooRG8nLZDkqXdOFNPsR5Z/f7b724f59d67e2aeb25f7a125acf09ad/dual-write__1_.png)

You have an application where you need to update the access of `user:anne` to `repo:roadmap` and make them a `writer`. You have an application with a local database, and you’re using OpenFGA for authorization; in an ideal world, both of these data sources would get updated, and everything will work perfectly, but we already know this is not the case. 

Keeping the example above in mind, how can you keep both your local database and OpenFGA in a consistent state? Here are some strategies:

## Strategy 1: Sequential Dual-Write

With a sequential dual-write approach, **the application writes data first in your application’s database and then in OpenFGA (or vice versa)**. If one write fails, you can have error handling mechanisms to roll back the other write or retry the failed write operation and avoid the dual-write problem.

A sequential dual-write approach would work as follows:

1. Write data to the local database. <br>
    a. If the write was successful, update the relation tuple in OpenFGA. <br>
    b. If the write fails, show an error message. <br>
2. Write to OpenFGA <br>
    a. If the write is successful, both writes were successful, and the sequence ends. <br>
    b. If the write fails, we need to roll back and delete the record on the local database to keep consistency and show a message that there was an error.

#### Pros
* **Simplicity**: Sequential writes are straightforward to understand.
* **Isolation of Errors**: If an OpenFGA write fails, database writes are unaffected, and vice versa.

#### Cons
* **No Atomicity**: If one write fails, you may have inconsistent states between the database and OpenFGA, so you must cover all possible error scenarios.
* **Higher Latency**: Waiting for one write before initiating the second increases latency.
* **Rolling back can be difficult or impossible:** if the service has to do many things before writing to OpenFGA. The error can happen at any point in the process, for example, with an unexpected crash in the server, there won’t be an easy way of rolling back.

## Strategy 2: Transactional Outbox 

Another common strategy to mitigate the dual-write problem is the transactional outbox pattern, which **relies on database transactions to update two tables: the table your app wants to update and an outbox table**. The idea is to use atomic database transactions to ensure the write is successful in the two tables of your database. Once the write is successful, you can use a separate process to consume it from the outbox table and update any other service. 

If you think about your application and OpenFGA, you’d have a transaction created only in the database of your application, along with an entry in an outbox table that indicates an event requiring a write to OpenFGA. For example, you could have a messaging streaming broker like RabbitMQ to propagate the event to OpenFGA. 

Going back to the example where you have an application where you need to update the access for `user:anne` to `repo:roadmap` and make them a `writer` and update OpenFGA, a transactional outbox approach would work as follows:

The application has multiple tables, including the repo and the outbox.

1. Write data to the local database in a single transaction: update the table outbox to indicate there’s a new unprocessed event, and table repo to indicate the new relation in this example
2. Your outbox service checks the outbox table every X amount of time, when there’s a new record found, and updates the relation in OpenFGA. <br> 
      a. Mark the record as processed in the outbox table if the write was successful. <br>
      b. If the write fails, you could have a retry mechanism or wait for the next processing time since the record wasn’t marked as processed yet. <br>

#### Pros
* **Atomicity**: The primary database and outbox entry are written in the same transaction, ensuring that data is either fully written or not at all.
* **Asynchronous Execution**: OpenFGA writes can happen in the background, reducing latency for the main database operation.
* **Recovery**: If there’s an error, you can retry the operation by checking the outbox table for unprocessed records. 

#### Cons
* **Eventual Consistency**: OpenFGA may have a slight delay in syncing.
* **Outbox Table Management**: Additional maintenance is required for the outbox table, including periodic cleanups. 

## Strategy 3: Event Sourcing 

In an event-driven approach, **every time an object is updated, the event-sourced system will translate that into an event**. In the case of using OpenFGA, you could use event-streaming with Apache Kafka, for example, and have a consumer service to read from it. 

Think of the example of an application where you need to update the access of `user:anne` to `repo:roadmap` and make them a `writer`. 

To mitigate the dual-write problem using an event-sourcing approach, you would do the following:

1. Publish the event regarding `user:anne` is now a `writer` of `repo:roadmap` to a streaming platform
2. The consumer service can then consume the event and update the relation in OpenFGA <br>
    a. If it fails, the consumer manages retries for failed writes to ensure that changes are eventually applied to OpenFGA.

#### Pros
* **Decoupling**: The application logic is simplified as a consumer service consumes directly from the source
* **Scalability**: Suitable for high-throughput applications as the stream of events and OpenFGA writes are independent.

#### Cons
* **Eventual Consistency**: There will be a delay until the message is processed and applied to OpenFGA.
* **Error Handling**: Retries and dead-letter queues must be carefully managed to handle failures gracefully.

## Strategy 4: Change Data Capture 

Another approach to mitigate the dual-write problem is Change Data Capture (CDC), which refers to the process of **tracking any change in the database (change) so that it can be captured and propagated into another system almost in real-time (captured)**. An example implementation of CDC is [Debezium](https://debezium.io/), an open-source distributed platform that captures row-level changes in your application’s database to see and respond to those changes. 

In the context of OpenFGA, using CDC can offer almost real-time updates, allowing real-time consistency between your permissions and your application. CDC is beneficial when your system can tolerate minor delays.

In the example of updating the permission for `user:anne` to be a `writer` of `repo:roadmap`, let’s assume you’re using a SQL database, when data is changed, let’s say by inserting a new record (note: you can listen to `INSERT`, `UPDATE` or `DELETE` triggers) the following happens when using a CDC approach:

1. The CDC Listener Service connects to the SQL database and listens for notifications on the table
2. When a notification is received, it’s processed, and the relation is updated in OpenFGA <br>
    a. If successful, you can log a success message <br>
    b. If a failure, you can implement a retry mechanism 

There are multiple ways to implement CDC. The approach above is trigger-based, but generally, approaches can be push or pull depending on which entity updates the other. This means the source database pushes the updates to OpenFGA, or OpenFGA polls the source database every X amount of time to pull the updated data. The example above represents a push approach. 

#### Pros
* **Real-Time Changes**: CDC can provide near real-time updates to OpenFGA.
* **Minimal Impact on App Logic**: CDC operates at the database level, so the application remains unaffected other than the listening service to the database. 

#### Cons
* **Complexity**: CDC requires a more complex setup and monitoring, especially in managing failed events.
* **Eventual Consistency**: There can be a slight lag before updates are reflected in OpenFGA.

## Strategy 5: Durable Execution Environments

A Durable Execution Environment is a system designed to **make sure that the execution of code or a workflow finishes to completion, by persisting the application state at every step** and automatically retrying execution after a failure. These systems use the concept of durable functions, which can persist in a state outside of the function execution context (hence the name) so that, in case of failure, it can be resumed from the point of failure. Examples of durable execution environments are [Temporal](https://temporal.io/) or [Dapr](https://dapr.io/).

In our example, we want to update the relation `user:anne` and make them a `writer` for `repo:roadmap`. You have a durable workflow that assigns tasks to available workers who are in charge of updating OpenFGA. A durable execution environment approach would look as follows: 

1. Write into the local database and log the event to the durable workflow
2. The durable workflow assigns the task to the first available worker to attempt to update the relation in OpenFGA <br>
    a. The worker will report back to the durable workflow, whether it was a success or failure, in which case it will retry the task


#### Pros
* **Fault Tolerance**: The system is more resilient to failures, ensuring that partial updates don’t lead to inconsistencies. Durable execution ensures that work is not duplicated on failure; it can resume from where it left off without reprocessing state.

#### Cons
* **Complexity**: Defining and managing durable transactions can be challenging.
* **Latency**: Durable transactions add to the latency and complexity of handling failures.

### Conclusion 

Overall, the dual-write problem might present itself in a distributed architecture, and there are different ways to mitigate it. In this blog post, you learned about five different strategies, their pros and cons, and gained an understanding of which one could best suit your use case. 

It really depends on the user case you have and how comfortable you are with the latency between your systems. Most of the downsides mentioned for each strategy are really inherent to distributed systems, and there is no silver bullet to solve distributed transactions; all approaches have their trade-offs and requirements. In the case of authorization, it is tightly coupled into your application’s logic, and moving it into a different service could offer significant advantages in the long run, but it also requires careful architectural planning and implementation.

Here’s a summary of each strategy with the key benefits and main drawbacks:

![summary of each strategy](https://images.ctfassets.net/23aumh6u8s0i/40ysjU1a2l685WVMtNhF5v/c07900432a427417054696ff22def754/dual-write-problem.jpg)

Handling the Dual-Write Problem in Distributed Systems

Checking your customers' email addresses is a basic rule for securely onboarding them in your B2B SaaS application. Learn how to do it in your Blazor Web App.

The very first thing to do when a user signs up for your application is to verify that they actually have access to the email address they provide. Although email verification is not the only security measure you should take to ensure the user's identity, this contributes to reducing spam and fraud. Auth0 provides [a few approaches to email verification](https://auth0.com/docs/manage-users/user-accounts/verify-emails), depending on your specific use case. In this article, you will learn how to leverage the built-in email verification process based on verification links to validate the email address provided by the user during their signup for a Blazor Web application.

## The Sample Application

A previous article showed [how to manage the onboarding of a customer](https://auth0.com/blog/enable-self-subscription-in-blazor-b2b-saas-application/) who signs up for a service offered by a B2B SaaS application implemented with Blazor. On that occasion, we did not consider verifying the client's email address as we wanted to focus mainly on self-registration and creating an Organization via code. Now, we will integrate that application by adding the verification step for the self-registering customer's email address.

Download the sample project to start with this command:

```shell
git clone --branch organization-via-code --single-branch https://github.com/andychiare/MyBlazorSaaS
```

Follow the attached README file instructions to register and configure the application with Auth0. If you don't have an Auth0 account, [you can sign up for free](https://a0.to/blog_signup).

## The Email Verification Process

By default, Auth0 sends a verification link to users when they sign up, but it's up to you to check if their email is verified before allowing them to access your application or perform specific actions.

In the context of your Blazor application, you will implement the following email verification process:

1. Once the customer signs up, Auth0 automatically sends an email to the user, and your application shows a message inviting the user to check their inbox.
2. The page showing the message provides a button to resend a new verification link in case the user didn't receive the first email.
3. If the user attempts to access any other application page, your app checks if the user's email has been verified before granting access.
4. Once the email is verified, the customer can create the Organization for their new subscription.

## Wait for Email Verification

The current customer onboarding flow implemented in your Blazor App allows users to create their Organizations as soon as they sign up. From a visual perspective, they pass from the signup form to the Organization creation form. You need to make sure the customer's email has been verified before allowing them to create their new Organization. Let's start by implementing a page that fulfills points 1. and 2. mentioned earlier.

### The verification waiting page

In the `MyBlazorSaaS/Components/Pages/Onboarding` folder, create a new file named `Verify.razor` and add the following code:

```csharp


@page "/Onboarding/Verify"
@rendermode InteractiveServer
@using Auth0.ManagementApi.Models
@using System.Security.Claims

@inject NavigationManager NavigationManager
@inject IAuth0Management auth0Management

<h1>Verify your email</h1>
<p>
 Please check your inbox for a verification link to continue creating your account.
</p>

<div>
  <button class="btn btn-primary" @onclick="ResendVerificationEmail">Resend Verification</button>
</div>

<div>
@Message
</div>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Message = "";

  private async Task ResendVerificationEmail()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;
      var userId = state?.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value;

      try {
        var managementClient = await auth0Management.getClient();
        await managementClient.Jobs.SendVerificationEmailAsync(new VerifyEmailJobRequest() { UserId = userId });
        Message = "The verification e-mail has successfully been sent. Please check your inbox";
      } catch (Exception) {
        Message = "Failed to resend verification e-mail.";
      }      
    } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
    }
  }
}
```

This page will display a message that invites the user to check their inbox and offers a button to resend the verification link if needed. It will be rendered as shown in the following image:

![Verify email screen in your Blazor Web app](https://images.ctfassets.net/23aumh6u8s0i/72gdEry0IJzomAqT4P95gF/a099d96c8531367d3c8b567ac3853081/blazor-verify-email-screen.png)

Since the current onboarding flow shows the Organization creation page after the user signup, you need to change it. Open the `Program.cs` file in the `MyBlazorSaaS` folder and replace the line of code shown below:

```csharp
// MyBlazorSaaS/Program.cs

//...existing code...

app.MapGet("/account/signup", async (HttpContext httpContext, string login_hint) =>
{
  var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
          //.WithRedirectUri("/onboarding/createOrganization") // 👈 old code
          .WithRedirectUri("/onboarding/verify")  // 👈 new code
          .WithParameter("screen_hint", "signup")
          .WithParameter("login_hint", login_hint)
          .Build();

  await httpContext.ChallengeAsync("OnboardingScheme", authenticationProperties);
});

//...existing code...
```

This ensures that the user will be redirected to the verification waiting page instead of the Organization creation page.

### Resend the verification link

The verification waiting page shows a "Resend Verification" button. Let's take a closer look at the code triggered by that button to learn how to resend the verification link:

```csharp

  
//...existing code...

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Message = "";

  private async Task ResendVerificationEmail()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;
      var userId = state?.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value;

      try {
        var managementClient = await auth0Management.getClient();
        await managementClient.Jobs.SendVerificationEmailAsync(new VerifyEmailJobRequest() { UserId = userId });
        Message = "The verification e-mail has successfully been sent. Please check your inbox";
      } catch (Exception) {
        Message = "Failed to resend verification e-mail.";
      }      
    } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
    }
  }
}
```

The `ResendVerificationEmail()` method gets the user ID from the authentication state, gets an instance of the management client, and uses the `SendVerificationEmailAsync()` method, passing an instance of `VerifyEmailJobRequest` with the user ID value. This method of the Management API client corresponds to calling [the email address verification endpoint](https://auth0.com/docs/api/management/v2/jobs/post-verification-email), which will generate a new ticket, include it in a verification link, and send it to the user via email.

## Customize the Email Verification Template

The default email message with the verification link sent to the user will look like the following:

![Email verification message](https://images.ctfassets.net/23aumh6u8s0i/6cP7skL9tqxBUnCAwC1cOa/0e31a5311fbd6506e75e010c091218a9/email-verification-message.png)

You can customize this message using your Auth0 dashboard. Go to the [Branding > Email Templates](https://manage.auth0.com/#/templates) page, select the *Verification Email (Link)* template, and apply the changes you want. You can customize the sender address, the subject, and the message body using [HTML and Liquid syntax](https://auth0.com/docs/customize/email/email-templates/use-liquid-syntax-in-email-templates). You can also customize other settings and use [common variables](https://auth0.com/docs/customize/email/email-templates#common-variables) to include some contextual values in your message. Read [this document](https://auth0.com/docs/customize/email/email-templates) to learn more about email template customization.

By default, nothing visible happens on your application when a user clicks the verification link. Auth0 will mark the user's email field as verified and show a page confirming that the email verification process was successful, as you can see in the following image:

![£mail address verified by Auth0](https://images.ctfassets.net/23aumh6u8s0i/4pgKFqZDlk93OnekyTrElS/1b3bf679d107f68279e8c4f711267836/email-address-verified.png)

However, in our self-subscription flow, we would like the user to be redirected to the next onboarding step after their email is verified, which is the organization creation screen. The email verification template provides a *Redirect To* field that allows you to specify the URL of the page you want the user to land after the email verification. You can parametrize the URL using one of the common variables mentioned above. Specifically, enter the following value in the *Redirect To* field and click the *Save* button:

```
{{ application.callback_domain }}/onboarding/createOrganization
```

That's all! Now, your user will be redirected to the Organization creation page after the email verification.

<include src="Auth0TemplatesForDotnetCTA" />

## Require Email Verification

One small piece is missing to complete the customer onboarding flow. You need to ensure that they cannot access the protected pages of your application if their email has not been verified yet. This means that when you check if the user is authenticated, you also need to consider checking that their email is verified too.

### A basic approach

You don't need to check if the user's email is verified when they access the `Home.razor` page, `Signup.razor`, and `Verify.razor` pages: the first two are public pages, and the third one is specifically designed for users who haven't verified their email yet.

You need to check the validity of the user's email on the `CreateOrganization.razor` page. To this purpose, apply the changes highlighted here on the `CreateOrganization.razor` page:

```csharp


//...existing code...

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      // 👇 new code
      var isEmailVerified = state.User?.FindFirst(c => c.Type == "email_verified")?.Value?.ToLowerInvariant() == "true";
      // ☝️ new code

      // 👇 changed code
      if (state.User?.Identity?.IsAuthenticated??false && isEmailVerified)
      // ☝️ changed code
      {
        Email = state.User?.FindFirst(c => c.Type == ClaimTypes.Email)?.Value??String.Empty;
        UserId = state.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value??String.Empty;
      } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
      }
    }
  }

//...existing code...
```

You can see that a new variable `isEmailVerified` has been introduced. This variable gets a boolean value coming from the value of the `email_verified` claim. You will use this variable as an additional condition to go ahead with the Organization creation step.

### A more structured approach

You need to apply the email verification check to most of the protected pages of your application. This depends on your application, of course. In our case, you should also apply the same check to the `Weather.razor` page on the server side and the `Counter.razor` and `FetchDat.razor` pages on the client side.

Applying the earlier approach would work, but it's ineffective in terms of code duplication and maintenance. You will use [ASP.NET Core policy-based authorization](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies) instead.

First, open the `Program.cs` file in the `MyBlazorSaaS` folder and add the code highlighted below:

```csharp
// MyBlazorSaaS/Program.cs

//... existing code...

// 👇 new code
builder.Services
    .AddAuthorization(options => {
      options.AddPolicy("VerifiedEmail", policy =>
        policy.RequireAssertion(context =>
          context.User.HasClaim(claim =>
            ( claim.Type == "email_verified" &&
              claim.Value?.ToLowerInvariant() == "true")
          )
        )
      );
    });
// ☝️ new code

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

//... existing code...
```

This code defines an authorization policy named `"VerifiedEmail"`. This policy checks if the current user has a claim `email_verified` set to `true`. This is the [standard claim](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) coming from the ID token issued by Auth0.

Now, let's create a page to which the user will be redirected when attempting to access a page without the required authorization. By default, Blazor redirects unauthorized users to an `Account/AccessDenied` page. So, create an `Account` folder in the `MyBlazorSaaS/Components/Pages` folder and add an `AccessDenied.razor` page with the following code:

```csharp

  
@page "/account/accessdenied"

<PageTitle>Access Denied</PageTitle>

<h2>You are not authorized to access this page</h2>

<p>@Reason</p>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Reason = "";

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      var isEmailVerified = state.User?.FindFirst(c => c.Type == "email_verified")?.Value?.ToLowerInvariant() == "true";

      if (state.User?.Identity?.IsAuthenticated??false && isEmailVerified)
      {
        Reason = "Your email is not verified yet!";
      }
    }
  }
}
```

This page shows a generic message to the unauthorized user and attempts to show a specific message about the actual reason. In particular, it checks if the user has the `email_verified` claim set to `true` and displays a message accordingly.

Finally, specify the policy `VerifiedEmail` in the `Authorize` attribute of your protected pages as shown below:

```csharp

  
@page "/weather"
// 👇 changed code
@attribute [Authorize(Policy = "VerifiedEmail")]
// ☝️ changed code
@attribute [StreamRendering]

//...existing code...
```

Apply this change to the `Counter.razor` and `FetchData.razor` pages in the `MyBlazorSaaS.Client/Pages` folder as well.

That's all! Your customer onboarding flow now includes the email verification step to mitigate the risks of spam and fraud.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Recap

Auth0 always sends an email verification message when a user signs up for your application. However, it's up to you to determine in which scenario to check whether the user's email has been verified.

In the example shown in this article, we took the case of onboarding a customer of a B2B SaaS application developed with Blazor and added the email verification step before allowing them to create a new Organization.

We also saw how to allow the resend of the verification email and prevent access to the application's protected pages when the user's email has not been verified yet.

You can find the final code of the project created during the article on [this GitHub repository](https://github.com/andychiare/MyBlazorSaaS/tree/email-verification).

Enforce Customer Email Verification in Your B2B Blazor Web App

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Secure Fastify APIs easily with the Auth0 Fastify SDK. It simplifies Auth0 integration, offering route protection and token validation.

Fastify is rapidly gaining traction among Node.js developers, and for good reason! If you're looking for a high-performance and low-overhead way to build web applications and APIs, Fastify is an excellent choice. Its plugin architecture is powerful, but securing those APIs remains a critical concern for developers.

To help address this, we are introducing the **`auth0-fastify-api` SDK**. This new package brings seamless Auth0 integration into your Fastify projects, simplifying API endpoint protection.

## So, What is Fastify, Anyway?

For those who might be new to it, Fastify is a web framework for Node.js focused on delivering a strong developer experience with minimal overhead, built around a robust plugin system. Key features include:

- **High Performance:** Fastify is known as one of the fastest Node.js frameworks, utilizing optimizations like schema-based request/response serialization.
- **Extensibility:** A rich ecosystem of plugins allows developers to easily add needed functionality.
- **Developer Experience:** Features like built-in logging, developer-friendly error handling, and first-class TypeScript support contribute to a smoother development process.
- **Schema-Powered:** Use JSON Schema to validate routes and serialize outputs, leading to more predictable and robust applications.
- **Helpful CLI:** The **`fastify-cli`** tool streamlines common development tasks like running the app and generating project scaffolds ([See fastify-cli on GitHub](https://github.com/fastify/fastify-cli)).
- **NestJS Integration:** Fastify's performance can also be leveraged within the popular NestJS framework by using it as the underlying HTTP provider ([Learn More](https://docs.nestjs.com/techniques/performance#performance-fastify)).

## Introducing `auth0-fastify-api`

This new SDK is specifically designed to secure Fastify APIs. It functions as a dedicated Fastify plugin to simplify the validation of access tokens issued by Auth0.

Here's what the SDK offers:

- **Simple Integration:** Sets up as a standard Fastify plugin.
- **Automatic Token Validation:** Handles the validation of incoming JWT access tokens (sent as Bearer tokens) against your Auth0 tenant configuration.
- **Route Protection:** Provides a **`requireAuth`** decorator for easily securing specific routes.
- **Scope Enforcement:** Allows specification of required scopes (permissions) needed to access certain endpoints.
- **User Information Access:** Makes the validated token payload available on **`request.user`**.
- **Token Access Utility:** Includes **`request.getToken()`** for accessing the raw token string if necessary.
- **Standard Error Handling:** Sends standards-compliant `WWW-Authenticate` headers on authentication/authorization errors.

## Getting Started: Quick Setup

Integrating the SDK involves two main steps:

1.  **Install the SDK:**

```bash
npm install @auth0/auth0-fastify-api
# or
yarn add @auth0/auth0-fastify-api
```

2.  **Register the Plugin:**

In your main Fastify application file, register the plugin, providing your Auth0 domain and API audience:

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";

const fastify = Fastify({ logger: true });

fastify.register(Auth0, {
  domain: "YOUR_AUTH0_DOMAIN", // For example: your-tenant.auth0.com
  audience: "YOUR_API_AUDIENCE", // The Identifier of your API in Auth0
});

// ... rest of your setup
```

> Remember to replace the placeholder values with your actual Auth0 domain and API identifier.

### A Functional Example

Let's look at a functional example that demonstrates setting up a basic server, loading configuration from the environment, and protecting a route.

Create a `fastify` directory anywhere in your system and initialize a Node.js project within it:

```bash
npm init -y
```

Within that directory, create a `server.ts` file and follow the instructions in this section to build it up.

First, import the necessary modules and use `dotenv` to load configurations like your Auth0 domain and audience from a `.env` file, which avoids hardcoding sensitive credentials.

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";
import * as dotenv from "dotenv";

dotenv.config();

const fastify = Fastify({
  logger: true,
});

if (!process.env.AUTH0_DOMAIN || !process.env.AUTH0_AUDIENCE) {
  fastify.log.error("Auth0 domain or audience not configured in .env file");

  process.exit(1);
}
```

It's good to check that the environment variables were loaded correctly.

Next, register the `Auth0` plugin, passing the configuration loaded from the environment variables:

```typescript
fastify.register(Auth0, {
  domain: process.env.AUTH0_DOMAIN,
  audience: process.env.AUTH0_AUDIENCE,
});
```

To ensure the `Auth0` plugin has finished loading before defining routes that use its decorators, such as `requireAuth`, register your protected routes inside an anonymous plugin function:

```typescript
fastify.register(() => {
  fastify.get("/", { preHandler: fastify.requireAuth() }, (_, reply) => {
    reply.send({ ok: true });
  });
});
```

Finally, start the server, listening on the port `3000`:

```typescript
fastify.listen({ port: 3000 }, function (err, address) {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }

  fastify.log.info(`Server is now listening on ${address}`);
});
```

You can run this short example by following these steps:

Install dependencies:

```bash
npm install fastify @auth0/auth0-fastify-api dotenv
```

Create a `.env` file with your Auth0 details:

```bash
AUTH0_DOMAIN=your-tenant.auth0.com
AUTH0_AUDIENCE=your-api-identifier
```

You can follow the steps on the ["Register APIs"](https://auth0.com/docs/get-started/auth0-overview/set-up-apis) document to learn how to create an API in the Auth0 Dashboard and get the required values: the Auth0 Domain, which is your tenant domain, and the Auth0 Audience, which is a unique identifier for your API.

Run the server:

```bash
npx ts-node server.ts
```

This provides a basic but functional starting point that loads configuration securely and correctly waits for the Auth0 plugin before defining protected routes.

## Securing A Route with `requireAuth`

As you saw earlier, to protect an individual API endpoint, use the **`requireAuth`** decorator provided by the SDK. Add it as a `preHandler` in your route definition:

```typescript
fastify.get(
  "/private",
  { preHandler: fastify.requireAuth() },
  async (request, reply) => {
    const user = request.user;
    return { message: "This is a protected route", user };
  }
);
```

Fastify will only reach the body of the route event handler if the token sent in the request authorization header is valid. The decoded token claims of the token are available in the `request.user` object.

If a request is made to `/private` without a valid Bearer token in the `Authorization` header, the SDK automatically rejects it with a `401 Unauthorized` status.

### Securing Multiple Routes

Applying the `preHandler` to every route can be repetitive if multiple routes require the same protection. Fastify's plugin system and encapsulation offer an efficient way to apply an authorization guard at the router level to protect multiple routes at once.

Group related routes within their own plugin and apply the **`requireAuth`** hook once using [`fastify.addHook`](https://fastify.dev/docs/latest/Reference/Server/#addhook) within that plugin's context. All routes defined within that plugin will then inherit the hook.

Let's see this concept in action.

**1. Create a routes plugin:**

Within an asynchronous Fastify plugin, you use `fastify.addHook("preHandler", fastify.requireAuth())` to run the authentication check before any route defined within this plugin. Routes defined after this hook (`/profile`, `/orders`, etc.) are automatically protected.

```typescript
// private-routes.ts
import { FastifyPluginAsync } from "fastify";

const privateRoutes: FastifyPluginAsync = async (fastify, opts) => {
  // Apply the hook once for all routes in this plugin
  fastify.addHook("preHandler", fastify.requireAuth());

  fastify.get("/profile", async (request, reply) => {
    // Token is already validated by the hook
    return { user: request.user };
  });

  fastify.get("/orders", async (request, reply) => {
    // Hook handles main auth; specific checks can still happen here
    if (!request.user.scope?.includes("read:orders")) {
      return reply.code(403).send({ error: "insufficient_scope" });
    }
    return {
      orders: [
        /* ... */
      ],
      user_id: request.user.sub,
    };
  });
  // Define more protected routes here...
};

export default privateRoutes;
```

**2. Register the plugin in your main server file:**

In your main server setup (likely within the `fastify.register(async function(fastify){...})` block), import the `privateRoutes` plugin. Use `fastify.register` to load it, passing the `prefix` option (e.g., `{ prefix: "/api/v1" }`) to mount all routes from the plugin under that path.

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";
import * as dotenv from "dotenv";
import privateRoutes from "./private-routes"; // Import the routes plugin

dotenv.config();

const fastify = Fastify();

fastify.register(Auth0, {
  domain: process.env.AUTH0_DOMAIN,
  audience: process.env.AUTH0_AUDIENCE,
});

fastify.register(async function (fastify) {
  if (!process.env.AUTH0_DOMAIN || !process.env.AUTH0_AUDIENCE) {
    fastify.log.error("Auth0 domain or audience not configured in .env file");
    
    process.exit(1);
  }

  // Register the protected routes plugin under the /api/v1 prefix
  fastify.register(privateRoutes, { prefix: "/api/v1" });

  // Routes defined outside that plugin don't inherit its hooks 
  // and need their own protection
  fastify.get("/", { preHandler: fastify.requireAuth() }, (_, reply) => {
    reply.send({ ok: true });
  });
});

fastify.listen({ port: process.env.PORT || 3000 });
```

Now, requests to `/api/v1/profile`, `/api/v1/orders`, or any other route inside `private-routes.ts` are automatically protected by the **`requireAuth`** hook applied at the plugin level.

## Enforcing Scopes

If you need to ensure the user has been granted specific permissions (scopes) in their access token, use the `scopes` property of the **`requireAuth`** decorator:

```typescript
const requiredScopes = ["read:messages", "write:messages"];

fastify.post(
  "/messages",
  { preHandler: fastify.requireAuth({ scopes: requiredScopes }) },
  async (request, reply) => {
    return { message: "Message created successfully", user: request.user };
  }
);
```

Only requests with valid tokens containing both `read:messages` and `write:messages` scopes will reach the route event handler body.

If you don't have multiple scopes to check, you can also assign `scopes` a string as its value. For a single scope, you could use the following:

```typescript
const requiredScopes = "read:messages";
```

If the validated token doesn't include _all_ the specified scopes, the SDK will return a `403 Forbidden` error with an `insufficient_scope` code.

## Accessing User Information

Once a token is validated by `requireAuth`, its decoded payload (claims) is attached to the Fastify request object at `request.user`. This typically includes information like the user ID (`sub`), audience (`aud`), issuer (`iss`), and granted scopes (`scope`).

```typescript
fastify.get(
  "/profile",
  { preHandler: fastify.requireAuth() },
  async (request, reply) => {
    // Access the user's unique identifier (subject)
    const userId = request.user.sub;
    // Access the scopes granted in this token
    const scopes = request.user.scope;

    return { userId, scopes, fullProfile: request.user };
  }
);
```

## Conclusion

The `auth0-fastify-api` SDK provides a straightforward way to secure your Fastify APIs by integrating Auth0 token validation. It offers simple decorators for protecting routes and checking scopes, allowing you to focus on your application's core logic.

We encourage you to try it out in your next Fastify project and share your feedback! Check out the [source code](https://github.com/auth0/auth0-fastify/blob/main/packages/auth0-fastify-api) and [examples](https://github.com/auth0/auth0-fastify/blob/main/packages/auth0-fastify-api/EXAMPLES.md) to learn more.

Happy coding!

Announcing the Auth0 Fastify API SDK: Secure Your APIs with Speed!

Let's explore the scenarios where ASP.NET Core Identity shows its limitations and what the alternatives are.

When it comes to handling identity and access management in the .NET platform, ASP.NET Core Identity is a fantastic starting point. It provides a full-featured, out-of-the-box solution for managing users, roles, and authentication in ASP.NET Core applications that is simple to set up and use. However, as applications grow in complexity and authentication and authorization requirements become more challenging, ASP.NET Core Identity may start showing its limitations.  
This article explores the limitations of ASP.NET Core Identity, the technical reasons behind these challenges, and discusses alternative solutions.

## Why ASP.NET Core Identity?

Before diving into its limitations, let’s first understand why ASP.NET Core Identity is so popular. ASP.NET Core Identity is a membership system that provides common features like user registration, login, role management, and claims-based authentication. It is tightly integrated with the ASP.NET Core ecosystem and supports both [cookie-based and token-based authentication](https://auth0.com/blog/cookies-tokens-jwt-the-aspnet-core-identity-dilemma/) (starting with .NET 8). It offers several key features out of the box:

* **User Registration and Login**. ASP.NET Core Identity simplifies user registration and login processes, including options for password recovery, email confirmation, and Multi-Factor Authentication (MFA).  
* **Role-based Authorization**. The system allows for granular control over user roles and permissions, which is essential for access control.  
* **External Authentication**. ASP.NET Core Identity supports various external authentication providers, such as Google, Facebook, and Microsoft, allowing users to sign in using their existing credentials from these platforms.  
* **Customizability**. Developers can customize the system to fit their needs, adding additional fields to the user model, integrating with other services, and defining custom password policies.

While ASP.NET Core Identity is highly effective for small to medium-sized applications with basic authentication needs, its limitations become apparent in more advanced scenarios.

## Limitations of ASP.NET Core Identity

What are the limitations you may encounter when your application needs to grow in the context of ​​security and user management? Let's explore some of the main scenarios.

### Support for Standard Authentication Protocols

One of the primary limitations of ASP.NET Core Identity is its lack of support for advanced authentication protocols, such as OAuth 2.0, OpenID Connect (OIDC), and SAML. These protocols are crucial for implementing [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on) across multiple applications and integrating with third-party Identity providers.  
While it can integrate with an external authentication service, this requires external libraries or a separate service to handle the authentication and authorization, adding complexity to the application.

### Single Sign-On and Federation

SSO is an essential feature for many organizations. It allows users to log in once and access multiple systems without needing to authenticate again. This is particularly important for enterprises with multiple applications that rely on centralized authentication.  
ASP.NET Core Identity is designed primarily for a single application context. While it’s possible to set up SSO in ASP.NET Core Identity by manually configuring external authentication providers (like Google, Microsoft, Facebook, or other enterprise systems), doing so is cumbersome and doesn’t scale well.  
Setting up SSO with complex protocols like SAML 2.0 or OpenID Connect can be challenging. You often need to rely on third-party libraries and write a lot of boilerplate code, which can be time-consuming and error-prone.  
In addition, if your application totally relies on an external Identity provider, the ASP.NET Core infrastructure, including the user database, becomes useless.

### Token Management

While .NET 8 introduced token-based authentication endpoints for Single-Page Applications (SPAs), these endpoints are limited in functionality compared to full-fledged OIDC or OAuth 2.0 implementations. For instance:

* By default, the tokens generated by ASP.NET Core Identity are not configured as JSON Web Tokens (JWTs).  
* Advanced OAuth flows like [client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) or [device authorization](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) are not natively supported.  
* Handling token refresh, revocation, or issuing custom tokens for various clients can be cumbersome with ASP.NET Core Identity.

### Microservices and Distributed Architectures

In modern application architectures, microservices are becoming increasingly popular. A key challenge in microservices is managing authentication and authorization across multiple services, each potentially using a different technology stack.  
ASP.NET Core Identity isn’t designed with microservices in mind. While it can work in monolithic applications, when dealing with a microservices architecture, you often need a solution that can provide centralized authentication and authorization, preferably using token-based authentication.  
In a microservices-based system, you might need to authenticate users once (e.g., OpenID Connect) and propagate tokens across multiple services (e.g., using OAuth 2.0). ASP.NET Core Identity is not ideal for this setup as it’s typically used for stateful session management, which is not optimal for distributed systems.

### Scalability and Performance

For high-traffic applications with millions of users, the default ASP.NET Core Identity database schema might become a bottleneck. While adequate for smaller applications, it isn't optimized for high-volume scenarios. Customizing the schema or implementing caching strategies is necessary but requires a deep understanding of the underlying database.

### Multitenancy

ASP.NET Core Identity is inherently designed for single-tenant applications, i.e., an application that manages a single set of users, typically belonging to one organization. A multi-tenant application is one in which a single instance serves multiple organizations or customers, each with its own set of users. This is a common scenario in SaaS (Software-as-a-Service) applications, where each customer (tenant) has different users, roles, and permissions.  
ASP.NET Core Identity does not provide built-in support for multi-tenant architectures. While it is possible to configure the system to work in a multi-tenant environment by creating separate user stores for each tenant, this approach can be cumbersome to manage and doesn’t scale well.

### Advanced Security Features

Implementing advanced security features like MFA with complex policies, FIDO2 credentials and passkeys, adaptive authentication, or risk-based authentication requires significant custom development. While ASP.NET Core Identity supports basic MFA, it lacks the flexibility to implement dynamic policies based on user behavior or risk profiles.  
Also, exposing protected APIs to third-party applications with ASP.NET Core Identity is possible, but it requires careful implementation of JWT-based authentication and authorization. Managing token issuance, validation, and revocation becomes critical, and inconsistencies can lead to security vulnerabilities. This is definitely a task for OAuth 2.0 and OIDC-compliant identity providers.

### Advanced Customization Requirements 

ASP.NET Core Identity's default implementation often requires significant customization to meet unique business requirements:

* Customizing the Identity API endpoints is challenging. For example, you cannot easily modify the data required for user registration or add unsupported authentication methods like WebAuthn.  
* The default UI for identity management forces you to use server-rendered pages unless you override them entirely.  
* Managing hierarchical roles or permissions is not natively supported.  
* Implementing fine-grained authorization for specific resources requires significant additional work.

### Security Concerns

Security is a major consideration when building any authentication system. While ASP.NET Core Identity provides some basic security features, the default configuration of ASP.NET Core Identity may expose vulnerabilities:

* Endpoints like `/register` are not natively protected, allowing [unauthorized access if not explicitly secured](https://auth0.com/blog/cookies-tokens-jwt-the-aspnet-core-identity-dilemma/#Some-Caveats-About-Identity-API-Endpoints).

* Without careful configuration, token expiration and refresh mechanisms [can introduce security risks](https://www.telerik.com/blogs/new-net-8-aspnet-core-identity-how-implement).

Also, it does not cover all the advanced security needs that modern applications require. Features like brute-force protection, IP whitelisting, user account lockouts, and MFA are important for securing an application’s authentication system. While ASP.NET Core Identity does provide some of these features (like MFA and account lockouts), more sophisticated threat protection features are often needed in high-risk environments.

## Self-Hosted Alternative Solutions

When you encounter one or more of the limitations discussed in the previous section, it is time to look for alternative solutions. A first option could be to replace ASP.NET Core Identity with a self-hosted standards-based Identity and access management solution.

Among the most popular self-hosted solutions in the .NET ecosystem, we can mention [Identity Server](https://duendesoftware.com/products/identityserver) and [Keycloak](https://www.keycloak.org/). Both offer more advanced identity and access management capabilities than ASP.NET Core Identity. Specifically:

* They **support standard protocols**, such as OpenID Connect and OAuth 2.0. Both products are OIDC-certified, which means they passed the tests that ensure compliance with the OIDC specifications. In terms of SAML support, while Keycloak supports it natively, Identity Server supports SAML via [a specific component](https://www.identityserver.com/articles/saml-20-integration-with-duende-identityserver).  
* They offer a **centralized authentication** solution enabling SSO and Federated Identity.  
* Support for **mutitenancy** depends on the specific product you are going to use. While Keycloak has native support for mutitenancy through [*realms*](https://www.keycloak.org/docs/latest/server_admin/index.html#_configuring-realms), supporting robust mutitenancy with Identity Server requires careful planning and implementation.  
* Support for **advanced authentication mechanisms** like passkeys is natively available in recent versions of Keycloak while it requires specific integration of third-party libraries in Identity Server.

Using a self-hosted solution like Identity Server or Keycloak certainly overcomes some of ASP.NET Core Identity's major limitations, especially regarding SSO and standards compliance. In terms of other features, much depends on the specific product and your needs in protecting your users' identities.

## Cloud-Based Solutions

Using a self-hosted solution, you still have to deal with issues that can become problematic as your application and its needs grow.

Leaving aside the features that your specific scenario requires, you still have to deal with your application's performance, high availability, and security. In other words, maintaining the efficiency and security of the Identity management solution is entirely up to you. You will have to follow the evolutions of the chosen self-hosted solution and apply updates promptly after verifying them. You will have to deal with scaling the authentication system as the number of users and concurrent requests grows. You will have to learn to do a job that is probably not yours.

Cloud-based solutions such as [Auth0](https://auth0.com/) offer you significant benefits in this regard.  
In addition to [features](https://auth0.com/features) that certainly go beyond those offered by self-hosted solutions and advanced customization possibilities, a cloud solution like Auth0 allows you to delegate the task of taking care of the security and maintenance of the Identity management of your application. No need to keep the system updated and take care of configuring the entire infrastructure to keep the identity of your users safe. In addition, you can take advantage of advanced security tools such as Anomaly Protection, Brute Force Protection, Bot Detection, and other features to armor your application's authentication system.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Wrapping Up

Choosing the right IAM solution depends on your specific needs and priorities. If you're building a simple application and need basic user management, ASP.NET Core Identity might be sufficient. For complex scenarios requiring SSO, federation, or advanced security features, IdentityServer or Keycloak are excellent self-hosted alternatives. If you prefer to offload the complexities of IAM and prioritize scalability and ease of use, a managed solution like Auth0 is a great option.

Here is a table that summarizes the main features supported by ASP.NET Core Identity compared with Identity Server, Keycloak, and Auth0 for your quick reference:

![Comparison table between ASP.MET Core Identity, Identity Servre, Keycloak, and Auth0](https://images.ctfassets.net/23aumh6u8s0i/4LpbsTxQhzyj2LXjULjWBz/29e1ddd3c5f245901ea9d951a98ea2a5/aspnet-core-identity-keycloak-auth0-comparison-table.png)

Remember to carefully evaluate your requirements and consider the tradeoffs between cost, complexity, and control before making a decision.  


When ASP.NET Core Identity Is No Longer Enough

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

Discover the Model Context Protocol (MCP) and its authorization mechanisms. Learn how to use API keys, OAuth 2.1 implementation, and best practices for secure LLM API connections.

An Introduction to MCP and Authorization

deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Staff Developer Advocate at Okta. He is also an international speaker and a published author.

Deepu K Sasidharan

Discover how AI agents are taking center stage by seamlessly integrating with multiple digital tools like Gmail, Calendar, Slack, and Google Drive to be more efficient. Learn why it is important to secure them and how to do it.

**AI agents** or **Operators** are the latest trend in AI. At their core, agents are autonomous systems that not only process natural language using Large Language Models (LLMs) but also decide when and how to act by interfacing with external tools and APIs. These smart entities blend machine learning with decision-making capabilities, enabling them to perform complex tasks, interact in real-time, use the most efficient tools to perform certain tasks, and even learn from their environment—all without constant human intervention.

<AmpContent>
<amp-youtube
    data-videoid="r7wEinUG0ns"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  className='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/r7wEinUG0ns'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

## Tool Calling Agents

LLMs on their own are still susceptible to hallucinations and mistakes, but the ability to call tools opens up a whole new world of possibilities where error-prone tasks can be offloaded to a more traditional non-AI tool, like using a calculator to do math rather than relying on the LLM for it. Similarly, tool calling allows AI agents to interface with other applications and services, like Gmail, Calendar, Slack, and Google Drive, to do more for you than just answering questions.

Tool calling can be generally classified into these:

1. **Unauthenticated Tools:** These are tools that don't require authentication and are generally simpler to configure, like a calculator, a weather API, or a unit converter.
2. **Authenticated Tools:** These are tools that require authentication and are generally complex to configure, such as an API provided by another internal application or services like Gmail, Calendar, Slack, and Google Drive.

In an enterprise environment, the authenticated tools can be further classified into:

1. **First-Party Tools:** These are services that are part of the same infrastructure and require authentication, like an API provided by another internal application or a microservice.
2. **Third-Party Tools:** These are external services that require more complex authentication. They could be services that are authenticated using service accounts or API keys, like a payment API, or services that need to be authenticated by the end user, such as Gmail, Calendar, Slack, and Google Drive.

Tool calling provides many key advantages to an AI agent:

- **Autonomous Decision-Making:** AI agents analyze context and determine the next best action, reducing the need for manual oversight.
- **Optimized Task Execution:** They can connect to various services and APIs, enabling them to perform specialized tasks like data retrieval, scheduling, and communication.
- **Scalability and Adaptability:** As systems evolve, agents can easily incorporate new functionalities, adapting to changes in workflow or priorities.
- **Improved User Experience:** Their ability to tackle diverse tasks leads to more personalized and efficient interactions, making technology feel both intuitive and proactive.

## Tool Calling Agent: A Conceptual Example

Imagine an AI personal assistant that consolidates your digital life by dynamically accessing multiple tools to help you stay organized and efficient. Here’s how it could work:

1. **Gmail Integration:** The assistant regularly scans your inbox to generate concise summaries. It highlights urgent emails, categorizes conversations by importance, and even suggests drafts for quick replies.
2. **Calendar Management:** By interfacing with your calendar, it can remind you of upcoming meetings, check for scheduling conflicts, and even propose the best time slots for new appointments based on your availability.
3. **Slack Notifications:** For team communications, the assistant monitors Slack channels. It identifies key messages and creates action items, ensuring you never miss an important update from your colleagues.
4. **Google Drive Access:** Whether you need immediate access to the latest project document or a file related to a current task, the assistant retrieves pertinent documents from Google Drive on demand. It can create document summaries and even create new documents based on your instructions.

With tool-calling capabilities, the possibilities are endless. In this conceptual scenario, the AI agent embodies a digital personal secretary—one that not only processes information but also proactively collates data from connected services to provide comprehensive task management. This level of integration not only enhances efficiency but also ushers in a new era of intelligent automation, where digital assistants serve as reliable, all-in-one solutions that tailor themselves to your personal and professional needs.

## Security Challenges with Tool Calling AI Agents

Building such an assistant is not that difficult. Thanks to frameworks like [LangChain](https://www.langchain.com/), [LlamaIndex](https://www.llamaindex.ai/), and [Vercel AI](https://vercel.com/ai), you can get started quickly. The difficult part is doing it securely so that you can protect the user's data and credentials.

Many current solutions involve storing credentials and secrets in the AI agent application’s environment or letting the agent impersonate the user. Storing credentials securely in the environment might work for APIs that require API keys or service accounts. However, this is not a good idea for cases where the end users need to authenticate to the service, as it can lead to security vulnerabilities and excessive scope and access for the AI agent.

<br>

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487 icon-info"></i>
  <b>To learn more about other security concerns and vulnerabilities in AI check out this blog post on <a href="https://auth0.com/blog/identity-challenges-for-ai-powered-apps/">Identity Challenges for AI-Powered Applications</a>.</b><br> 
</div>

When you build an AI agent, you need to consider all its other security implications as well. You don't want an LLM to have unlimited access to your personal data like email and documents, and more importantly, you don't want to provide your credentials to the LLM to access these tools. Let's face it, regardless of how secure the LLM is, there is always a possibility of it getting manipulated into divulging sensitive information or doing something you don't want it to do.

## Tool Calling with the Help of Auth0

This is where Auth0 comes to the rescue. As the leading identity provider (IdP) for modern applications, our upcoming product, [Auth for GenAI](https://auth0.com/blog/auth-for-genai/), provides standardized ways built on top of OAuth and OpenID Connect to call APIs of tools on behalf of the end user from your AI agent.

Auth0 brokers a secure and controlled handshake between the AI agents and the services you want the agent to interact with on your behalf – in the form of scoped access tokens. This way, the agent and LLM do not have access to the credentials and can only call the tools with the permissions you have defined in Auth0. This also means your AI agent only needs to talk to Auth0 for authentication and not the tools directly, making integrations easier.

### Call first-party APIs on users' behalf

When your AI agent, secured with Auth0, needs to call another application also secured with Auth0, you can use standard OAuth 2.0 flows, like the [Authorization Code Flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow), to get an API token from that application with user consent. In this case, Auth0 will manage the retrieval of new access tokens using cached refresh tokens when the API token expires.

### Call third-party APIs on users' behalf

When your AI agent, secured with Auth0, wants to call external services like Gmail, Calendar, Slack, and Google Drive, Auth0 can help the agent get access tokens for the external service on behalf of the end user. In this case, Auth0 brokers the API access token from the external service to the AI agent.

![Tool calling with Federated API token exchange](https://images.ctfassets.net/23aumh6u8s0i/1gY1jvDgZHSfRloc4qVumu/d44bb7102c1e858e5ac64dea324478fe/tool-calling-with-federated-api-token-exchange.jpg)

This is made possible by Federated API token exchange, which is a way to obtain an access token from an external identity provider without the need for the user to re-authenticate every time. The end user authenticates and connects the external service once, and Auth0 intermediates the authentication and authorization process and provides the API access token to the AI agent. Auth0 takes care of storing refresh tokens and getting new access tokens when the current access token expires.

## Security Best Practices for Tool Calling AI Agents

Here is a summary of security best practices to consider when building a tool-calling AI agent:

- **Least Privilege**: Grant the minimum permissions needed (e.g., read-only access).
- **Audit Logs**: Track API calls and credential usage.
- **Proxying**: Use an IdP like Auth0 as a broker between the AI agent and the tools to protect the user's credentials.
- **Encryption**: Encrypt credentials at rest and in transit (HTTPS/TLS).
- **Token Rotation**: Regularly rotate API keys and tokens.
- **Sandboxing**: Run tools in isolated environments when possible to limit damage from leaks.

## Learn More about AI Agents and Auth for GenAI

This post offers a glimpse into the transformative potential of AI agents and highlights how secure and intelligent tool calling can empower AI agents to deliver a more connected and personalized experience. Stay tuned for a series of posts on tool-calling Agents with [Auth for GenAI](https://a0.to/ai-content), where we will build the conceptual personal assistant from the previous section in Node.js and Python, showing how to integrate with different types of services securely using your favorite AI frameworks and Auth0.

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/), [CrewAI](https://www.crewai.com/), [Vercel AI](https://vercel.com/ai), and [GenKit](https://firebase.google.com/docs/genkit). [Auth for GenAI](https://auth0.com/blog/auth-for-genai/) is our upcoming product to help you protect your user's information in GenAI-powered applications. Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.

Tool Calling in AI Agents: Empowering Intelligent Automation Securely

For developers tasked with building global applications, choosing the right authentication solution is crucial. Auth0's ability to bridge the gap between enterprise and consumer needs makes it a standout choice in the crowded authentication landscape.

In today's multi-platform world, identity management isn't a one-size-fits-all solution. As developers, we need an authentication system that not only secures enterprise-level applications (B2B) but also delivers a seamless, user-friendly experience for consumer-facing products (B2C). That's why developers across the world turn to Auth0 when they feel it's time to delegate the task of building and maintaining ***authentication and authorization*** to a vendor with deep security expertise and adaptable technical capabilities. 

## The Challenge of Global Scale

Global companies with multifaceted portfolios face a unique set of challenges:

- **Multiple Platforms:** Users access their services via smartphones, PCs, consoles, and more.

- **Diverse Regulatory Requirements:** Compliance with international data privacy and security regulations is non-negotiable.

- **Customization Needs:** Every organization has its own unique workflows and integration requirements, such as compatibility with legacy authentication systems or [support for protocols like SCIM](https://auth0.com/docs/authenticate/protocols/scim).

For developers building at a global scale, the solution needs to be robust enough to handle high security and regulatory demands while remaining flexible for rapid development and global expansion.

## Why Auth0 Stands Out

Auth0's strength lies in its ability to effectively serve both B2B and B2C needs across geographical regions. Here's what makes it a compelling choice:

### Dual capability

Auth0 is built to handle both enterprise-grade integrations and consumer-friendly interfaces. While many competitors specialize in one or the other, Auth0 offers the best of both worlds.

### Robust security

With advanced features like multi-factor authentication (MFA), threat detection, and continuous monitoring, Auth0 meets stringent global security standards—critical for protecting sensitive user data and adhering to mandatory compliance requirements. Don't let regulation get in the way of expansion.

### Scalability

Whether you're serving thousands or millions of users across different regions, Auth0 scales seamlessly. This is vital for companies that operate in a global marketplace.

### Flexible customization

Auth0 allows extensive customization through robust APIs that support multiple programming languages and frameworks. This flexibility means you can tailor the authentication process to meet your specific needs, ensuring a smooth user experience regardless of the platform. Whether you are building the next top-ranking mobile game, a desktop AI application, or a streaming service, Auth0 has a solution that adapts to the user experience you want to attract, convert, and retain paying customers.

### Comprehensive support
 
Transitioning to a new authentication system can be complex. Auth0's professional services and support ensure that even challenges like regulatory compliance or cloud infrastructure migrations (e.g., AWS) are managed efficiently.

## Auth0 Is Ahead of the Competition

While there are strong contenders in the IDaaS space, they often excel in more niche areas. A competitor may be a strong option for enterprise integrations but may require extra effort to tailor it for consumer-facing applications. Some competitor platforms often focus on streamlined, developer-friendly solutions for either simple consumer apps or internal enterprise tools. However, they might not offer the same depth of customization and B2B/B2C functionality required for complex global environments or operations.

Auth0's proven track record in both B2B and B2C scenarios makes it uniquely suited for organizations that need a versatile, scalable, and secure authentication solution.

## See Auth0 in Action

Seeing is believing. Experience Auth0's power firsthand by diving into our developer resources. There, you can quickly set up secure authentication flows for both business and consumer scenarios.

### Interactive demo
   
Try out [our reference B2B SaaS application](https://saastart.app/) to experience features of multi-tenancy support, user management and access controls, security policies, self-service Single Sign-On configuration, and more out-of-the-box. Follow our [guided walkthrough](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/) to see how easily Auth0 can secure B2B SaaS applications. If you prefer to learn while reading code, check out the [Auth0 B2B SaaS Starter open-source repo](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter).

### Step-by-step developer guides

Check out our [detailed developer guides](https://developer.auth0.com/resources/guides) on integrating strong authentication using Auth0 with different frameworks and languages. These guides will show you how to implement everything from simple login pages to role-based access control in Single-Page Applications (SPAs), APIs, and web applications. Once you are done with the basics, explore our [developer labs](https://developer.auth0.com/resources/labs) to learn how to extend your authentication solution to include features such as Single-Sign On (SSO) for end-users using Google, GitHub, or X/Twitter, as well as enhancing your authorization models with Fine-Grained Authorization.

### Code samples

[Clone any of our starter projects](https://developer.auth0.com/resources/code-samples) and see practical examples of how Auth0 streamlines the implementation of authentication and authorization. Experiment with the code, tweak it to suit your needs, and accelerate your development process.

## Conclusion

For developers tasked with building global applications, choosing the right IDaaS solution is crucial. Auth0's ability to bridge the gap between enterprise and consumer needs—coupled with its robust security, scalability, and flexibility—makes it a standout choice in the crowded authentication landscape. 

If you're developing a platform that must meet both B2B and B2C demands on a global scale, Auth0 is definitely worth a closer look. [Global companies like SEGA have chosen Auth0](https://www.okta.com/jp/press-room/press-releases/sega-auth0/) as a comprehensive and compliant yet flexible authentication solution that not only enhances security and user experience but also streamlines development and operational efficiency: by opting for a ready-to-use IDaaS solution rather than maintaining an in-house system, SEGA was able to lower development friction, allowing their teams to focus more on core game development and innovation.

Authentication and Authorization For Developers Who Build at Global Scale

The way to implement an authorization system depends on your application's needs. Let's explore Relationship-Based Access Control (ReBAC) and implement it in a Rails API using OpenFGA.

How to Implement Relationship-Based Access Control (ReBAC) in a Ruby On Rails API?

tyler-nix

Tyler’s professional experience spans engineering, architecture, sales, and product at companies ranging from a small Series B startup to a large Fortune 5 enterprise. He now uses his diverse experiences to build better products at Okta. When he is not scaling digital products, he is pursuing hobbies that inherently don’t scale (especially those outside). He loves hearing his kids laugh while riding bikes, spotting a new bird species, and watching his garden grow.

Product Manager

Tyler Nix

Learn how the ReBAC authorization model overcomes RBAC when it comes to evaluate permissions on a specific resource.

In today’s dynamic digital landscape, ensuring users have the right permissions for specific resources is a critical task for any organization. Resource-based access control often needs to be highly fine-grained, especially in complex systems with millions of objects—such as files, projects, records, accounts, etc.

Yet building fine-grained authorization (FGA) correctly with traditional Role-Based Access Control (RBAC) presents several challenges, particularly when it comes to protecting against the top vulnerability in web applications: [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/).

RBAC itself isn't inherently problematic. But when you try to build fine-grained authorization on top of RBAC, the struggle creeps in. However, this is where Relationship-Based Access Control (ReBAC) shines: evaluating permissions on a per-resource basis. ReBAC makes it simple to perform an authorization check on complex permission models.

## The Difficulty of Building Fine-Grained Authorization with RBAC

[RBAC](https://auth0.com/docs/manage-users/access-control/rbac) has been the go-to method for managing access control in many applications. In RBAC, users are assigned to roles (e.g., admin, editor, viewer), and roles are mapped to permissions that give access to various resources.

A common approach to evaluating access to a resource in an application is to include the permissions in a user’s access token as scopes. However, since most scopes are generic and binary (e.g. `_view_all_documents_`), it would be difficult to manage detailed, resource-specific scopes (e.g. _view_document_123_) by adding them to the token because it would lead to token bloat. Additionally, since scopes in a token are static by design, they cannot easily reflect real-time permission updates until the token is refreshed.

Because of this, developers will often implement their own custom FGA solutions using RBAC built with SQL tables to unlock more dynamic and real-time access control. But this approach isn’t without its issues.

As systems grow and product improvements require more intricate resource hierarchies, the need to manage numerous roles, users, and resource-specific permissions leads to messy databases and unruly SQL queries, which often involve multiple joins spread out across database tables or services.

In contrast, [(ReBAC)](https://docs.fga.dev/authorization-concepts#what-is-relationship-based-access-control) models permissions based on relationships between users and resources, simplifying the evaluation logic. With ReBAC, permissions are dynamic and context aware. While you can fully implement RBAC roles within ReBAC, it also allows for more granular control over who can do what with each resource.

## Evaluating Resource-Specific Permissions with RBAC

Let’s consider an example: In a project management application, Aria is the admin for her entire organization. She is thus granted permissions to view and edit all documents in any project. The developers of the application have chosen to implement resource-specific authorization by building RBAC in SQL tables.

How do we determine if Aria has access to view a specific document? She would not have any direct assignments because she is not the document creator, but she should inherit the “editor” permissions since she is the organization’s admin. Evaluating this resource-specific authorization check in RBAC would require joining the various database tables that contain the role assignments and resource hierarchies in the organization to see if her "admin" role cascades down to that specific document.

As a result, with each permission check requiring more complex SQL queries, the application’s authorization logic becomes difficult to manage and even harder to update, possibly even leading to performance issues with deeply nested resources.

## How ReBAC Simplifies Resource-Specific Permission Checks

With ReBAC, permissions are calculated based on relationships instead of explicitly assigned roles, simplifying the evaluation of who has access or not. In a ReBAC system, Aria’s permissions aren’t solely based on her role but also on her role’s relationships with a document. Since Aria is the admin of the organization, the relationship can be cascaded down from the organization level via inheritance to a specific project or document level.

When you need to make an authorization check on a specific resource, the authorization system references the logic defined in the authorization model against the known object relationships and returns a decision (i.e. true or false). “_Can Aria edit the document business-report-1?_” = TRUE. We’ll learn later why this authorization check can be so simple.

> ReBAC makes it far more efficient than RBAC to check access on a per-resource basis.

## Evaluating Permissions with Okta Fine Grained Authorization

Now, let’s explore how Okta Fine Grained Authorization, a hosted and managed service of the popular open-source ReBAC project OpenFGA, leverages relationship-based access control to simplify access management.

Okta Fine Grained Authorization is designed to be flexible enough to work for small startups scaling single applications but powerful enough for large enterprise corporations creating complex relationships at a global scale. It does all of this while staying friendly enough for adjacent stakeholders on the team to read and understand the authorization logic.

Let’s build on the practical example above of Aria being an admin in her project management company. Suppose you have a hierarchical system in which different teams have access to various documents in a project based on the user's assignment.


### Sample Authorization Model in Okta Fine Grained Authorization

```bash
model
   schema 1.1

type user

type organization
  relations
    define admin: [user]

type project
  relations
     define organization: [organization]
     define owner: [user] or admin from organization
     define member: [user]
     define viewer: member or owner

type folder
  relations
     define parent: [folder, project]
     define owner: owner from parent
     define viewer: viewer from parent or owner

type document
  relations
     define parent: [folder]
     define editor: [user] or owner from parent
     define viewer: [user] or viewer from parent or editor
```

In this model, there are five core “types”: `user`, `organization`, `project`, `folder`, and `document`. Each plays a specific role in managing access within the system.

- `User` represents the individuals who will interact with the system. Users are assigned roles and permissions either directly or through group memberships.
- `Organization` contains all the projects with the ability to assign a global admin (like Aria).
- `Project` contains members, controlling access to project documents through membership at a top-level project.
- `Folder` adds a hierarchy to managing resources, connecting users to documents, even through deeply nested folders.
- `Document` inherits access permissions from their parent folder, which ultimately inherits from the project, all while allowing direct assignment to enable use cases like sharing a document with an external user.

A typical authorization scenario might look like this:

1. _Document_ business-report-1 is nested inside two _Folders_ under _Project_ Alpha.
2. _Project_ Alpha is a part of the Acme _Organization_.
3. Aria is assigned as the admin of the Acme _Organization_.

In Okta Fine Grained Authorization, these would be represented as relationship tuples stored in the centralized authorization system. You can think of Okta Fine Grained Authorization as a permissions database and tuples are the data. Each tuple will contain a user, relation, and object value like this:

```bash
{
  User: user:aria
  Relation: admin
  Object: organization:acme
}
```

Thus, following the logic in the authorization model, the access check for _“Can Aria edit the document business-report-1?”_ would return TRUE because:

1. Aria has the admin relationship in the Acme organization.
2. The admin relationship receives the owner relationship in the projects of that organization.
3. The owner relationship is thus inherited by the folders in that project.
4. Owner permissions continue to cascade down to the editor relationship of the documents inside the organization’s project folder, of which Aria is the admin.

![](https://images.ctfassets.net/23aumh6u8s0i/3pEKrtX5hEZrGMz2mT40RV/d13f7730b526aec43508c1f1294b37e3/01_rebac.png)

![](https://images.ctfassets.net/23aumh6u8s0i/65WRfIj3zGTtCo8S5dimhn/e8150eab044f6763069ff81cb42bf5c7/02_rebac.png)

## The Okta Fine Grained Authorization API

With ReBAC and Okta Fine Grained Authorization, querying permissions is as simple as checking a user’s relationship to a resource. Instead of performing multiple joins across tables as in RBAC, a single API call checks the relationship, making it highly efficient.

```bash
curl -X POST https://api.fga.dev/stores/{store_id}/check \
  -H "Authorization: Bearer {your_api_token}" \
  -d '{

    "tuple_key": {
        "user": "user:aria",
        "relation": "editor",
        "object": "document:business-report-1"
      }
}'
```

While RBAC is a powerful model for role-based permissions, it can struggle when adapted to manage fine-grained, resource-specific permission scenarios. Alternatively, ReBAC excels in dynamic, heavily-nested environments where permissions are based on inherited relationships between users and resources. By adopting ReBAC (and using a platform like Okta Fine Grained Authorization), development teams can streamline how they handle complex access control in their applications, reducing the major risk of broken access control that can stem from complex database queries. Try [Okta Fine Grained Authorization](https://auth0.com/fine-grained-authorization) for free.

### Additional Resources

- [https://fga.dev](https://fga.dev/)
- [FGA Playground](https://play.fga.dev/)
- [Fine-Grained Authorization in your Next.js application using Okta FGA](https://auth0.com/blog/fine-grained-access-control-with-okta-fga-nextjs/)
- [FGA Modeling Guide Video Series](https://www.youtube.com/watch?v=8VGy52SQ8bw)

How To Evaluate Resource-Specific Permissions Efficiently with ReBAC instead of RBAC

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Peter Fernandez

Why a Multi-Tenant approach is fundamental to B2B SaaS, and how using Auth0 and the Auth0 Organizations feature can help implement it.

Demystifying Multi-Tenancy in a B2B SaaS Application

paulo-nascimento

Paulo Nascimento is a Machine Learning Engineer at Okta, spearheading AI development for the Customer Identity Cloud (CIC). He brings expertise from AI startups to create innovative solutions powering the CIC organization. Paulo's work focuses on integrating AI technologies to strengthen enterprise security, enhance user experience, and drive intelligent automation across Okta's identity platform.

Machine Learning Engineer

Paulo Nascimento

Waleed Manzoul

Staff Product Designer

Automate user lifecycle, enhance security and boost IT efficiency across your enterprise

## Introduction

Consider a Fortune 500 company, like a bank with 40,000 employees. A financial analyst at this company will use many SaaS tools to do their job, like Slack, Google Suite for Work, Zoom, Tableau, Workday, and more. In fact, enterprise organizations rely on [an average of 211 apps each](https://www.okta.com/businesses-at-work/) to run their businesses.

So, the bank’s central IT team might be responsible for managing 200+ SaaS apps, and our financial analyst may need access to a quarter of them. Naturally, for an employee to use all of those apps, accounts for each one would need to be provisioned first.

Fortunately, our bank’s IT team is smart. They utilize [Okta Workforce Identity Cloud](https://www.okta.com/workforce-identity/) to maintain [a directory of all their employees](https://www.okta.com/products/universal-directory/) and enable easy account creation and access to those SaaS apps using [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on). That means they don’t have to manually provision SaaS apps every time a new employee joins the company or an existing employee needs access.

But what about other events in an employee’s time with the company, such as when they change their role, change their name or pronouns, or eventually leave the company? How many times might those events happen over 40,000 employees? And how might each of those changes be reflected in the SaaS apps that they use?

## User Lifecycle Management Using SCIM

Fortunately, if a SaaS app used at the company relies on a workforce provisioning engine that utilizes SCIM ([System for Cross Identity Management](https://scim.cloud/), a standard for automating the exchange of user identity information between identity domains), that app can synchronize its user list to the central employee directory and react to changes that happen in the directory.

For the bank’s central IT team, this means they can make updates to users once in their central employee directory and have those changes reflected in all of the SaaS apps an employee uses, **reducing administrative overhead and toil**.

The power of this “live” connection that SCIM provides becomes critical when an employee leaves the company. Once central IT deletes this employee from their central directory, any user accounts they had with those SCIM-powered SaaS apps will be deactivated within seconds, **eliminating the chance of unauthorized access** through “[zombie accounts](https://www.wsj.com/tech/cybersecurity/unused-online-accounts-data-safety-38fa675e)” and **maintaining compliance with data privacy regulations**, like [GDPR](https://gdpr-info.eu/art-5-gdpr/).

Timely deprovisioning of former employees can have **cost savings** as well. When an employee leaves, the central IT team can quickly release the employee’s SaaS licenses and accurately reflect the reduced spend to the respective vendors.

So, you can imagine that the bank’s central IT team would want any new SaaS app it evaluates to leverage SCIM due to its many benefits:

* Saves a lot of manual labor
* Improves their security posture
* Saves their company money

## How Does SCIM Provisioning Work?

SCIM works by providing a defined schema of identity data that represents users and groups, along with a REST API that supports JSON and XML for CRUD operations on those user and group resources. 

Behind the scenes, SCIM is broken down into a few core components:

* SCIM Service Provider
    * This service hosts the identity data and responds to SCIM API requests. It’s also commonly called a SCIM server.
    * _Examples: Cloud applications, identity providers (e.g., Okta)_
* SCIM Client
    * The SCIM Client **initiates SCIM requests to interact with a SCIM server to perform operations that manage identities.**
    * _Examples: Identity management systems, HR systems_
* SCIM Schema
    * The SCIM schema defines the structure of identity data.
    * Core schemas: User, Group, EnterpriseUser (defined in [RFC7643](https://datatracker.ietf.org/doc/html/rfc7643))

The SCIM core components then use an HTTP-based REST API that supports JSON and XML data formats, although JSON is more common. The REST API uses standard HTTP methods like GET, POST, PUT, PATCH, and DELETE to support CRUD operations.

SCIM supports a number of key operations, such as:

* User Provisioning
    * The ”SCIM Client” sends a POST request to create a new user, and the ”SCIM Provider” creates the user and returns a unique identifier (ID).
* User Retrieval
    * The ”SCIM Client” sends a GET request with the user ID or search criteria, and the ”SCIM Provider” returns user data that matches the request, provided the user exists.
* User Update
    * The ”SCIM Client” sends a PUT or PATCH request with the updated user data, and the ”SCIM Provider” applies changes and confirms the update.
* User Deprovisioning
    * The ”SCIM Client” sends a DELETE request, and the ”SCIM Provider” removes or deactivates the user account.

On top of this core functionality, SCIM also provides useful features such as: 

* Bulk Operations
    * Where batch processing can be applied for multiple SCIM operations in a single request
* Filtering and Searching
    * Allows complex queries to find specific users or groups by using a standardized filter syntax

For each request, the SCIM REST API will return with the appropriate HTTP status to indicate success or failure along with detailed error messages for troubleshooting. SCIM typically uses OAuth 2.0 for authorization and supports HTTPS for secure data transmission.

SCIM is also extensible, which means that organizations can extend the standard SCIM schemas to accommodate their specific needs. For example, if an organization wants to include additional information about employees not covered by the standard SCIM schemas, then they can store additional information such as ”department” or ”manager” in their user profiles.

## SCIM vs SAML

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s most commonly used to enable Single Sign-On (SSO) across different web applications and services.

SCIM and SAML are both protocols for identity and access management (IAM). However, they serve different purposes. 

SCIM is used for user provisioning and management across different systems and applications, ensuring that identity data is consistent across. SAML, on the other hand, is used to access multiple applications with a single set of credentials.

> In summary, SCIM is for user management, while SAML is for user authentication.

## SCIM vs. SSO

Single Sign-On (SSO) is an authentication method that allows users to sign in to multiple applications with a single set of credentials.

Although SCIM and SSO are related, SCIM is a protocol used for provisioning appropriate roles and groups to users, whereas SSO authenticates those users into multiple accounts with a single set of login credentials.

## Inbound SCIM with Auth0

If you’ve been reading about SCIM online, you’ve probably found identity providers like Okta Workforce Identity Cloud and Microsoft Entra ID support SCIM in different ways, and that building for each of them can become a substantive effort. We’d advise that you learn about the identity providers your customers use and tailor your SCIM solution to meet the majority of your customers. However, If you think you will need to integrate your development with more than one identity provider, don't despair: there are solutions that allow you to easily connect to multiple identity providers at once. 

In fact, that's one of the things we do at Auth0. Our [Inbound SCIM solution](https://auth0.com/docs/authenticate/protocols/scim) allows you to integrate with Okta Workforce Identity Cloud, Microsoft Entra ID, and other identity providers via both SAML and OpenID Connect, manage attribute mappings on a per connection basis, and more. 

## Conclusion

SCIM is a powerful way to automate user lifecycles and maintain user accounts across platforms that can save companies time, money, and increase their security. Learn more about SCIM by exploring the [Auth0 docs](https://auth0.com/docs/authenticate/protocols/scim). 


Streamline Account Provisioning and Management with SCIM

abhi

Abhishek Ambastha is a Group Product Manager with over 18 years of experience in security and identity solutions. At Okta CIC, he drives innovations to counter identity threats and enhance user security with seamless experiences.

Group Product Manager

Abhishek Ambastha

There are so many resources out there about passkeys and each vendor has its own implementation of the standard. Let’s answer some of your frequently asked questions about passkeys at Auth0!

There are so many resources for passkeys, and each vendor has its implementation of the standard. 

If you still need to familiarize yourself with passkeys, I recommend you look at this [blog post](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

Now, let's answer some of your frequently asked questions about passkeys at Auth0!

## Can I Use Passkeys With The Free Tier?

Starting with the elephant in the room, let's leave this clear here and now: **Passkeys are included in ALL PLANS**, yes, including the Free Tier, at no additional cost. We really, really are aiming for a passwordless future, and this is part of our commitment to it. 

## Migrating from Passwords to Passkeys

The industry is moving towards a passwordless future, and at Auth0, we are committed to the same goal. 

<include src= "LearnPasskeysCTA"/>

### Is Auth0 getting Rid of Passwords Entirely?

Not yet. For now, we introduced passkeys as an additional authentication option alongside passwords. Users can choose between a passkey and a password based on what works best.

### Can your Users Only Use a Passkey for Login?

Yes, absolutely. End users can sign up and log in using only passkeys, providing a completely passwordless experience. Passkeys serve as a robust first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is eventually to replace passwords.

### Can your Users Continue to Use Passwords for Signup & Login?

Yes. If passkeys are enabled in the configuration, end users will be prompted to continue with a passkey or a password.

<img src="https://images.ctfassets.net/23aumh6u8s0i/AbdRxr97bTLiR7ciHSFMs/9d8d9592d5b26a9b7dfa80271831c07c/passkeysprompt.png" alt="passkeys prompt" width="300"/>

### What About the Existing Users with Passwords?

When you enable progressive enrollment in the Auth0 Dashboard, existing users with passwords will be prompted to add a passkey so that they can use it in subsequent logins.

### Does Auth0 Support a Passkey-Only Flow (a flow where there is no password involved anywhere)?

Not at the moment. We are keeping the option of using passwords alongside passkeys; there are still some challenges regarding compatibility issues with older devices or browsers that need passkey support. In such cases, passwords will remain a viable method of authentication. 

In other words, **disabling password is not yet supported in the Database connection.**

![Username-Password DB Connection on passkeys config page](https://images.ctfassets.net/23aumh6u8s0i/3e3aJQhXISfjet2Pb3qvT2/6218e3ad3cdca472faafb23f06a7c06b/passkeys-db.png)

### Which Device and Browser are Compatible with Passkeys?

Passkeys are compatible with different operational systems and browsers at differing levels. Please refer [to `passkeys.dev` Device Support](https://passkeys.dev/device-support/) (maintained by [W3C WebAuthn Community Adoption Group](https://www.w3.org/community/webauthn-adoption/) and members of the [FIDO Alliance](https://fidoalliance.org/)) which provides latest information on device/browser support on passkeys.

> You can [learn more about passkeys and see them in action](https://youtu.be/v-KTu8W\_irM?feature=shared) in this excellent session from Oktane 2023. 

## Enabling Passkeys in Your Auth0 Tenant

You can enable passkeys by switching a toggle, and you can always refer to [the documentation](https://auth0.com/docs/authenticate/database-connections/passkeys) to understand how the signup and login flow with passkeys work at Auth0, but let's answer some more specific questions about enabling passkeys:

### How Can You Enable Passkeys for Your Users?

Passkeys are available in the Database connection section in the Auth0 Dashboard. You could enable passkeys by logging in to your Auth0 Dashboard and navigating to [Authentication -> Database](https://manage.auth0.com/\#/connections/database) -> Connection -> Authentication Methods -> Passkey as shown in the below screenshot.

![Username-password db connection page](https://images.ctfassets.net/23aumh6u8s0i/6ApYxla0hbMtXy6gEVwEpV/a2328b46620c5d74ad44d5b7b4294783/passkeys-rb-1.png)

For more details on enabling passkeys, follow the steps [in this blog post.](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) 

### Are there any prerequisites to enable passkeys?

Yes, passkeys come with specific prerequisites:

1. Enable New Universal Login: we encourage you to switch to New Universal Login, where new features like passkeys are being introduced.

2. Deactivate Custom Login Page: Enabling the Custom Login Page reverts the New Universal Login to the Classic experience, which connects to the first requirement.

3. Activate Identifier First Login: This facilitates a seamless user journey, beginning with the Identifier. Users can then decide whether to proceed with passkey or password authentication.

4. Deactivate Requires username: For connections that have not activated attributes for flexible identifiers, the username is not supported. To use passkeys with usernames, you will need to  [activate attributes for flexible identifiers](https://auth0.com/docs/authenticate/database-connections/activate-and-configure-attributes-for-flexible-identifiers) on the connection.

5. Disable Use my own database: Finally, "Use my own database" must be disabled unless Import Users to Auth0 is enabled as it implies passkeys created in the system will remain separate from user credentials stored in external custom databases (unless Lazy migration is ON).

If you are missing any of the prerequisites above, we will show a checklist similar to the image below when you try to enable passkeys for your users.

![passkeys pre-requisites](https://images.ctfassets.net/23aumh6u8s0i/2n9HEqIK9TN3Fep2VEaSpA/80016c1e19d9c713ecc6c20a034cdb51/passkeys-prereq.png)

### Is there any other important consideration for enabling passkeys?

An important point to note is **the [relying party](https://auth0.com/docs/glossary\#relying-party) domain should not change after passkeys are enrolled**, because changing the domain will invalidate all existing passkeys. As such, passkeys are created for a specific RP domain.

### Are there different options for logging in with passkeys?

Yes. You could choose how the passkey options are rendered in their end user prompts. This will control how the challenge is triggered. 

Two options are available for logging in with passkeys: **Passkey Button and Autofill.** By default, both options are enabled when passkeys are configured.

> As per [FIDO UX guidelines](https://fidoalliance.org/UX-guidelines/), FIDO research explored participants' success and satisfaction with dedicated passkey buttons and autofill. FIDO testing indicates that autofill ensured the highest success for people to sign in with a passkey.

However, it is essential to note that autofill does not work in all scenarios. For example, when autofill is disabled in the browser, the Passkey Button provides the fallback UX.

## Passkeys Configuration at Auth0

### What is Local Enrollment?

When you enable local enrollment and authenticate through the cross-device flow (using a QR code) across ecosystems, Auth0 will prompt the user to create a passkey on their second device. Local enrollment ensures secure and effortless logins, as the passkeys from the second device become accessible for subsequent logins. It also eliminates the need for the user to repeatedly use a QR code to log on to the second device; instead, they can simply utilize the local passkey for all subsequent logins.

### What is Progressive Enrollment?

Progressive enrollment allows Auth0 to prompt existing users with passwords to add passkeys so they can use them for their next login. 

### Why is Auth0 Skipping Captcha Verification When Passkeys are Selected?

Passkeys already offer a phishing-resistant authentication method. To achieve a faster, seamless, and secure login experience, adding additional friction during login steps like Captcha is not optimal. Hence, Captcha verification is presented, but users can skip this step when they select log in with a passkey. They still have to solve a Captcha if they're presented with one and choose to continue with the password.

### Does Auth0 have any limit on the number of passkeys per user?

Yes. For now, we've implemented a **limit of 20 passkeys per user.** A user could have multiple passkeys. For example, a user could create a passkey on Apple and Google devices when they authenticate via cross-device authentication using a QR code.

## Security & Attack Protection with Passkeys

### What if An Attacker Tries to Abuse a QR Code?

FIDO cross-device authentication incorporates an inherent verification mechanism utilizing Bluetooth technology to ensure the proximity of the two devices. While this process remains seamless for the user, potential attackers who acquire a QR code and attempt remote logins will be thwarted, as the cross-device authentication does not operate over remote connections. We're limiting the attack surface to a few meters of physical proximity instead of anywhere in the world, as with passwords.

### Is Bluetooth a Requirement for Cross-Device Authentication? How does it Impact the Overall User Experience?

Yes. The Bluetooth-based proximity verification for cross-device authentication happens seamlessly for the end user. If they have deactivated Bluetooth, a user-friendly prompt will guide them to enable Bluetooth when they scan a QR code for cross-device authentication.

### Are Attack Protection Features Applicable to Passkeys?

Yes. Certain attack protection features, such as Suspicious IP throttling, will be applicable for passkeys. Credential Guard is skipped when utilizing a passkey due to the absence of a password. While Bot Detection will operate during the pre-login assessment phase, the Captcha verification step is bypassed when opting for passkey-based logins.

### What if MFA is Enabled in the Flow?

The MFA policy will continue to apply for login with passkeys. This implies that users will be prompted with a second factor depending on their MFA configuration. If you choose to bypass a second factor, you could implement custom logic when a passkey is used as an authentication method.

### Can I use Passkeys as a Second Factor?

Not for now. Passkeys are the first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is to eventually replace passwords.

## Managing and Handling Passkeys

### How can you debug passkeys in your tenant logs?

Passkeys are an additional authentication method. Therefore, we're repurposing existing event codes outlined in [Log Event Type Codes](https://auth0.com/docs/deploy-monitor/logs/log-event-type-codes). However, to enhance clarity regarding the employed authentication method, we've incorporated the following elements:

* Signup: The event with type `ss` will include a field `details.authentication_method` set to either `password` or `passkey` based on the method used during signup.

* Login: For passkey-based logins, `"performed_amr": ["phr"]` is included. During login, the event with type `s` indicates if a passkey is used to authenticate. The `details.prompts` array contains the set of prompts that the end-user navigated through, and the `"performed_amr": ["phr"]` will be present on the element if passkey authentication was used (`phr` stands for "phishing-resistant" and is the standard amr (Authentication Method Reference) claim value for passkeys).

* Progressive & local enrollment: Successful enrollment will be captured with `gd_enrollment_complete`, while failed enrollment attempts will be recorded as `gd_webauthn_enrollment_failed`.

### Can you Use Passkeys with the Management API?

Yes, you can list and revoke passkeys using the Auth0 Management API. You can learn more about [managing passkeys with this blog post.](https://auth0.com/blog/passkeys-management/) 

### Can you Use Passkeys with Actions?

Yes. You can, for example, detect whether a user authenticates with a passkey within the [Post-Login trigger](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow).

In the event object, the `authentication.methods` array contains elements describing the methods used to authenticate for the current session. The elements' names are set to `pwd` for regular password-based authentication and `passkey` for passkey-based authentication.

## Account Recovery

### How can users recover their passkeys?

Auth0 stores a record of public information about your passkey (such as the public key) that you can use for authentication. As passkeys are stored within their respective ecosystems (like Apple or Google) and not shared with the relying party (such as Auth0), end users must retrieve passkeys directly from these ecosystems when needed. 

### How could users recover an account?

The existing account recovery process remains unchanged. Users will still need to verify their email by clicking the link in their inbox. Following successful verification, they'll have the option to set up a new password.
 

We hope this passkeys FAQ helps you leave passwords behind and enable passkeys for your users today. If you have other questions, make sure to post them in the comments, and our team will be happy to help! 

All You Need To Know About Passkeys at Auth0!

There are different ways to implement an authorization system and the one you choose depends on your application's needs. Attribute-Based Access Control (ABAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

Previously on your access control series \*read with TV show presenter's voice\*... You learned about [Role-Based Access Control (RBAC) and how to integrate it into your Rails API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/).
In this blog post, you’ll continue learning about different authorization systems, this time about Attribute-Based Access Control and how to migrate the access control of the expense management API from RBAC to ABAC. 

<details>
<summary>Starting from here?</summary>

If you want to start this tutorial from the beginning, [start from this blog post.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/)

Clone the application repo and check out the `add-rbac` branch:

``` bash  
git clone -b add-rbac https://github.com/auth0-blog/rails-api-authorization 
```

Make the project folder your current directory:

``` bash  
cd rails-api-authorization
```

Then, install the project dependencies:

``` bash  
bundle install
```

Then, setup the database

``` bash
  rails db:setup
```

Finally, create a `.env` hidden file:

``` bash  
touch .env
```

Populate `.env` using the `.env.example` file:

``` bash  
cp .env.example .env
```

Add your Auth0 configuration variables to the .env file and run the project by executing the following command:

``` bash  
rails s
```

</details>

## What Are Attributes in the Context of Access Control?

Let's consider the use case of the expense management API you are using in this tutorial. For RBAC, you created an `admin` role and assigned it to users using Auth0 Actions. Users with the `admin` role can approve and review expenses, and so far, that's so good. 

The following requirement you have is that only certain users can do certain things on specific expense reports: 

- Users can only see a report they own (submitted by them)
- Users can only see a report if they are the approver
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

With the current RBAC implementation, a user with the `admin` role can do all of these things, but unfortunately, not all admin users need to approve reports. So, as a solution, you think adding these guards to your code sounds good, so **you are going to check the attributes of the report** (the user is either the approver or submitter of this report), the date the report is being approved, etc. 

This practice has a name, and it's called Attribute-Based Access Control.

## What Is Attribute-Based Access Control (ABAC)?

[According to NIST, Attribute-Based Access Control (ABAC)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf) is an access control method where a subject's requests to perform operations on objects are granted or denied **based on assigned attributes of the subject, assigned attributes of the object**, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

In other words, any access decision that your application makes based on attributes of an entity can be considered ABAC and it'll be specific to your application and access control needs. 

ABAC also gives you more control and granularity over your access decisions, making it more flexible than RBAC. 

Regarding the expense management API, RBAC and ABAC can coexist; in fact, checking for a role or permission is also checking for attributes, in this case, attributes assigned to the user, so we can say RBAC is an implementation of ABAC with a limited scope of roles and permissions. So now, let's say it is a requirement that the user also needs to be an admin to perform the approver actions. Why not? 😛 

Let's look at what you'll need to change in your Ruby on Rails API to comply with the new access control requirements and implement ABAC. 

## ABAC Implementation in a Ruby on Rails API

Let's take a look at the requirements you need to implement: 

- Users can only see a report they own (submitted by them)
- Only approvers can see reports submitted by other users
- Only admin users can approve reports
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

Based on this, there are a few changes you could make to the application; most of them are related to the `report` entity. 

Let's think of the scenario where a **user can only see a report they have submitted, or they are the approver**; you could think of this as multiple things like the user needs to have some relationship with the expense report, meaning they are either the submitter or the approver.

There's little we can do with the relationship example now. Still, you can define that if a user is the submitter or approver of a report, they have some **ownership** over it and are allowed to see that report, so let's start there. 

In the API context, you can define this ownership such that **the user making the request is the same user for which we want to see reports.** At the moment, your API doesn't have the context of the user other than an access token, which tells you only that they are authorized to access your API and that they are `admin` because [you added this role as a custom claim in the access token.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Creating-and-Assigning-Roles-with-Auth0)

So, that's great 🫠 how can you get information from the user in your API using Auth0? The answer is by connecting your Auth0 API and your Auth0 Application!

### Connect Your Auth0 API with your Auth0 Application 

If you have a REST API as your backend, chances are you have a frontend application where your users authenticate and manage their data, etc. 

When you use Auth0, your users can authenticate using [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login). So, you need to create an Auth0 Application for either a SPA or a Regular Web Application and [integrate it with your code using one of the SDKs](https://auth0.com/docs/libraries). For this blog post, let's focus on the example of the regular web application. 

[When you created the expense management API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Building-the-Starter-Application), you created an [Auth0 API](https://auth0.com/docs/get-started/apis) and an Auth0 Regular Web Application for testing purposes, well now you are going to use this Regular Web Application because in a real-life scenario, your users will probably authenticate themselves *somewhere* and once they're authenticated you proceed to do X or Y in your REST API. 

In the Regular Web Application you created in Auth0 for your users to authenticate, you need to implement login, logout, etc., and you can learn how to do so by following [any of the Developer Center Guides on Authentication](https://developer.auth0.com/resources/guides?type=web-app). Still, the general process is almost identical in all of them, and the outcome is that **you will get an access token from Auth0 issued for the authenticated user.** 
 
Then, you need to tell your Regular Web Application that your users will be interacting with your REST API and, therefore, its counterpart in Auth0, so when you request the access token, you need to provide the `audience` as well. An example of how to do this in a [Ruby on Rails Web application](https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication) would be: 

```ruby
Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
 :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
 callback_path: AUTH0_CONFIG['auth0_callback_path'],
 authorize_params: {
 scope: 'openid profile email',
 audience: 'https://rails-api-authorization', # pass the audience ✨
 }
 )
end
```

Once you pass the `audience`, you'll get a JWT token containing the information about the user, as well as any scopes and claims you've added. To learn more about the audience parameter [you can check out this post.](https://community.auth0.com/t/what-is-the-audience)

That's all you need to do for now in Auth0 to make this work, so let's get back to the code!

### Validate Ownership of the User Making the Request

You already added a method to check for the user's role, so similarly, you could do the same to check for the user's *ownership*. In the context of the expense management app, we'll say: 

> A user is allowed to see an expense report of another user if they are the subject of the access token 

At the moment, you do not store any information about the user's data in your database, but you will need the Auth0 user's ID to compare it. 

#### Add the Auth0 ID to the User Model

Let's create a migration to add a new field to the User model using the following command on your terminal: 

```bash
rails g migration AddAuth0IDToUsers auth0_id:string 
```

The command above will generate a new migration file under `db/migrate/YYYYMMDDHHMM_add_auth0_id_to_users.rb` that looks like this:

```ruby
class AddAuth0IdToUsers < ActiveRecord::Migration[7.0]
  def change
 add_column :users, :auth0_id, :string
  end
end
```

Then, execute the migration by running `rails db:migrate` on your terminal. 

Now, let's add a validation to the User model to make sure the `auth0_id` field is always present and unique. Go to `app/models/user.rb` and add the following code: 

```ruby
class User < ApplicationRecord
 has_many :expenses, foreign_key: :submitter_id
 has_many :submitted_reports, class_name: 'Report', foreign_key: 'submitter_id'
 has_many :reports_to_review, class_name: 'Report', foreign_key: 'approver_id'

 validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: true
  # 👇 new code 
 validates :auth0_id, presence: true, uniqueness: true
end
```

You're all set from the model level. Let's move to the controller level. 

#### Add the Ownership Validation to the Controller

Go to the `Secured` concern in `app/controllers/concerns/secured.rb` and add the following code: 

```ruby
# frozen_string_literal: true

module Secured
  extend ActiveSupport::Concern

  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
  BAD_CREDENTIALS = {
 message: 'Bad credentials'
 }.freeze
  MALFORMED_AUTHORIZATION_HEADER = {
 error: 'invalid_request',
 error_description: 'Authorization header value must follow this format: Bearer access-token',
 message: 'Bad credentials'
 }.freeze
  INSUFFICIENT_ROLES = {
 error: 'insufficient_roles',
 error_description: 'The access token does not contain the required roles',
 message: 'Permission denied'
 }.freeze
  # 👇 new code 
  NOT_OWNER = {
 error: 'not_owner',
 error_description: 'The access token does not belong to the current user',
 message: 'Permission denied'
 }.freeze
  # 👆 new code 

  def authorize
 token = token_from_request

 validation_response = Auth0Client.validate_token(token)

    @decoded_token = validation_response.decoded_token

    return unless (error = validation_response.error)

 render json: { message: error.message }, status: error.status
  end

  def validate_roles(roles)
    raise 'validate_roles needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_roles(roles)

 render json: INSUFFICIENT_ROLES, status: :forbidden
  end

  # 👇 new code 
  def validate_ownership(current_user)
    raise 'validate_ownership needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_user(current_user)

 render json: NOT_OWNER, status: :forbidden
  end
  # 👆 new code 

  private
  # ... 
end
```

You are adding a new hash called `NOT_OWNER` to specify the error message in case the user is not the owner of the access token being passed. Then, in the `validate_ownership` method, you're checking the access token and returning an error if the user is not the owner. Since you haven't implemented the `validate_user` method yet, let's add it to the token structure. 

Go to your `Auth0Client` class in `app/lib/auth0_client.rb` and add the following code: 

```ruby
# frozen_string_literal: true

require 'jwt'
require 'net/http'

class Auth0Client

  # Class members
  Response = Struct.new(:decoded_token, :error)
  Error = Struct.new(:message, :status)
  Token = Struct.new(:token) do
    def validate_roles(roles)
 required_roles = Set.new roles
 token_roles = Set.new token[0][Rails.configuration.auth0.roles]
 required_roles <= token_roles
    end
    # 👇 new code
    def validate_user(current_user)
 current_user.auth0_id == token[0]["sub"]
    end
    # 👆 new code
  end

  # Helper Functions
  # ...
end
```

The `validate_user` method checks the `current_user` variable (the user from whom you want to check the reports) against the owner of the access token. In the access token, you have information about the user's ID in Auth0 under the `sub` field, so you are comparing that against the `auth0_id` from the local database. 

Next, call the `validate_ownership` method in the `ReportsController`. You want to validate the user's ownership when they request to review or submit a report, so let's add the validation to the corresponding actions. 

Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  def submitted
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(submitter_id: @user.id) # list only reports where user is submitter

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/review
  def review
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(approver_id: @user.id) # list only reports where user is approver

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/1/approve
  # ...
end
```

By adding the `validate_ownership` block in the controller together with the condition inside the query, you are implementing a form of ABAC because you're allowing or denying access based on certain attributes of the user or the report. 

### Validate that Only Approver Users can Approve Reports 

Even though this might be a new requirement, you already took care of this scenario when you first added RBAC. If you look at the `approve` action in the `ReportsController`:

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  # ...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        @report.status = "approved"
        @report.save
 render json: @report
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

The check for `@report.is_approver?(@user)` already confirms that 
 `@user` is the approver of `@report`. This is interesting because sometimes we mix up different authorization models without even realizing it, and that's okay as long as it fits your business model. s

### Validate that Approvals Only on Weekdays

You only have to add another validation to allow users to approve expense reports on weekdays, and this is possible by adding a new check to the `approve` action in the `ReportsController`. Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  #...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        # 👇 new code 
        if Date.current.on_weekday? # can only approve on weekdays
          @report.status = "approved"
          @report.save
 render json: @report
        else
 render json: {message: "Can only approve on weekdays"}, status: 401
        end
        # 👆 new code 
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

[The function `Date.current.on_weekday?`](https://api.rubyonrails.org/classes/DateAndTime/Calculations.html#method-i-on_weekday-3F) returns true if it's a weekday (Mon-Fri) and false otherwise. Users who try to approve during the week will get an error.

At this point, you've fulfilled all the requirements you've received so far! 🚀 It's time to go back to the client and discuss the progress you've made. 

> Up until here, all the changes in the code are available in the [`add-abac` branch of the repository.](https://github.com/auth0-blog/rails-api-authorization/tree/add-abac)

## What About Policies?

You're introducing a lot of extra complexity in the application code that needs to be recreated by each environment, such as web, mobile, CLI, etc. Using a policy engine can streamline application decision-making. 

[A policy](https://csrc.nist.gov/glossary/term/access_control_policy) is a set of rules defining a software service's behavior. There are access control systems like [Open Policy Agent (OPA)](https://www.openpolicyagent.org/), a full-featured policy engine that offloads policy decisions from your software so you don't have to implement it from scratch, or [Policy-Based Access Control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control), where access control decisions are made based on the business roles of users and is combined with policies.

You won't implement PBAC for the sake of this tutorial, but I thought it was interesting for you to know that decision-making engines like these exist.

## Oh, No. What's Next?

You are showing your implementation to the client, and they're satisfied, but as usual, they came back with more requirements 🥲 

- Users who are managers can see the reports of their directs, plus the reports of their directs' directs, and so on 😵‍💫

You think of a way to implement this with your current solution and... recursiveness 🥲 you know this is possible, but you also start exploring what options are out there for these scenarios. You bump into Relationship-Based Access Control, which seems interesting 🤔 because you feel like basing your implementation on the relationships of your users could work, but you need to do more research. 

## Conclusion 

When we talk about attributes, we refer to properties of the entities of your application; in the expense management application example, we are talking about attributes of a user or an expense report. Attribute-Based Access Control is an authorization model that allows you to make decisions based on these attributes. ABAC gives you more granularity than RBAC because you can specify access control on specific resources other than a role that usually includes more than one resource. 

In the next blog post, you'll learn about ReBAC and its implementations. 

How to Implement Attribute-Based Access Control (ABAC) in a Ruby On Rails API?

Nowadays you could replace your physical driver's license with a digital, cryptographically verifiable one. Let's learn about it and how to start using them.

A driver's license is a document that gives legal authorization for people to drive certain types of vehicles, and they're often made of plastic and have the size of a credit card, so you usually store it in your wallet. Some countries, like Australia, the UK, and the US, use driver's licenses to prove their citizens' identity.

As driver's licenses continue to play a crucial role in verifying your identity, it makes sense that they evolve alongside our increasingly digital world. That's where Mobile Driver's Licenses come in. In this blog post, you'll learn more about them and how to use them.

## What is a Mobile Driver's License (mDL)?

Let's start from the beginning. **A Mobile Driver's License (mDL) is a driving license that resides on a mobile device** instead of physically in your wallet. The beauty behind an mDL is that **they are cryptographically verifiable**, meaning you can use cryptography to verify their information and authorship.

An mDL is a type of [Verifiable Credential (VC)](https://auth0.com/blog/what-are-verifiable-credentials-why-you-should-care/#What-are-Verifiable-Credentials) and they're an [ISO Standard](https://www.iso.org/standard/69084.html). As a VC, mobile driver's licenses also have an issuing authority, which is the authorized organization issuing the driver's license; for example, in the US, that'd be [the DMV](https://en.wikipedia.org/wiki/Department_of_motor_vehicles). There is an mDL holder, and it's the person to whom the mDL is issued. Finally, there is an mDL verifier, which is the entity that can verify the authorship of the mDL.

### mDL Step by Step

![mDL Roles](https://images.ctfassets.net/23aumh6u8s0i/7xGF2PSKekpejYPX11EOse/157c1415ce452ff436954197c1e90eb7/mdl-roles.png)

1. **Issuing:** A user can request an mDL from an issuing authority using their digital wallet. In mDL, this wallet is called an mDoc reader. An mDoc is a document that resides on a mobile device, so the mDoc reader can retrieve an mDoc for verification purposes. The issuer will verify the user's details and use their private key to sign and issue the mDL.

2. **Presenting:** A user can show their mDL using an application called an mDL reader to prove their identity, for example. This application would request the mDL data, which must be verified later.

3. **Verifying:** The mDL reader is in charge of cryptographically verifying the mDL data.

<include src="SmallBannerCTA"
         imgLink="https://images.ctfassets.net/23aumh6u8s0i/12gXwIIea5F2nkS1hNQFWy/70e57fab64095553831e4f4a0ee497d9/mdl-logo.png"
         text="Want to learn more about mDL?"
         linkText="Visit → mdl.me"
         link="https://mdl.me"/>

## Where Are We Today?

Today, many countries have started implementing and deploying pilots for Mobile Driver's Licenses. In the US, for example, there are already [multiple states that have mDL implementations](https://www.aamva.org/jurisdiction-data-maps#anchorformdlmap) in place. [The TSA (Transport Security Administration) has been accepting digital credentials as proof of identity since early 2022](https://www.tsa.gov/travel/frequently-asked-questions/when-will-phased-digital-id-rollout-start-which-airportsstates).

In November 2023, the [European Union also submitted a proposal to introduce mobile driver's licenses](https://data.consilium.europa.eu/doc/document/ST-15808-2023-INIT/en/pdf) and make them fully equivalent to their physical counterpart.

These are just a few examples to tell you that Mobile Driver's Licenses are coming to stay, and many other countries will start piloting and adopting them. Many companies are also beginning to build their own mDL readers and implementations; in fact, [the mDL ISO Standard was tested at the Interoperability Event](https://blog.spruceid.com/iso-iec-18013-7-interoperability-event-results/) where companies joined forces to test their implementations. Some mDL readers and mDL implementers included **Google, the National Institute of Standards and Technology (NIST), Okta, Samsung**, and more. You can read more about it in the [event results publication](https://docs.google.com/document/d/1M4ufcKqmj8gycNovslOSWzFB2nB1o1eu/edit?ref=blog.spruceid.com#heading=h.gjdgxs).


## Where to Use mDL?

Mobile Driver's Licenses have many potential use cases, but some of the most relevant are:

- Prove your Identity: as mentioned above, many countries use driver's licenses as proof of identity, and mDLs should be equivalent to prove someone's identity.
- Improve business processes involving Know Your Customer (KYC) and Anti-Money Laundering (AML)

## Getting Started with mDL

There are a few ways you can get started with mDL, the first one being going to [mdl.me](https://mdl.me) to learn more about it, how it works, and use the debugger to understand what's happening under the hood.

You can also start playing with a library like the one we crafted at [Auth0 Lab, mDL](https://github.com/auth0-lab/mdl). This NodeJS library allows you to issue and verify mDL [CBOR](https://cbor.io/) encoded documents. This library allows you to have a good start to understand how mDL works but **it's important to mention the library alone allows you to create, parse and validate mDL but it's not enough if you need to exchange mDLs.** So for example if you want to present mDL you need to implement a protocol such as the one in the [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html).

### Using the mDL library

First, you need to install the library. For that, run the following in your terminal:

```bash
npm install @auth0/mdl
```

> Note this blog post is for educational purposes and not meant to be used in production. In order to use mDL you'd need a protocol on top to exchange the data, such as the one in [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html) for presenting mDLs.


### Issuing a Credential

Let's take a look at what the code for issuing a new credential would look like:

```js
import { MDoc, Document } from "@auth0/mdl";
import fs from "node:fs";

// Create Document: representation of the mDL data
const document = await new Document('org.iso.18013.5.1.mDL')
  .addIssuerNameSpace('org.iso.18013.5.1', {
    family_name: 'Jones',
    given_name: 'Ava',
    birth_date: '2007-03-25',
  })
  .useDigestAlgorithm('SHA-512')
  .addValidityInfo({
    signed: new Date('2023-10-24'),
    validUntil: new Date('2050-10-24'),
  })
  .addDeviceKeyInfo({ deviceKey: devicePublicKeyJWK })
  .sign({
    issuerPrivateKey,
    issuerCertificate,
    alg: 'ES256',
  });

// Create MDoc
const mdoc = new MDoc([document]);

// CBOR encode the MDoc
const encodedMdoc = mdoc.encode();
```

This script is doing a few things. First, it adds the document type `org.iso.18013.5.1.mDL` to the `Document` instance; this refers to the mDoc document type that is used to identify the ISO driving license standard. Then, it adds the name and birth date attributes of the holder.

The digest algorithm is set to `SHA-512`, and it's used to compute the digest of each attribute. A digest algorithm is a cryptographic hash function that maps a large block of data into a fixed-size output (512 bits or 64 bytes in this case). The verifier will use the same algorithm to verify the disclosed attributes. This is related to the way that [selective disclosure](https://www.w3.org/TR/vc-data-model/#dfn-selective-disclosure) is implemented in mDL.

Then you'll see the `validityInfo`, which is the period of time the document is valid, and finally the device key information in the `addDeviceKeyInfo` method. Here, you specify the public key of the device that will hold the mDL to ensure that the mDL will only be used by the device that holds the corresponding private key. In other words, a presentation will only be accepted if it's signed with the private key that corresponds to the public key in the mDL.

Finally, you use the `sign` method to sign the document using the issuer's private key and certificate.

### Requesting a Credential

Now let's take a look at what should happen on the verifier side. The verifier is the entity that will request the mDL from the holder to later on verify its authenticity. 

Depending on the use case, the holder could have an application on their device that can serve as mDL reader (for example if they're opening a bank account online from their phone) or they could have be requested to show their mDL and the mDL reader resides in another device (for example, to enter a bar and prove that the holder is 18 years old or more, the person at the entrance could have an mDL reader where people can present their mDLs).

The mDL reader requests the mDL data that it needs and the holder uses the digital wallet to present the credential. When the holder presents the credential, the verifier needs to first generate an [ephemeral key pair](https://csrc.nist.gov/glossary/term/ephemeral_key_pair) and a nonce. An ephemeral key pair it's a short-term key pair generated when needed, and the nonce is a random value that is used to prevent replay attacks. The verifier then sends the nonce and the ephemeral public key to the holder. 

You could use [the JOSE package](https://www.npmjs.com/package/jose), for example, to generate these short-term keys. After installing `jose` with `npm install jose` you could do something like the following:

```js
const {generateKeyPair} = require('jose');
const ephemeralKey = await generateKeyPair('ES256')
```

### Generating a Device Response

Once the holder receives the nonce and the ephemeral key, their device can generate a device response. The device response is a signed message that contains the mDL and the nonce.

```js
const deviceResponseMDoc = await DeviceResponse.from(mdoc)
  .usingPresentationDefinition(PRESENTATION_DEFINITION_1)
  .usingHandover([holderNonce, clientId, responseUri, verifierGeneratedNonce])
  .authenticateWithMAC(DEVICE_JWK, ephemeralPublicKey, 'HS256')
  .addDeviceNameSpace('com.foobar-device', { test: 1234 })
  .sign();

const encodedSessionTranscript = getSessionTranscriptBytes(
  { client_id: clientId, response_uri: responseUri, nonce: verifierGeneratedNonce },
  holderNonce,
);

const deviceResponse = deviceResponseMDoc.encode();

sendToVerifier({ deviceResponse, encodedSessionTranscript });
```

With the mDL issued to the holder, the device creates a new device response using the `DeviceRespose` class. The `usingHandover` method is used to specify the date the verifier sent along with a nonce generated by the holder. Here, the `PRESENTATION_DEFINITION_1` constant refers to [which proofs the verifier is requesting from the holder](https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-definition). An example could be:

```js
export const PRESENTATION_DEFINITION_1 = {
  id: 'mdl-test-age-over-18',
  input_descriptors: [
    {
      id: 'org.iso.18013.5.1.mDL',
      format: {
        mso_mdoc: {
          alg: ['EdDSA', 'ES256'],
        },
      },
      constraints: {
        limit_disclosure: 'required',
        fields: [
          {
            path: ["$['org.iso.18013.5.1']['age_over_18']"],
            intent_to_retain: false,
          },
        ],
      },
    },
  ],
};
```

In this case, the verifier is asking for an mDL with just one of the holder's attributes to verify that the holder is over 18 years old. You can find other examples in the [mDL repository](https://github.com/auth0-lab/mdl/blob/41724db924161c680c6fff0aa80450a8a2aa7286/__tests__/issuing/config.ts#L108). 

The `authenticateWithMAC` method is used to specify the way in which the device response is authenticated. In this case, it's authenticated [with a MAC](https://datatracker.ietf.org/doc/html/rfc9052#name-mac-objects) using the `HS256` algorithm. The secret for this MAC is computed as follows:

- On the holder's side it uses the public ephemeral key generated by the verifier plus the private key of the device.
- On the verifier's side it uses the private ephemeral key generated by the verifier plus the public key of the device.

The `addDeviceNameSpace` method adds a namespace to the device response.

Finally, the `sign` method is used to sign the device response.

### Verifying the Device Response

Finally the verifier verifies the `DeviceResponse`.

```js
const verifier = new Verifier([ISSUER_CERTIFICATE]);
await verifier.verify(encoded, {
  ephemeralReaderKey: ephemeralPrivateKey,
  encodedSessionTranscript,
});
```

First you need to construct a `Verifier` instance with a list of the issuer's certificates you trust.

Then you call the `verify` method with the encoded device response, the private key of the ephemeral key pair, and the encoded session transcript. This is a structure defined by the ISO standard. You can learn more about it in the  [ISO 18013.5 (section 9.1.5.1 - Session transcript)](https://www.iso.org/standard/69084.html)

## What's Coming: Verify mDL with Auth0

You can [sign up for the waitlist](https://regionalevents.okta.com/mdlearlyaccess) to be one of the first to know when mDL with Auth0 is available in Early Access.

You can also go to [mdl.me](https://mdl.me) to learn more, and if you know about any other mDL libraries out there, let us know so we can include them in the list of resources!

What is a Mobile Driver's License (mDL) and How to Start Using Them

sofia-prosper

Sofía Prósper, a trained architect, is a passionate Developer Advocate and the current Partner Manager of Auth0 by Okta Marketplace. She has a diverse background focused on architecture, design, art, and verbal communication. Recipient of the Spanish Data Protection Agency Prize in 2018, in her spare time, she has worked since as an advocate defending Privacy, Digital Rights, and Digital Sovereignty in Spain. Outside her daily work, you can find her illustrating her travel journal, cooking for friends, collecting recipe books, and joining side projects in beautiful Galicia, Spain.

Senior Developer Advocate and Partner Manager of the Auth0 Marketplace

Sofía Prósper Díaz-Mor

Eutelo Pena

All my career I have been oriented to the creation of software products for mobile devices. Initially, as an Android & iOS developer, implementing biometric solutions in Gradiant / Alice Biometrics. Over the years, my role has been changing towards the management layer, the product and the leadership of teams, carrying it out in places like Bank Sabadell, InAuth (AMEX group), Verse (Square group) or Eccocar. Currently back home, where I am helping to make digital onboarding easier for people.

Head of Product at Alice Biometrics

Facial biometrics revolutionizes digital processes. Implemented thoughtfully, it provides businesses a competitive edge while safeguarding privacy.

## Introduction

In the era of digital transformation, businesses are constantly looking for ways to streamline their processes and enhance security. One technology that is rapidly gaining traction in this regard is facial biometrics, which includes face recognition and face liveness detection. This technology is revolutionizing processes such as the digital onboarding of new users and adding an extra layer of security to prevent AI bots and fraudsters from causing harm. Auth0 has included facial biometrics features at [Auth0 marketplace](https://marketplace.auth0.com/partners/alice-biometrics).

## The Power of Facial Biometrics

Facial biometrics technology uses unique features of a person’s face to verify their identity. It’s a powerful tool that can be used in a variety of applications, from unlocking smartphones to verifying identities at border controls.

### Face Recognition

Face recognition technology works by comparing selected facial features from a given image with the photo ID for the onboarding use case or with the facial template stored for authentication, password reset, or access control use cases. It’s a fast and accurate way to verify the identity of users, making it an excellent tool for digital onboarding and multiple account opening. 

### Face Liveness Detection

Face liveness detection is a technology that can determine whether the source of a biometric sample is a live human being or a representation of a human being. This technology is crucial in preventing fraudsters from using photos, videos, or masks to impersonate legitimate users.

![](https://images.ctfassets.net/23aumh6u8s0i/72e8GkU7K8cuSoxC8JrleF/c3d57801015e621f725020f2db951b8e/Biometric_3.jpg)

## How Facial Biometrics Enhance Businesses Processes

Facial biometrics can significantly enhance several aspects of digital security and user experience. Let’s delve into how this technology can improve authentication, bot prevention, account recovery, and password reset processes.

### Digital Onboarding

Digital onboarding is the process of integrating new users into a system. It’s a critical process for businesses, as it’s often the user’s first interaction with the company. Facial biometrics can streamline this process by quickly and accurately verifying the identity of the user.

For example, a bank can use facial biometrics to verify the identity of a new user opening an account. The user simply takes a selfie, which is then compared to a photo ID they provided. The process is quick, easy, and secure, providing a positive experience for the user while ensuring the bank is complying with KYC (Know Your Customer) regulations.

### Authentication

Facial biometrics provide a secure and user-friendly method for user authentication. Instead of remembering complex passwords, users can simply use their faces as a form of identity verification. This not only enhances security but also improves the user experience by offering a quick and convenient authentication method.

### Bot Prevention

Bots pose a significant threat to digital security. They can carry out a variety of malicious activities, from spamming to automated attacks. Facial biometrics, particularly face liveness detection, can help prevent bots by ensuring that a real, live person is behind each action.

### Account Recovery

Account recovery can be a complex process. Traditional methods often involve answering security questions or receiving a code via email or SMS. With facial biometrics, users can recover their accounts by simply verifying their identity with their face. This makes the account recovery process more secure and user-friendly.

### Password Reset

Resetting passwords can be a hassle for users. However, with facial biometrics, this process can be simplified. Users can verify their identity using their faces and then set a new password. This not only streamlines the password reset process but also adds an extra layer of security.

![](https://images.ctfassets.net/23aumh6u8s0i/1PBtpzTeahMOcqlpm1MoL3/09f0029a9c41c405493f0549b51a7397/Biometric_2.jpg)

## Adding Security to Business Processes

In addition to streamlining digital processes, facial biometrics can also add an extra layer of security. By verifying the identity of users at key points, businesses can prevent AI bots or fraudsters from gaining access to sensitive information or systems.

For instance, a business could use facial biometrics to verify the identity of users before they make a transaction. This could prevent a fraudster who has gained access to a user’s account from making unauthorized transactions.

## Conclusion

Facial biometrics offer a powerful tool for businesses undergoing digital transformation. By streamlining the digital processes and enhancing security, this technology can provide a competitive edge while protecting against AI bots and fraudsters. As with any technology, it’s important to implement it in a way that respects user privacy and security. With these considerations in mind, facial biometrics can play a key role in the digital transformation journey. If you want to try biometrics, please visit [Alice Biometrics](https://marketplace.auth0.com/partners/alice-biometrics) profile at Auth0 marketplace to learn more.

Facial Biometrics: The Key to Digital Transformation and Enhanced Security

Shreya Gupta

Shreya is the Developer Advocate for Auth0 for Startups. She previously founded a non-profit called Bit Project, worked at a YC-backed Startup as a Developer Advocate, and currently hosts The Developer Diaries podcast. Through each experience, she has found her love for building resources and tools that help move the needle for developers. Outside of work, she enjoys traveling, watching K-Dramas, and drinking boba.

Developer Advocate, Startups

Calah Vargas

Calah Vargas is the Associate Manager of Product Led Growth, focusing on nonprofits, startups, and partnerships. She works on product marketing and customer marketing initiatives. Outside work, you can find her cooking, trying new restaurants, and traveling with friends and family.

Associate Manager, PLG

Before you start working with AI developer tools, understand what it could mean for you, your product, and your customers.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Note:</strong><br> 
  This blog post is based on interviews conducted with startup founders, engineering managers, data scientists, and risk analysts in the Artificial Intelligence and Machine Learning space.<br> 
</div>

Evaluating tools that can help optimize your development processes? Maybe you’re entirely building alongside [Devin, the first AI software engineer](https://www.cognition-labs.com/introducing-devin) to get your app to market faster, generating code snippets for your React app with [V0.dev](https://vercel.com/blog/announcing-v0-generative-ui), or using [GitHub CoPilot](https://thehackernews.com/2024/03/github-launches-ai-powered-autofix-tool.html) to help patch your website’s security flaws.

While productivity and efficiency are hallmarks of development success, security and privacy are just as paramount to protect your product and maintain customer trust. According to [Snyk’s 2023 AI Code Security report](https://snyk.io/reports/ai-code-security/), **80% of developers are bypassing security policies to use AI**.

But modern-day [Generative AI](https://news.mit.edu/2023/explained-generative-ai-1109) tools don’t typically have the built-in capability to determine whether the data it is exposed to is sensitive. It’s completely up to the user to take precautions and set up the proper protocols when choosing to use one of these tools. Let’s explore the potential risks of using AI tools in the dev process and what questions you could ask yourself to help make more informed decisions – for you, your product, and your customers.

## Productivity vs. Risk

According to Snyk’s blog, [How to Embed Security in AI-assisted software development](https://snyk.io/blog/snyk-and-atlassian-embed-security-ai-assisted-software-development/), “Code generation, using generative AI… is the area that stands to offer the greatest productivity benefits — **and the highest potential for introducing risk**.“

AI tools can help accelerate the process of taking an idea and building an MVP with limited resources. Although engineering productivity cannot be tracked by a single metric for all, it’s easy to see how these tools are already helping developers reduce time spent in generating code and improving the quality of code.

Like with all third-party tools, to strike the perfect balance between productivity and risk, it’s important to recognize ways in which these tools can hurt your product and customer security, now and in the future. In many situations, risk cannot be quantified, but companies can have an increased or decreased risk factor (risk tolerance) depending on:

* Industry
* Product type and use case
* Company stage

For example, risk tolerance can be higher for startups in growth mode, especially in industries outside of security.

## Risk Prevention Strategies

Let’s explore the most common risks associated with AI tools and mitigation strategies outlined by some engineers. 

Nonprofit OWASP (The Open Worldwide Application Security Project) documented a [list of potential security risks](https://owasp.org/www-project-top-10-for-large-language-model-applications/) when deploying and managing Large Language Models (LLMs) – some examples include:

* Sensitive Information Disclosure (LLM06) - LLMs can inadvertently disclose sensitive, proprietary, or confidential information leading to privacy breaches, intellectual property theft, and unauthorized access
* Prompt Injection (LLM01) - Attackers can manipulate LLMs through crafted inputs, causing the LLMs to execute the attacker’s intentions
* Overreliance (LLM09) - Systems or people overly dependent on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs

When adding these tools to your tech stack, do these questions come to mind?

* How are you deciding which tools to use to increase your efficiency and productivity? 
* Do you have an internal vetting process for third-party vendors? How are you updating this for AI tools?
* Will you be prompting the AI tools with customer data and PII or proprietary restricted information? Are you in line with your applicable regulatory compliance frameworks? (GDPR, etc.)
* Does this tool abide by your corporate guidance?
* Do you have customer permission to use their data in this way?
* How could these tools impact you?
* What risks will you, your product, and your customers face?
* What guidance or guardrails does the tool have to protect your data as a user? Two popular types of AI developer tools are those for engineering productivity and those for general use, and the available configurations may vary.

We interviewed a few engineers (anonymously) about what they’re doing to minimize the risks associated with AI developer tools. Here’s a breakdown of some of the most common concerns and questions engineers are asking to reduce any harmful and inadvertent impact while coding with Gen AI tools.

* PI and copyright concerns
    * Once one of these tools generates code, who is the owner?
    * What happens if the tool is suggesting the same code to another customer, maybe even a competitor?
    * If you use AI tools in order to create a customer-facing chatbot, and a customer includes PII in their prompt – who is in charge of monitoring and removing this data and ensuring it isn’t being used to re-train models?
* Overreliance
    * Generating a few lines of code vs a few files of code – how familiar are you with the code in your product, and how much do you trust it?
    * Are you aware of the potential risk of [AI hallucinations](https://www.ibm.com/topics/ai-hallucinations) and how are you reducing it?
        * AI hallucinations are outputs from models that are nonsensical or inaccurate. For example:
            Question: where can I find the help center?
            Context: you’re looking for a website like [domain].com/help or support.[domain].com
            AI answer: the help center is located on the ground floor of this building.
* How are you updating your code and content review processes to deal with Gen AI?
* Data Exposure
    * Can you make sure your own data won't be used to answer prompts for competitors or malicious actors?
    * What are practical and technical strategies you can take to prevent data exposure?
    * Do you have strict policies and training for engineers when they are using these tools, or are you exploring third-party tools that tackle data leak prevention?

There’s no specific path to being completely secure from the risk of AI tools today, but there are many different strategies you can take to build strong guardrails to protect code and mitigate risk. Ensuring restrictions are very specific when engineers are using AI tools like Devin and code review is a must.

## AI Developer Tools Now and Tomorrow

AI tools for developer productivity are becoming increasingly popular. Further down the line, a startup founder might be able to ideate, possibly write [pseudocode](https://builtin.com/data-science/pseudocode), and use these tools to bring their idea to life. They might be able to start testing in a matter of minutes, not months.

If you’re an early-stage company, you might be eager to get started and may not have as much internal guidance as a large corporation. We hope this blog helps you start to outline the potential risks and considerations when evaluating AI tools for developer productivity. 

[Auth0 for Startups](https://auth0.com/startups) is empowering early-stage startups – tell us what we can do to best support you and your team!

_These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments or all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at [okta.com/agreements](http://okta.com/agreements)._

Security Considerations in the Time of AI Engineering

matt-raible

Matt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt is a frequent contributor to open source and a big fan of Java, IntelliJ, TypeScript, Angular, and Spring Boot. 

Matt Raible

Learn how to build a secure CRUD app with Spring Boot and Angular. You'll use Auth0 for authentication and authorization and Cypress to verify it all works.

Build a Beautiful CRUD App with Spring Boot and Angular

joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Joey deVilla

Smartphones include EXIF metadata in their photos. Here’s how to read, write, and erase it using Python.

How to Read and Remove Metadata from Your Photos With Python 

poovamraj

I'm a senior software engineer at Auth0. From Rust to Kotlin, Java to JavaScript, I love exploring new languages, technologies, and frameworks. Away from the screen, you can find me in the Alps hiking.

Senior Software Engineer

Poovamraj Thanganadar Thiagarajan

We added support for hooks and rewrote it in TypeScript, made API improvements, improved Expo, Android, and iOS integration, and we think you’ll like it.

**We’re excited to announce the general availability of version 3.0 of our React Native SDK!** In this latest version, we’ve transformed our [`react-native-auth0` SDK](https://github.com/auth0/react-native-auth0) to work with two goals in mind:

* To work with the latest and greatest version of React Native, and 
* To create improvements to make your life as a developer easier. 

Read on to find out more about the new version of the SDK!


## What Changed?

We wanted to improve your developer experience and let you focus on what your applications do. We listened to your feedback, made changes to remove the obstacles that were getting in your way, and cut out the confusing parts that were slowing you down.

In this new version of the SDK, we made the following changes:

**100% support for hooks.** You’ve been asking for access to our authentication APIs (such as login via SMS, email, and so on) through hooks. That makes sense — after all, the general consensus is that React hooks generally make for more concise code that’s easier to read and maintain. So we went “all in”: our SDK now has 100% support through hooks! (And yes, you can still use it “the old way” too!)

**Improved `user` object and credentials.** The `User` object (available through our hooks API) isn’t static anymore and doesn’t just capture a snapshot of the user’s information at the moment of login. Instead, it dynamically updates to reflect changes to the user in real time. You can now force-refresh the user credentials, check their validity, and you can do so using either hooks or classes.

**Expo improvements.** The SDK now seamlessly integrates into any Expo project with a single line of configuration. You just specify the domain, and the SDK automatically generates the other configuration lines. We’ve also raised the minimum supported version of Expo to a more stable version (currently v48).

**Completely rewritten in TypeScript.** This allows us to take advantage of TypeScript’s type safety and removes any confusion about what data you provide to and receive from the SDK’s methods. (It also has the side benefit of making the SDK easier to maintain and update, which we believe will provide future benefits for you.)

**Improved Android/iOS interoperability.** We switched from React Native’s Android and iOS SDKs for web authentication to our own SDKs, which we use in the `Auth0.Android` and `Auth0.Swift` packages. Ours are battle-tested, more reliable, and less buggy, which provides your users with a better login/logout experience.


## Requirements

Naturally, you’ll need an Auth0 account to use the SDK. <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">You can sign up for a free account here;</a> the free version supports unlimited login/logout for up to 7,000 users and ten applications.

### Which versions of React Native are supported?

Version 3 of our React Native SDK targets apps using React Native version `0.60.5` and up.

### Is Expo supported?

This SDK _is_ compatible with Expo [custom development client](https://blog.expo.dev/introducing-custom-development-clients-5a2c79a9ddf8) and [EAS (Expo Application Services)](https://expo.dev/eas) builds. 

⚠️ Please note that the SDK is _not_ compatible with the [Expo Go](https://expo.dev/client) app because of the SDK’s use of custom native code.

### Which versions of Android and iOS are supported?

Version 3 of our React Native SDK supports the following mobile platform versions:

* **Android SDK 28, also known as “Android 9” or “Pie” (or later).** Android 9 was released in August 2018. 84% of devices active in the Play Store at the time of writing (August 2023) will run applications targeting this Android version. The oldest phones that support this version of Android date back to late 2017.
* **iOS 13 (or later).** iOS 13 was released in September 2020. As of the end of February 2023, almost 88% of iOS users were running iOS 16, with nearly 12% running iOS 15. iOS 14 users accounted for about 0.2% of users, while users of iOS 13 and earlier comprised the remaining 0.3%. The oldest iPhones that will run iOS 13 are the 6S and 6s Plus, which date back to 2015. Simply put, you’re not really leaving anyone behind by setting iOS 13 as the oldest supported version.


## How to Find Out More

* [**The `react-native-auth0` GitHub repository.**](https://github.com/auth0/react-native-auth0/) You can find the code here, as well as more than enough documentation to get started using the SDK — it’s all in the README file.
* [**The migration guide.**](https://github.com/auth0/react-native-auth0/blob/master/MIGRATION_GUIDE.md) This document covers the improvements that we made going from version 2 to version 3, changes that might break your current implementations, and changes to the format for callback URLs. If you’re working with projects based on the v2 SDK, make sure you read this.
* **Quickstarts.** The fastest way to create a new project that uses the Auth0 React Native SDK is to use a quickstart. We have a [**React Native quickstart**](https://auth0.com/docs/quickstart/native/react-native/interactive) and an [**Expo quickstart**](https://auth0.com/docs/quickstart/native/react-native-expo/interactive).
* **Sample projects.** These sample projects will help you get acquainted with the Auth0 React Native SDK in general and version 3 in particular:
	* [Login/logout app using React components](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login)
	* [Login/logout app using React hooks](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Hooks)
	* [Login/logout app using Expo](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Expo)
* [**Code examples.**](https://github.com/auth0/react-native-auth0/blob/master/EXAMPLES.md) This is a collection of code snippets that shows you how to perform specific tasks using the SDK.


## Summary

We made version 3 of the React Native for Auth0 SDK based on your feedback to improve the developer and user experiences. With support for hooks, better integration with both Android and iOS, strong typing support, and fewer bugs, we’re sure you’ll enjoy working with this version!

Introducing Auth0 React Native SDK 3.0!

Ryan Friess

Dynamic and seasoned, Ryan holds the role of Senior Sales Engineer at ID.me, a prominent platform specializing in identity proofing, group affiliation verification, and authentication. Ryan's extensive background in both sales and engineering enables him to seamlessly fuse technical intricacies with client requirements. He excels at providing custom solutions that effectively tackle intricate challenges across diverse sectors.

Sr. Sales Engineer - ID.me

Enhance Auth0’s authentication and elevate trust by combining it with ID.me’s verified identities.

In today's interconnected digital landscape, ensuring robust security for online platforms has become a top priority. As the number of data breaches and cyber-attacks continue to rise, businesses and organizations must employ innovative solutions that go beyond traditional authentication methods. Two industry giants, Auth0 and ID.me, have joined forces to create a powerful alliance that offers advanced security measures by integrating Auth0's identity and access management expertise with ID.me's cutting-edge authentication and identity verification capabilities. 

![ID.me & Auth0](https://images.ctfassets.net/23aumh6u8s0i/2MEfvv6hdNXWLrBzbZQNfz/b8ac2c26229144aa7cf12473e4a1c11e/01_Idme.png)

## The Power Duo: Auth0 and ID.me

In the realm of consumer identity and access management, Auth0 has been a trailblazer with its versatile authentication solutions, catering to diverse needs across industries. By providing a seamless and secure way for users to log in to applications and services, Auth0 has revolutionized the way developers handle identity and access management. But what happens when consumer authentication is not enough, and the business needs a way to associate a user’s true identity to their request to access your application? That's where ID.me comes in. 

## How Does It Work? 

ID.me exists to put individuals in charge of their own login, their own data, and their own ID cards to allow the login and the data to move with the user. ID.me’s primary focus lies in validating users' identities through a multi-layered approach, ensuring that the person on the other end of the screen is who they claim to be, and our user’s know they can take their portable identity with them anywhere they see the green ID.me button. This level of assurance goes far beyond the standard username-password-OTP combination, effectively thwarting potential fraudulent activities for higher-risk transactions. 

## Turnkey Integration of ID.me on Auth0

We wanted a way for developers and business decision makers to easily leverage the benefits of ID.me’s trusted and portable credentials within their existing Auth0 implementation in a turnkey manner - eliminating the need of custom development. Therefore, we worked closely with the Auth0 team to create **three turnkey marketplace listings**: 

- [ID.me Post-Login Action](https://marketplace.auth0.com/integrations/idme)
- [Social Login (Community)](https://marketplace.auth0.com/integrations/idmecommunity)
- [Social Login (Identity)](https://marketplace.auth0.com/integrations/idme-identity)

In just four configuration steps, you can benefit from ID.me’s network of 110M+ members and 47M+ IAL2 verified members for your secure authentication and identity verification needs. 

![Cconfiguration Steps](https://images.ctfassets.net/23aumh6u8s0i/7pJt2OAXv9rzBWIY24KIVS/6b30010556c4dfd158b2254ed4cb64fe/02_idme.png)

It’s as simple as selecting the Add Integration button on the marketplace listings, entering your ID.me credentials, and applying the post-login action and social login to your appropriate Auth0  applications. We’ll go into more detail in the next section, but as a sneak peak, your end result will look something like this:

![Integration](https://images.ctfassets.net/23aumh6u8s0i/6ipkP21q1On13NKx4cn8Rs/0bfcf3f9a7dfbce35deb0fb6bef6ffcf/03_idme.png)

- **Pathway #1** - By providing users with the choice of how they prefer to log into your application, customer satisfaction increases, pass rates improve, and ID.me provides 
support for any of your users that elect to log in through ID.me - effectively _reducing the burden and lowering the costs of password resets to your call center or IT Help Desk_. After successful authentication or verification, a corresponding Auth0 user account will be created with appropriate ID.me-validated attributes mapped within the user account.
support for any of your users that elect to login through ID.me - effectively _reducing the burden and lowering the costs of password resets to your call center or IT Help Desk_. After successful authentication or verification, a corresponding Auth0 user account will be created with appropriate ID.me validated attributes mapped within the user account. 

![Pathway #1](https://images.ctfassets.net/23aumh6u8s0i/5Br6WvqABfS3DtVAjTAeML/ab441728797ab912328c7ae80213f8b2/04_idme.png)

- **Pathway #2** - In order to support your existing user base, users can log into their existing account, and can be redirected to ID.me for verification. After successful verification, the individual’s ID.me attribute payload will automatically be mapped within the existing Auth0 user account. 

## For Developers - Let’s Dive a Little Deeper

While integrating ID.me is turnkey within your Auth0 tenant, it’s still important to understand the nuances of the user journey and data flow. The architecture diagram below provides an overview of the two pathways we just discussed: ID.me as a Social Login and ID.me as a Post-Login Action.

![ID.me](https://images.ctfassets.net/23aumh6u8s0i/4CHSxbdUrMVfmKWxhWGBd5/3905e1176eb5ec191575bd955fef71e2/05_idme.png)

The top half of the architecture diagram highlights the Auth0 login with the ID.me post-login action pathway, in which the user elects to log into their existing Auth0 credentials, and will be redirected to ID.me for verification. Take note that an indicator is used to determine when to prompt an existing user for verification with ID.me, and that post-successful verification, that indicator will be updated within the user's application metadata. 

The bottom half of the architecture diagram demonstrates the data flow for the Social Login pathway. This is where our partners receive the benefit of the ID.me network, allowing 110M users to login to your application with their pre-verified ID.me credentials in just a few clicks. 

Now, let’s take a look at an even deeper dive and look at an overview of ID.me, as well as what the exact steps needed to configure the ID.me integrations in this video. 

<AmpContent>
<amp-youtube
    data-videoid="Vd9zZcsGUkE"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vd9zZcsGUkE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Conclusion 

The digital landscape is continually evolving, demanding innovative solutions to combat cybersecurity threats effectively. The partnership between Auth0 and ID.me brings together two industry leaders, each contributing its strengths to create a security ecosystem that surpasses traditional authentication methods. By combining Auth0's identity and access management prowess with ID.me's authentication and identity verification capabilities, we can ensure a higher level of trust, security, and compliance while providing a seamless user experience. Together, we are transforming the way to approach digital security, setting a new standard for safeguarding user identities in an ever-changing world.

Strengthen Your Application Security beyond Authentication

We asked ChatGPT to write code to integrate Auth0 into an Android app after its initial release. The code didn’t work then. Will it work this time?

ChatGPT Tries to Add Auth0 Authentication to an Android App, Round Two!

There are different ways to implement an authorization system and the one you chose depends on your application's needs. Role-Based Access Control (RBAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

How to Implement Role-Based Access Control (RBAC) in a Ruby On Rails API?

We asked ChatGPT to write code to integrate Auth0 into an iOS app after its initial release. The code didn’t work then. Will it work this time?

## What Happened in Round One

Barely two weeks after the initial release of ChatGPT, I tidied up my home office/studio, put on my newest Aloha shirt, and started asking the newly-released AI some questions about OAuth and Auth0. The result was the video below, which you’ll find on the OktaDev YouTube channel: _Chatting with ChatGPT About Auth0:_

<iframe width="600" height="338" src="https://www.youtube.com/embed/rfkgdorO-8Y" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

ChatGPT gave correct answers to these questions:

- “What is OAuth?” and a follow-up question where I asked it for a more layperson-friendly version of its initial answer.
- “What is OIDC?” and the same follow-up question as my previous one.
- What is an ID token?
- What is an access token?
- What is a refresh token?
- Are there security downsides to using refresh tokens with indefinite lifespans?

ChatGPT didn’t do as well when I asked it, “How do I write an iOS app that uses Auth0 for login?” The set of steps it suggested was correct, but it said that I should use the  `Auth0.authentication()` method to make the Universal Login screen appear. **No such method exists**.


## And Now, Round Two! 

Half a year has passed since I asked ChatGPT about adding Auth0 authentication to an iOS app. Over that period, OpenAI’s developers added a newer model, GPT 4.0, which you can access only if you have a paid account. They also made adjustments and improvements to the original GPT 3.5 model, which powers the free version of ChatGPT.

I decided to see if the free version of ChatGPT could give me a working iOS authentication code this time. I asked it **“How do I write an iOS app that uses Auth0 for login and logout?”**

Here’s ChatGPT’s response, which I’ve condensed slightly for brevity:

1. Set up an Auth0 account.
2. Create an iOS project. Set it up with the desired UI and navigation flow for the login and logout functionality.
3. Install the Auth0 SDK. You can use CocoaPods or Swift Package Manager to install the SDK dependencies.
4. Configure your Auth0 application by providing the necessary settings, such as allowed callback URLs and logout URLs.
5. Implement login functionality: Create a login view controller or integrate the login functionality into an existing view controller. Use the Auth0 SDK to initiate the login process by presenting the Auth0 login screen. The user will be able to enter their credentials or choose a social login option.
6. Handle login callback: Once the user successfully logs in, Auth0 will redirect them back to your app. You need to implement the callback handling in your app to receive the authentication result. This typically involves handling a URL scheme or Universal Link that Auth0 uses to redirect back to your app.
7. Store and manage tokens: When the login is successful, Auth0 provides an access token and, optionally, a refresh token. You'll need to store these tokens securely, such as using the iOS Keychain, and handle token refreshing when necessary.
8. Implement logout functionality: Create a logout function that clears the stored tokens and logs out the user. You can use the Auth0 SDK to perform the logout operation.
9. Secure API requests: To secure your app's API requests, include the access token in the authorization header when making requests to your backend services. Ensure that your backend verifies the authenticity of the token with Auth0.
10. Test and refine: Thoroughly test your app's login and logout functionality to ensure it works as expected. Make any necessary refinements or enhancements based on user experience and feedback.

I then asked **“Could you show me some Swift code that uses Auth0 for login and logout?”**

Its response: “Certainly! Here's an example of Swift code that demonstrates how to use Auth0 for login and logout in an iOS app,” followed by this code:

```swift
import Auth0

class Auth0Manager {
    let auth0 = Auth0.webAuth(clientId: "YOUR_CLIENT_ID", domain: "YOUR_DOMAIN")

    func login(completion: @escaping (Error?) -> Void) {
        auth0
            .scope("openid profile")
            .audience("https://YOUR_API_IDENTIFIER")
            .start { result in
                switch result {
                case .success(let credentials):
                    // Successful login
                    let accessToken = credentials.accessToken
                    let idToken = credentials.idToken
                    // Store the tokens securely

                    completion(nil)

                case .failure(let error):
                    // Handle error
                    completion(error)
                }
            }
    }

    func logout() {
        auth0.clearSession(federated: true) { result in
            switch result {
            case .success:
                // Successful logout
                // Clear stored tokens and any other user data

            case .failure(let error):
                // Handle error
                print("Logout error: \(error)")
            }
        }
    }
}
```

My thought was probably what you’re thinking right now: _Does this code work?_

I opened a copy of the iOS project I use for demonstrating Auth0 authentication, which is based on the Auth0 iOS Quickstart app (you can [download a version configured with your Auth0 tenant settings](https://auth0.com/docs/quickstart/native/ios-swift/01-login) or [get it from this Github repository](https://github.com/auth0-samples/auth0-ios-swift-sample/tree/master/Sample-01)). I added a new file to the project, `Auth0Manager.swift`, and pasted the class that ChatGPT generated there. I replaced these placeholder values...

- `YOUR_CLIENT_ID` with my app’s client ID
- `YOUR_DOMAIN`with my tenant’s domain
- `YOUR_API_IDENTIFIER` with `https://YOUR_DOMAIN/api/v2/`, replacing `YOUR_DOMAIN` with my tenant’s domain

…and replaced my demo app’s calls to its original `login()` and `logout()` methods with calls to the versions that ChatGPT provided.

I ran the app...

...and it worked! It appears that this time, ChatGPT — and the _free_ version at that — got it right.


## A Closer Look At ChatGPT’s Code

Now that it’s clear that ChatGPT now knows how to write code to integrate Auth0 into an iOS app let’s take a look at the way it did this.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />To make this exercise a little more fun, I’ll keep a running score where I’ll award points for what I thought were good things that ChatGPT did and deduct points for things that I thought were bad ones. Watch for the picture of the gavel for these scores.


### The Auth0Manager class

This is different from a lot of [tutorial code](https://auth0.com/blog/get-started-ios-authentication-swift-uikit/), which puts the Auth0 logic and data — the`login()` and `logout()` methods as well as the variables to hold the tokens that Auth0 returns —  inside the view object that makes the call to display the Universal Login screen or log the user out. Many tutorials take this approach because it shows all the code in a single file, which is useful when you’re trying to explain something new to the reader.

In a _real_ iOS app (as opposed to a tutorial app), you’d probably take the same approach as ChatGPT’s and put the authentication and authorization code in its own class. In fact, [that’s what we do in tutorials showing how to integrate Auth0 into Android apps](https://auth0.com/blog/add-progressive-profiling-auth0-authentication-android-apps-jetpack-compose/) since they rely heavily on ViewModels that inherit from Android’s built-in `ViewModel` class.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />I’ve decided to follow ChatGPT’s example and put Auth0 code in its own class in my tutorials from now on to make my tutorial code a little closer to real-world code. For this idea, I’ll award ChatGPT 1 point.


### The WebAuth instance

ChatGPT’s `Auth0Manager` class has a single property, `auth0`, a `WebAuth` instance whose definition is as follows:

```swift
let auth0 = Auth0.webAuth(clientId: "YOUR_CLIENT_ID", domain: "YOUR_DOMAIN")
```

`Auth0.webAuth()` is a function in the _Auth0.Swift_ library that creates an instance of the `WebAuth` class, which provides the necessary methods for logging a user in and out. Both the `login()` and `logout()` methods use this instance.

ChatGPT’s solution uses the version of `Auth0.webAuth()` that takes two arguments: the client ID and the domain. It’s the most straightforward way to show how you can use Auth0 to implement login and logout in an app, but you probably wouldn’t do this in a production application since you’d be hard-coding server credentials.

Fortunately, there’s another form of `Auth0.webAuth()` that _doesn’t_ take arguments for the client ID and domain. In fact, it doesn’t take _any_ arguments, and you’d use it like this:

```swift
let auth0 = Auth0.webAuth()
```

Instead of relying on arguments that you pass to it, this form of `Auth0.webAuth()` looks through the app’s property lists (a.k.a. _plists_) for values corresponding to the following keys:

- `ClientId` for the client ID
- `Domain` for the tenant domain

You would typically create a new property list — usually named `Auth0.xml` — and store the `ClientID` and `Domain` values there. Here’s what it would look like in an Xcode project if you prefer editing property lists visually...

![auth0_plist](https://images.ctfassets.net/23aumh6u8s0i/6LexUyPkhqCzEvMCASpR37/246ed1182fd7d410cebaca9c4a6d01b0/auth0_plist.png)

...and here’s how it would look if you prefer editing property lists as source code:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Domain</key>
    <string>** Put your tenant’s domain here ***</string>
    <key>ClientId</key>
    <string>** Put your app’s client ID here ***</string>
</dict>
</plist>
```

Putting the client ID and domain values in their own file makes it easy to exclude them from version control, which makes it less likely that you’ll unintentionally share these values with people outside your organization.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />ChatGPT’s implementation works when trying to explain how to implement something, which earns it 1 point. However, its implementation isn’t one that you should use in a production application, and it should have explained this fact, so I’m deducting the point I just gave it. ChatGPT’s current score is holding at 1 point.


### The login() method

Let’s take a look at ChatGPT’s `login()` method:

```swift
func login(completion: @escaping (Error?) -> Void) {
    auth0
        .scope("openid profile")
        .audience("https://YOUR_API_IDENTIFIER")
        .start { result in
            switch result {
            case .success(let credentials):
                // Successful login
                let accessToken = credentials.accessToken
                let idToken = credentials.idToken
                // Store the tokens securely

                completion(nil)

            case .failure(let error):
                // Handle error
                completion(error)
            }
        }
}
```

Its `login()` implementation is mostly the same as the `login()` methods in our tutorials or our iOS Quickstart app. There’s the usual method chaining from the `webAuth` instance, where the methods are called in this order:

- `scope()` to request the minimum amount of scopes necessary to authenticate a user:
    -   `openid` to indicate that we want to use OpenID Connect (OIDC) to verify the user’s identity. Since Auth0 authentication is OIDC-based, Any application using Auth0 must request this scope.
    -  `profile` to retrieve the user’s name.
    -  The ChatGPT code doesn’t include a request for the `email` scope, which I would recommend, simply for access to the user’s email address, which is typically how an app would send out-of-band communications to the user.
-  `audience()` to specify one or more APIs that the access token that Auth0 returns should grant access to. In the rare case that you’re using Auth0 for authentication only, you can skip this method call. In my case, I passed it the string `https://MY_DOMAIN/api/v2/`, replacing `MY_DOMAIN` with my tenant’s domain. This is the URL for the Auth0 user management API, which is useful for accessing the user’s app and user metadata.
- `start()` to indicate what the app should do in the cases where the user was able to log in and where they weren’t.

The big difference between ChatGPT’s implementation of `login()` and the ones we’ve been using here on the Auth0 blog and in our Quickstarts can be seen in the `login()` method’s signature:

```swift
func login(completion: @escaping (Error?) -> Void)
```

ChatGPT’s version of `login()` has a parameter, `completion`, that takes an argument of type `(Error?) -> Void`. This argument is a closure that takes an argument of type `Error?` (a value whose type is `Error`, a subclass of `Error`, or `nil`) and does not return a value. The `@escaping` annotation informs Swift that the closure provided to `login()` might [outlive or go beyond `login()`’s scope](https://www.donnywals.com/what-is-escaping-in-swift/).

The `completion` parameter allows the code that calls `login()` to perform additional actions upon successful login and also in case login fails:

- If the user logged in successfully, `login()` calls `completion(nil)`.
- If the user’s attempt to log in failed, `login()` calls `completion(error)`, where `error` is the `Error` instance returned by `start()` method of the `WebAuth` instance contained in the `auth0` property.

The code calling `login()` must provide a closure argument that specifies what extra actions should happen whether the login succeeds or fails. For example, here’s the code in my demo app that calls `Auth0NManager`’s `login()` method:

```swift
auth0Manager.login() { error in
    if let error = error {
        print("Login error!")
        isAuthenticated = false
    } else {
        print("Login successful!")
        isAuthenticated = true
    }
}
```

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />I like ChatGPT’s addition of the <code>completion</code> parameter and feel no shame in stealing this idea (is it even possible to steal from an AI?). I’m granting ChatGPT 1 point, resulting in a total of 2 points so far.


### The logout() method

Here’s ChatGPT’s `logout()` method:

```swift
func logout() {
    auth0.clearSession(federated: true) { result in
        switch result {
        case .success:
            // Successful logout
            // Clear stored tokens and any other user data
            print("Logged out!")
            
        case .failure(let error):
            // Handle error
            print("Logout error: \(error)")
        }
    }
}
```

ChatGPT’s implementation of the `logout()` method is pretty much the same as the `logout()` methods in our tutorials or our iOS Quickstart app.

I would steal ChatGPT’s trick from its `login()` method and add a `completion` parameter that takes a closure that performs additional actions for both successful and unsuccessful logouts. My implementation would look something like this:

```swift
func logout(completion: @escaping (Error?) -> Void) {
    auth0.clearSession(federated: true) { result in
        switch result {
        case .success:
            // Successful logout
            // Clear stored tokens and any other user data
            completion(nil)
            
        case .failure(let error):
            // Handle error
            completion(error)
        }
    }
}
```

And here’s how I’d call the `logout()` method:

```swift
auth0Manager.logout() { error in
    if let error = error {
        print("Logout error!")
    } else {
        print("OK")
        isAuthenticated = false
    }
}
```

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />ChatGPT didn’t provide a <code>completion</code> parameter for the <code>logout()</code> method as it did for the <code>login()</code> method. I won’t award it a point, but I won’t take one away, either. At the end of this exercise, ChatGPT has 2 points. Not bad!


## Is Your Developer Job Safe?

Considering that it’s been only half a year since we last tested ChatGPT’s ability to write code that integrates Auth0 into iOS apps, this is an impressive improvement. You might be wondering what kinds of leaps it might make over the next couple of years if AIs keep advancing at the same pace, and more importantly, what this means for your career as a developer.

I don’t think of AIs like ChatGPT as a threat. Instead, I think of them as part of a long series of cognitive aids that include  [tally sticks](https://en.wikipedia.org/wiki/Tally_stick), [the abacus](https://www.ecb.torontomu.ca/~elf/abacus/intro.html), writing, [logarithmic tables](https://www.cuemath.com/algebra/log-table/), and [slide rules](https://sliderulemuseum.com/SR_Course.htm), as well as their more modern counterparts such as the combination of search engines and Stack Overflow, [code completion](https://en.wikipedia.org/wiki/Intelligent_code_completion), and [GitHub Copilot](https://github.com/features/copilot). I think that AIs can enhance what a human programmer can do and even provide ideas and inspiration that they might not think of. After all, ChatGPT’s answer provided me with a couple of ideas that I’m going to use in future code.

You might find it helpful to read this IEEE Spectrum article, [_How Coders Can Survive—and Thrive—in a ChatGPT World_](https://spectrum.ieee.org/ai-programming), which lists four ways in which developers can stay ahead of generative AIs. It captures my thinking about AI and programming in its final paragraph:

<blockquote>For programmers to survive in a generative AI world, they’ll need to embrace AI as a tool and incorporate AI into their workflow while recognizing the opportunities and limitations of these tools—and still relying on their human coding capabilities to thrive.</blockquote>

ChatGPT Tries to Add Auth0 Authentication to an iOS App, Round Two!

Logging out of an application may not be as easy as it can seem at first. Let's explore the options available in the different scenarios.

We put a lot of emphasis on the login step of an application: authentication methods, authentication factors, user identity protection, passwordless, single sign-on, etc. What about the logout step? Do you think it's so easy to implement that it doesn't deserve much attention?

Implementing logout may not be as easy as you think at first, especially in contexts where multiple actors may be involved in the login step, as it may happen in the Auth0 context.

This article will give you a high-level overview of logout issues and the different types of logouts. It will not go into the implementation details of logout, but you will get an idea of the complexity behind this apparently simple operation.

## A Few Questions about Logout

An Arabic proverb reads: "*Think of the going out before you enter*". This highlights the importance of planning well for a way out before entering any environment, physical or virtual. This also applies to logging out of applications. Understanding how to properly log out of an application has the same weight as logging in.

Before you dive into the different types of logout, ask yourself a few questions that may help you understand how to implement it for your application needs.

### What is the relationship between login and logout?

Login is the initial step in an authenticated session, which is a session that has an authenticated user associated with it. Logout is the final step of an authenticated session, that is, the last step in a session whose activities are bound to an authenticated user. Before the login and after the logout, any user activity in your application is not bound to an authenticated user but to a so-called unknown user, often called an *anonymous user*.

So, we can say that during the time between the login and the logout steps, your application knows who the logged-in user is.

### How many authenticated sessions do you have?

In the Auth0 context, when your application user logs in by using the [Universal Login page](https://auth0.com/docs/authenticate/login/auth0-universal-login), Auth0 creates a new authenticated session. Likewise, when your application receives confirmation of user authentication from Auth0, it should create another new authenticated session.

The first session tracks the interaction between the user and the Auth0 server: let's call it the *Auth0 session*. The second session tracks the interaction between the user and your application: let's call it the *Application session*. The following diagram highlights these two sessions in the context of Auth0:

![Application session and Auth0 session](https://images.ctfassets.net/23aumh6u8s0i/7GL9lhge2VPiguMql1fZba/be9b5db48db07160a24ea887471051ab/application-auth0-sessions.png)

You can use a third-party Identity provider (IdP) to authenticate your users through Auth0. For example, you can allow your users to authenticate with their favorite social media providers, such as Google, Facebook, or Twitter. In this case, a third session is created in addition to the Auth0 session and the application session: the 3rd-party IdP session. The following diagram illustrates this new scenario:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

### Why do you need to log out?

This may seem like a strange question, but think a bit about it. What is the purpose of logging out of an application? Basically, it means terminating an authenticated session. All the information associated with the session must be destroyed so that unauthorized parties can't take it over. In other words, it's a security measure. But you should not underestimate that it also has an impact on the user experience, as you will see later.

### Where do you want to log out from?

Again, this may seem like a silly question at first. Probably the most natural answer is: "*I want to log out of the application*". But as you learned earlier, there are scenarios where there are multiple authenticated sessions. Which of these sessions do you need to close? Just the application session? All sessions?

You will learn about the options in a moment.

### Why do you ask these questions?

These questions (some of which are not yet answered) should help you think about the correct way to let your users log out of your application in your specific scenario. Carefully analyze the context of your application to find the right way to let your users log out. With these questions in mind, let's see what types of logouts are available.

## Types of Logouts

I guess that it shouldn't sound weird at this point to talk about different types of logouts. Just as there are different ways to log in to your application, there are different ways to log out. Let's explore them.

### Application logout

Logging out of your application means closing your application session. How you close your application session depends on how it is implemented. For example, if your application is a [regular web application](https://auth0.com/docs/get-started/applications), you might have implemented your session using a cookie and session storage on the server side. To close the user's session, your application should invalidate the cookie and clear the session storage. Handling your application session is your responsibility.

Closing your application session doesn't close the Auth0 session. This means that the user's session with Auth0 is still alive. Technically, this means that the user's browser still has a valid authentication cookie issued by Auth0. If the user accesses the Universal Login page to authenticate while the Auth0 session is still valid, they are not even prompted for their credentials. Their authentication status is confirmed, and a new ID token is issued.

The following diagram shows the session status after application logout:

![Application logout](https://images.ctfassets.net/23aumh6u8s0i/4l8XzMQc9fJn9nKfPhhWm2/43654bd6f3da2616d3241c0f0b66caec/application-logout.png)

It is up to you to decide whether this logout type is right for your application. You know your application business scenario and the user experience you want to provide to your users.

### Auth0 logout

Suppose you don't want your user to be left with an active Auth0 session when they log out of your application. In this case, you must close both your application session and the Auth0 session.

As mentioned before, it is your responsibility to handle the logout of your application. To close the user's Auth0 session, your application must call the [Auth0 logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0). This way, the next time the user accesses the Universal Login page, they will be prompted for their credentials.

In short, when the user clicks the logout button in your application, you close your application session and then call the Auth0 logout endpoint.

> Currently, Auth0 supports two logout endpoints: the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0) and the [alternative logout endpoint](https://auth0.com/docs/api/authentication#logout).

The following diagram shows the session status after application and Auth0 logouts:

![Application and Auth0 logout](https://images.ctfassets.net/23aumh6u8s0i/2jGrD0v3xLCldzzMYX9gjb/9870f5bab211f2f47beac09a2b05b356/application-auth0-logout.png)

Check if this logout type is appropriate for your needs.

### Federated logout

Suppose that your application allows users to log in with a third-party Identity provider, such as Google, via Auth0. As you've already seen, in this scenario, you have the sessions shown in the following diagram:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

If you apply the application and Auth0 logout, the IdP session remains active.

This may be an acceptable scenario in some contexts. For example, most users use [social logins](https://marketplace.auth0.com/features/social-connections) to access multiple independent applications. If they use Google to access your application, there is a high probability that they are already authenticated with Google because they may have Gmail or some other open application that requires Google as the IdP. So, when your user logs out of your application by closing only the application session and the Auth0 session, they can still use Gmail or any other application they have logged in to through Google.

However, there are scenarios where this approach may not be appropriate. Consider the case where the third-party IdP is not a social media provider but an [enterprise IdP](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers). In these scenarios, you may want the user to log out of the IdP when they log out of your application. The [Federated logout](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps) accomplishes this goal. After logging out of the application, the authenticated sessions involved in your scenario will look like this:

![Federated logout](https://images.ctfassets.net/23aumh6u8s0i/13qgFDDmMVx2bjhQX7x4wb/2f948733cc09c9d9c9eb3c948af26b31/federated-logout.png)

> Note that not all third-party IdPs support Federated logout. Check [which ones](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps#federated-logout-support) support it.

The Federated logout introduces some user experience challenges. While logging out of your application and Auth0 is expected by the user, logging out of a third-party IdP may be something unexpected and even annoying to the user. Consider a user who uses Google to access your application, and after they log out of your application, they are unable to access their email on Gmail because their authenticated session has been terminated. As a best practice, you should make your users aware that they are logging out of their third-party IdP. For example, you can require confirmation to log out of the third-party IdP. Alternatively, you can implement the logout function so that the user can choose whether or not to log out of their third-party IdP as well.

### Global logout

The logout scenarios analyzed so far assume that there is a single application and that the user logs out of that application. What happens when multiple applications are involved in the same authenticated session? What if the user logs out of the third-party IdP instead of your application? What is the desired behavior?

The following diagram illustrates this specific scenario:

![multiple-application-auth0-3d-party-idp-sessions](https://images.ctfassets.net/23aumh6u8s0i/6ndpGiqaF3WYTo1iPCSpep/687586187b40b966e293e676fb08c423/multiple-application-auth0-3d-party-idp-sessions.png)

The diagram shows a situation where two applications (Application A and Application B) share the same authenticated sessions: the Auth0 session and a third-party IdP session.

> This scenario would be similar even without the third-party IdP. However, the inclusion of the third-party IdP makes explicit the case where the user logs out of it instead of one of the applications.

As said before, what to do when the user logs out of one of these applications or from the IdP depends on your business needs. In some scenarios, you may want to do nothing: the other applications will continue to work until the user logs out of them. In other scenarios, you may want to terminate the sessions of the other applications.

The logout that terminates the sessions of the other applications is usually called **Global logout** or **Distributed logout**. From a certain point of view, it can be seen as the counterpart of the [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on). For this reason, it is also known as **Single Logout (SLO)**, especially in the [context of SAML](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps).

Basically, when a user logs out of one of the applications sharing the same authenticated session, a logout request is sent to the other applications. The details of how this happens depend on the specific protocol (e.g., SAML, OIDC), where the initial logout happens (one of the applications or the IdP), and the type of application (regular web application, SPA). This article will not go into those details. If you are curious, take a look at these docs:

- [OpenID Connect Session Management](https://openid.net/specs/openid-connect-session-1_0.html). The OIDC specification for implementing Global logout by actively monitoring the user's current authentication status.
- [Front-Channel Logout](http://openid.net/specs/openid-connect-frontchannel-1_0.html). The OIDC specification for implementing Global logout when the browser notifies the IdP of the application session termination.

- [Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout). A high-level overview of the [OpenID Connect Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html) specification, i.e., when a regular web application communicates the termination of the application session to the IdP.

- [Best Practices for Application Session Management](https://auth0.com/blog/application-session-management-best-practices/). A blog post about the best practices for checking and terminating authenticated sessions.

Of course, the same user experience issues we mentioned for the Federated logout also apply to Global logout.

## Life after Logout

You have explored the different types of logouts you may encounter as you deal with increasingly complex scenarios. But what happens after the user logs out of your application? Since their authenticated session terminates, they are no longer authorized to access the protected pages of your application. Where will they be redirected?

This is mostly a user experience decision. You can redirect your users to the home page of your application, a specific page, or the authentication page (i.e., the Universal Login page). The choice is up to you, but there are a few points to keep in mind:

- When your logout involves Auth0 (i.e., it's not just an Application logout), you'll need to specify where to redirect the user. Learn how to do this based on the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0#redirect-users-after-logout) or the [alternative logout endpoint](https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout).
- Register the URL of the page to which users will be redirected in the *Allowed Logout URLs* field of your Auth0 Application Settings in the Auth0 dashboard. This is a security measure to prevent URL injection attacks.
- Let's say you only use the Application logout or allow users to authenticate with a third-party IdP, but you don't use the Federated logout. In these cases, be sure to redirect users to an unprotected page after they log out. Otherwise, their active authenticated session with Auth0 or the IdP will re-authenticate them, and a new application session will start. The perceived effect is that the users will not log out of your application.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Summary

In this article, you were invited to ask yourself a few questions about when you are going to implement your logout function. These questions should help you choose the right approach to define the logout for your specific scenario.

Then you explored some logout types based on different scenarios: you started with a scenario where the simple Application logout might be enough and arrived at a scenario where multiple applications are involved, and you need a Global logout.

At the end of this article, I hope you now have an idea of the complexity behind the logout step. It may look easy at first, but in scenarios where multiple applications and multiple IdPs are involved, it becomes very challenging. The alternative to this complexity would be to [discourage your users from logging out of your application](https://www.theverge.com/23670169/logout-button-ui-websites-design-ui-interface). Is that what you want? 🙂

The Not-So-Easy Art of Logging Out

React is one of the most popular JavaScript frameworks, and Spring Boot is wildly popular in the Java ecosystem. This article shows you how to use them in the same app and secure it all with Okta.

Use React and Spring Boot to Build a Simple CRUD App

andrew-hughes

Andrew is a senior web app developer with 15+ years of experience and solid expertise with React, Node, and React Native, as well as tons of SQL/NoSQL knowledge. He has performed complicated back-end API integrations for clients, including payment platforms like Stripe and PayPal along with InfusionSoft and WordPress. His extensive professional background also includes working with PHP, Laravel, Java, and Swift/iOS.

Andrew Hughes

Learn how to use Java and embedded Jetty to create a simple servlet-based web service. Then see how to do it with Spring Boot.

Get Started with Jetty, Java, and OAuth

Catherine Razeto

Catherine Razeto is a Staff Data Scientist on the Machine Learning team for Okta's Customer Identity products. She focuses on developing threat detection models to secure our customers' applications. She led the development of the machine learning engine for the Bot Detection security feature. She is interested in classification problems, anomaly detection and fraud detection at-scale.

Staff Data Scientist

The aggregated score indicates the level of bot activity seen across all CIAM customer login flows

From online retail to social media — and everything in between — bots are (one of the reasons) why we can’t have nice things. As we examine in detail in our[ State of Secure Identity Report](https://auth0.com/resources/whitepapers/2022-state-of-secure-identity-report), these digital automatons plague Identity flows at all parts of the user journey:

* Fake signups defraud registration forms and pollute customer intelligence systems;
* Brute force attacks use breached passwords in account takeover (ATO) attacks; and
* Malicious bots burden app owners with scams and spam, degrading the user experience.

Consumer-facing apps, in particular, must identify and filter out bots as part of their security and growth objectives — and since day one, Auth0 has devoted considerable effort to helping our customers do just that.

## Bot or Not?

As a vital part of the[ Attack Protection](https://auth0.com/docs/secure/attack-protection) add-on in the[ Okta Customer Identity Cloud](https://www.okta.com/customer-identity/), our[ Bot Detection](https://auth0.com/docs/secure/attack-protection/bot-detection) feature mitigates scripted attacks against native applications, passwordless flows, and custom login pages.

By correlating a variety of data sources — like past events associated with an IP address, recent login history, IP reputation data, and an assortment of other factors — we can detect when an Identity request is likely to be coming from a bot. When the Bot Detection feature detects bot or scripted login requests, it triggers a CAPTCHA step in the login flow.

Over the years, we’ve continually refined our bot detection capabilities: today’s version employs a machine learning (ML) model that ingests 60+ inputs — and when we introduced this new system last year, it[ reduced bot attacks by 79%](https://auth0.com/blog/auth0-bot-detection-reduces-bot-attacks-by-79/) above and beyond its precursor.

Importantly, the improved defensive capabilities were achieved without the expense of user friction: even during attacks, fewer than 1% of challenges are shown to legitimate human users.

## Building on Bot Detection: The Identity Threat Level (ITL)

Being at the ‘front door’ of applications with a Customer Identity and Access Management (CIAM) solution that secures billions of login transactions per month, Auth0 has a unique vantage point from which to monitor Identity threats.

This powerful perspective was the genesis of the Identity Threat Level (ITL), a score from 0 to 10 that indicates the level of bot activity targeting CIAM systems: a score of 0 means there’s practically no bot activity to speak of, while a score of 10 means almost all traffic is attributable to bots.

By aggregating (anonymously, of course!) observations across our customer base, we can calculate an ITL for different industries and geographies, with the option of introducing additional slicing and dicing on other common attributes.

Tracking historical trends and daily shifts has the potential to inform of elevated risks to CIAM login and sign-up flows, enabling app providers to increase their own monitoring, proactively tighten thresholds, implement additional defenses — or respond in any other way they see fit.


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Behind the scenes</strong><br> 
Here's a simplified overview of how an ITL is calculated.<br>
Each day, the ITL instrumentation analyzes traffic samples that cover all industries and geographies and includes customers of all sizes.
By cross-referencing the samples against our Bot Detection capabilities, we're able to determine with high accuracy what proportion of those Identity flows are associated with bots.
Finally, for each dimension or combination of dimensions (e.g., Financial Services in North America), we calculate the ITL.<br>
The ITL is based on traffic from Okta's Customer Identity Cloud customers; we believe it's reasonable to conclude that organizations that aren't customers will experience similar threats, but we cannot and do not assert that this is definitely the case.<br> 
</div>

## Sneak-Peak Observations

While future posts will explore the ITL in greater detail, including diving into Identity trends and perhaps even specific attack campaigns, in this post, we’ll stick to some high-level observations.

For example, consider the chart below, which shows the ITL for the Travel/Transportation industry, across all regions, from January 1st, 2023, through April 1st, 2023.

Just from a quick visual examination, we can see that so far in 2023, this ITL fluctuates up and down around an average of about 5.5, with the peaks corresponding to weekends (some industries exhibit this weekday/weekend pattern, and others don’t).

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/4ahrXj9vXgxuQnLrwXlU6w/b5df3271d0dee7ac8a87819a8247e38f/Battling_Bots_01.png)

Next, let’s use the ITL to see how the threat of bots varies across industries. In the chart below, we’ve zoomed out to a weekly view to more clearly showcase the general trends in Financial Services, Retail/eCommerce, and Software/SaaS/Tech.

We can see that of the three industries, Retail/eCommerce has experienced the highest peak ITL (nearly 8) and has had an average score of around 6. During the same period, Financial Services peaked at an ITL of 7 but has generally trended downward, while Software/SaaS/Tech has maintained a fairly constant ITL of around 5.5


![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/29k788paxQ9AF3bksWHWuB/da9f6822e69ea5ed48364c5ab8558561/Battling_Bots_02.png)


For our third example, let’s shift our attention to Healthcare (with a global aggregation and weekly granularity). It’s clear that around the beginning of March, bot activity targeting the Healthcare industry picked up significantly — jumping from a baseline ITL of around 3.5 to repeated peaks approaching 6.0!

Do providers of Healthcare apps know that they’re under siege — and would they configure their defenses differently if they knew?

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/Wb4zGX0ZgOOjDzlBYtD2M/1cf104b5bca618e3be5df9e2ed2aba82/Battling_Bots_03.png)

As our final example, let’s return our attention to Travel/Transportation, but this time we’ll go one level deeper and examine the ITL for three different geographies: the Americas (AMER), Asia-Pacific (APAC), and Europe, the Middle East, and Africa (EMEA).

From this breakdown, we can see that while the composite Travel/Transportation ITL tends to be in the range of 5.5 to 6.0, the threat level varies considerably by region: APAC and EMEA are largely in the 3.0 to 4.0 range, while the AMER score has remained above 7.0 for all of 2023!

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/68RTbaQaVFgqNYO5rOsmJ0/23995c6abed960115b391617a78f184d/Battling_Bots_04.png)

## Looking Ahead

Anonymous firmographic metadata can help us not only to monitor _what_ is happening but also _why_. As a result, the ITL is about more than just observing attack trends — it’s about surfacing insights and informing actions to protect both providers and users of online services.

At the same time, ITL scores equip the broader security community with data that — until now — has only been available to a handful of organizations.

Ultimately, we’ve really only begun to scratch the surface of the insights that ITL scores can provide, and we invite you to join us on this journey of discovery.

Battling Bots: Introducing the Identity Threat Level (ITL)

People are saying Ruby is dead, while others use it widely in their companies. Let's dive into the history of Ruby. From its birth to how it's doing today and to what the future holds.

[Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language%29) is an interpreted, open-source programming language with a focus on simplicity and productivity. **Ruby is already 30 years old**, and it has become one of the most used programming languages. 

Some claim Ruby is dead; others use it widely in their companies. Join me in this blog post as we learn about Ruby's history and where it stands today. 

## How It Started

[Ruby was born on Feb. 24th, 1993](https://youtu.be/gTNC26BtRFc?t=85). This was the day when [Yukihiro Matsumoto](https://en.wikipedia.org/wiki/Yukihiro_Matsumoto), also known as **Matz** and creator of Ruby, decided along with his colleague Keiju Ishitsuka what the name of the language was going to be during a chat conversation: 

```plain-text
matz> Let us decide the codename now
matz> tentative one.
keiju> Ok.  
matz> What is your best up to now?
keiju> I'm content with coral.  
matz> I thought ruby is cool as a codename, isn't it
keiju> Well. Ruby is also good.  
matz> But, coral is also good
matz> arrr
```
<center>*[Extract from the chat between Matz and Keiju back in Feb 1993](https://blade.ruby-lang.org/ruby-talk/88819)*</center>
<br/><br/>

They knew they wanted to name the programming language after jewels, so they were considering *Ruby* and *Coral*. As Matz explains in his talk [Ruby After 25 Years](https://youtu.be/gTNC26BtRFc?t=286), Coral was longer by one character making it more annoying to write multiple times. *Ruby was shorter and more beautiful*.

Matz created Ruby because he wanted a simple object-oriented, easy-to-use scripting language. He added the features he loved the most, such as iterators, exception handling, and garbage collection. 

Ruby is a clean, simple, and powerful object-oriented programming language. There are no curly braces; scopes are clearly defined by blocks, and overall makes you happy to use it. This was, in fact, one of Matz's goals when creating the language:

> "I hope to see Ruby help every programmer in the world to be productive, enjoy programming, and be happy. That is the primary purpose of Ruby language."
&mdash; <cite>[Matz on Ruby 1.9, Google TechTalks 2008](https://youtu.be/oEkJvvGEtB4?t=1795)</cite>

I mean, look at this thing: 

```ruby
class Numeric
  def plus(x)
    self.+(x)
  end
end

y = 5.plus 6
# y is now equal to 11
```

I can't imagine a more beautiful thing 🤩. 

This code creates a new class, `Numeric`, with a `plus` method. Because everything is an object in Ruby, you can call this method with anything, even a number! We do this in the example `y = 5.plus 6`. The `Numeric` class is just a small example of what Ruby can do, but I'm sure it gives you an idea of its power.  

But Ruby has come a long way from the first version to the current one. After naming the language in 1993, `ruby-0.95` was released to the Japanese domestic newsgroups on Dec. 21st, 1995. In 1996 `ruby-1.0` was released, and in July 1997, Matz announced that **he had been hired by [netlab.jp](https://www.netlab.jp/), a Japanese open source company, to be a full-time Ruby developer**. This only helped accelerate the implementation of Ruby, so on Aug. 13th, `ruby-1.1` was released, and on Sept. 22nd, 1997, the first article about Ruby was published. I did my best to find it, but it is not available anymore 😭.

The popularity of Ruby was growing every day in Japan, and as more and more developers started to use Ruby, the first Ruby books were published to support the community's continued learning. The first was "The Object-Oriented Scripting Language Ruby" by Matz himself.

![The Object-oriented Scripting Language Ruby 1999 edition book cover](https://images.ctfassets.net/23aumh6u8s0i/5qtUsDS2rpmpR3AIZABxgc/f06c643901227a3a2fb449223415aba9/amazon-ruby-book.jpg)


In 2000 [Ruby was more popular than Python in Japan](http://ruby-doc.com/docs/ProgrammingRuby/html/foreword.html), and the acceptance and growth of the language were starting. In 2004, a new server-side web application framework was born: [Ruby on Rails](https://rubyonrails.org/). The launch of Rails, together with the fact that [Apple announced that it would ship Ruby on Rails with Mac OS X v10.5 "Leopard"](https://rubyonrails.org/2006/8/7/ruby-on-rails-will-ship-with-os-x-10-5-leopard) helped Ruby to become the [Language of the Year in 2006](https://www.tiobe.com/tiobe-index/ruby/) and to be used mainly for web development. 

Fast-forward to 2016, Ruby reaches the highest position (since 2001) in the TIOBE index at number 8, and its usage is peaking. Between 2013 and 2020, we went from `ruby2.0.0` to `ruby3.0.0`, and the community and the language were more and more mature. 

But where is Ruby now? 

## How It's Going 

Ruby is at version [`ruby3.2.1`](https://github.com/ruby/ruby/releases/tag/v3_2_1) as of the date of publishing this article, and by the end of 2022, there were [2.4 million Ruby developers](https://www.slashdata.co/free-resources/state-of-the-developer-nation-23rd-edition?) out there.

At the beginning of this article, I mentioned that some people say Ruby is dying, and I'm afraid I have to disagree with this statement. Ruby, as technology, still creates value nowadays, which is essential to remember. When technology creates value, it also creates jobs, opportunities, and money. 


Now let me tell you why Ruby is still creating value:

### Ruby lives to its purpose: *programmer happiness*

You can take it from me, or you can take it from [other people in the industry.](https://jetrockets.com/blog/is-ruby-still-alive-in-2023) The reality is programming in Ruby is truly joyful, and if you still need to do it, I highly recommend you try it. 

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>We have created step-by-step guides to help you integrate Auth0 with your Ruby on Rails application. Check out the 
<a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication">Rails Authentication By Example</a> and the <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization">Rails Authorization By Example</a> guide, which also covers the concept of <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization#set-up-role-based-access-control-rbac">Role-Based Access Control (RBAC)</a> and let yourself fall in love with Ruby😍.</strong>
</div>

### Ruby is widely used in big companies 🧑‍💻

[Ruby is widely used in the tech industry](https://toprubycompanies.info/) by some of the biggest companies like Airbnb, Shopify, Coinbase, and Gitlab. Some are significant contributors to Ruby's source code and Ruby on Rails. 

### Ruby makes money 🤑

In 2022, Ruby and Ruby on Rails are still listed as [the top-paying technologies](https://survey.stackoverflow.co/2022/#top-paying-technologies) for developers, with a median yearly salary of about $90,000. 

Also, because big publicly-traded companies are using Ruby, [the total market cap of only 46 (!) of them is currently at about $284 Billion.](https://toprubycompanies.info/)

### Ruby has a great community

The [Ruby community](https://www.ruby-lang.org/en/community/) is highly active, and many projects contribute to it. One of them is the [Rails Foundation](https://rubyonrails.org/foundation) which aims to improve the documentation, education, marketing, and events to benefit all new and existing Rails developers. 

Also, Ruby is open source, and everyone can contribute to its development; this also means it can quickly evolve to fit developers' needs in the future. 

## What’s Next?

[Ruby 3.0](https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/) was released in 2020 with many improvements and new features, so the plan to keep improvement remains. 

Some of the improvements, ambitions, and features that Ruby will be working on are the following: 

- **Ruby 3x3**: 
  - It started as "Make Ruby 3.0 run 3 times faster than Ruby 2.0", but it [has been revisited in 2021](https://youtu.be/Dp12a3KGNFw?t=2757) and changed to *"Ruby 3.x will be 3 times faster than Ruby 3.0 "* so we will see more and more performance improvements!
- **Performance**: 
  - Ruby 3.2 adds a lot of performance improvements, such as re-implementing the [MJIT](https://www.rubyguides.com/2018/11/ruby-mjit/) compiler in Ruby and executing it under a forked process instead of using a native thread. 
  - [YJIT](https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md) is now production-ready, and there will be more performance improvements coming as shown by [Alan Wu in RubyKiagi 2022](https://youtu.be/EMchdR9C8XM?t=1910).
- **Concurrency / Parallelism**:
  - Ruby 3.0 introduced [Ractors](https://ruby-doc.org/core-3.0.0/Ractor.html), an [actor-model abstraction](https://en.wikipedia.org/wiki/Actor_model) that provides a parallel execution feature without thread-safety concerns. Ractors have improved since they were first released and will continue their development to ensure Ruby is more *thread-safe* than ever. 
- **Static Analysis with [RBS](https://github.com/ruby/rbs) and [Typeprof](https://github.com/ruby/typeprof)**: both of these tools were released with Ruby 3.0 are still being improved in new versions. 
  - RBS allows you to add type annotations to your Ruby code in files with a new extension called `.rbs`.
  - Typeprof is a type analysis tool that reads plain (non-type-annotated) Ruby code, analyzes what methods are defined and how they are used and generates a prototype of type signature in RBS format.

## Conclusion 

Ruby is an object-oriented and interpreted programming language created by Yukihiro Matsumoto in 1993. Ruby was quickly adopted in Japan and then expanded to the rest of the world; it gained popularity when the Ruby on Rails framework was released. Ruby has peaked in popularity over the years and remained relatively stable. 

Ruby is still widely used in big companies like Shopify, AirBnb, and Github, which also contribute to the source code and investment and language development. 

Programming languages' popularity and the features that developers seek come and go. A few years ago, developers didn't want to deal with static typing; now, they do, for example. It is hard to predict whether Ruby will become extremely popular, but surely Ruby is still alive, and it will live as long it continues to create value for the community and companies but also while it makes developers happy. 

A Brief History of Ruby

Broken Object Level Authorization is the most critical API security vulnerability. Learn how Fine Grained Authorization (FGA) can help fix it.

According to [OWASP](https://owasp.org/), the worldwide web security community, Broken Object Level Authorization (BOLA) is the most critical vulnerability affecting APIs. What is this vulnerability? How can it be exploited? How can you prevent it in your API? Keep reading to find the answers to these questions.

## What Is OWASP API Security Top Ten?

One of the main goals of the OWASP community is to make developers and technologists aware of the risks their applications and systems are exposed to. With this in mind, the community publishes some documents that highlight what are the most common security risks.

The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) document is the most popular one. It focuses on web development in general. But there is also a more specific document for APIs: the [API Security Top Ten](https://owasp.org/www-project-api-security/).

Both the 2019 and the [2023](https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc.html) versions of the document report that [Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/2023/en/src/0xa1-broken-object-level-authorization.md) is the most critical security risk. It's incredible that after four years this security risk is still affecting APIs around the world! Is there a way to mitigate if not eliminate this vulnerability?

The answer to this question is positive: you can prevent  this vulnerability from affecting your API by designing a proper authorization system. But before you get to the solution, let's learn what Broken Object Level Authorization is.

## What Is Broken Object Level Authorization?

Authorization is the process of determining what a user has access to. This access control can be done in many different ways based on the business rules of the specific application.

In the API context, each request to a protected endpoint should be analyzed to determine if the client is authorized to access and perform the requested action. Typically, this check is done at the code level and is based on verifying that the client has the right permissions to access the resource (the object) exposed by the API endpoint.

The main problem in this case is to define what is the actual resource to protect.

In some scenarios, it's the API endpoint itself. Consider the `/profile` endpoint: it implicitly returns the profile data of the current user. The API may know who the current user is from the session storage or from the access token sent along with the request.

In other scenarios, the object to protect is the requested resource. Consider the endpoint `profile/42`, which returns the profile data of the user with ID 42. In this case, comparing the current user ID to the requested user ID may not be correct. Think of an administrator who should have access to the profile data of all the users. The authorization check should verify that the current user has permission to access the requested object.

Inaccurate permission checking in endpoints that use object IDs exposes the API to BOLA attacks. In fact, an attacker could manipulate the object ID to gain access to an object for which they have no permissions.

> In the past, the Broken Object Level Authorization (BOLA) vulnerability was called Insecure Direct Object Reference (IDOR). The name was changed because it suggested that the problem was with the ID, while in fact it's with the authorization check.

## An Example of BOLA Vulnerability

To understand how a Broken Object Level Authorization vulnerability can be exploited by an attacker, let's use a practical example.

Suppose your bank provides you with an app to manage your account. Being a curious developer, you take a look at how your app interacts with the server. You notice that it calls the endpoint `https://thebankwebsite.com/accounts/9876543` to get data about your own account whose number is 9876543.

You remember that one of your friends has the same bank as you. You also remember that you made a money transfer to him in the past, so you look for his account number in the messages he has sent you. You find out that his account number is 1029387. So, you take curl or another HTTP client and replay your HTTP request to the bank's server by changing the endpoint's URL: `https://thebankwebsite.com/accounts/1029387`.

Surprisingly, you get the data about your friend's account from the server! This means that the bank's API has a BOLA vulnerability. Their authorization check fails at the object access level.

You can imagine, for example, that the API implementation for that particular endpoint is as follows:

```javascript
const express = require('express');
const app = express();
const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');

//This checks that the provided access token is valid
const validateAccessToken = auth({
  audience: '...yourApiIdentifier...',
  issuerBaseURL: `https://...yourDomain.../`,
});

//This checks that the provided access token grants reading permissions
const checkReadPermissions = requiredScopes('read:account');

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          res.json(getAccountData(req.params.accountNumber));
        }
);
```

This Node.js Express code snippet shows how a GET request on the `/accounts/:accountNumber` endpoint is handled. Note that the endpoint is protected by two middleware:

- `validateAccessToken`, which ensures that the client provides a valid access token.
- `checkReadPermissions`, which ensures that the access token contains the required `read:account` scope in order to allow the client to access the requested account.

Unfortunately, these checks are not sufficient to implement an accurate access to the account object. In fact, they will not prevent you from accessing your friend's account.

<include src="ebook-ads/WebSecurity" />

## How to Prevent BOLA Vulnerabilities

What measures can you take to prevent BOLA vulnerabilities?

A common suggestion is to avoid using easily recognizable object identifiers in your endpoint URL, such as the bank account number in the example above. This measure prevents the knowledge of the object ID from allowing an attacker to compose a specific HTTP request. For example, you could use a GUID in the URL to identify the bank account instead of the bank account number itself. GUIDs are randomly generated values and make them very difficult to guess.

This approach can mitigate the risk of BOLA attacks, but it doesn't solve the problem. If the attacker finds a way to determine the GUID associated with a bank account, this protection will be bypassed.

The real problem is not in the object ID but in the authorization mechanism. The access control of your API should not be limited to controlling access to the endpoint. It should verify that only authorized users can access **the object exposed by the endpoint**.

In the bank account example, this means that additional checks should be performed. For example, you can check that the current user is the owner of the account, as outlined below:

```javascript
// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          if (account.userId == userId) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

This would solve the unauthorized access to the bank account described earlier. However, it might not cover other scenarios. For example, consider a bank account with multiple owners. Each owner could have different permissions on the account. Also consider a bank employee: they should be able to access the accounts of their branch customers. And perhaps a regional manager should be able to access the accounts of multiple branches.

As you can see, the authorization policy that your API should implement strictly depends on the specific business logic. This logic is mainly determined by the relationship between users and resources. When this relationship becomes complex, your API code run the risk of getting messed up.

## What Is Fine-Grained Authorization?

To handle complex authorization policies, you should use Fine Grained Authorization (FGA). FGA allows you to control access to resources by analyzing a context described by various attributes and relationships. By having access to a detailed context, you can more effectively control who can access what in your system.

You can design and implement FGA in a variety of ways, but the most common models are as follows:

- **Attribute-Based Access Control (ABAC)**. This authorization model allows you to make authorization decisions by evaluating attributes such as the user's role or age, the resource type or size or status, the action requested, the current date and time, and so on.
- **Policy-Based Access Control (PBAC)**. This authorization model allows you to make authorization decisions based on policies. It is very similar to ABAC. The main difference is that PBAC focuses more on logic while ABAC relies more on data.
- **Relationship-Based Access Control (ReBAC)**. This authorization model focuses on the relationship between users and resources. This also includes relationships between resources. ReBAC provides a more expressive and powerful authorization model that can describe very complex contexts.

Okta offers [Fine Grained Authorization](https://fga.dev) through two solutions based on the ReBAC model:

- [Auth0 FGA](https://dashboard.fga.dev/). This is an *authorization service* that centralizes your authorization logic and data. It allows you to define your authorization model, store your authorization data, and make your authorization decisions across all your applications. Read the [Auth0 FGA documentation](https://docs.fga.dev/intro/authorization-and-auth0-fga) to learn more.
- [OpenFGA](https://github.com/openfga). This is the Open Source project powering the Auth0 FGA service. You can install the [OpenFGA Server](https://github.com/openfga/openfga) and use its SDKs to integrate authorization into your applications.

## How FGA Solves BOLA Vulnerabilities

Auth0 FGA and OpenFGA allow you to fix Broken Object Level Authorization vulnerabilities in your APIs without messing up your code. Whether you use the hosted product or install the Open Source engine on your servers, FGA allows you to centralize the access control to the resources protected by your API.

You can do this in three steps:

1. **Define your authorization model**. In this step, you define the types of objects in your system and their possible relationships with each other. The authorization model is usually fairly static once written. Check out [this document to learn more about defining your authorization model](https://docs.fga.dev/modeling).
2. **Store your authorization data**. This step allows you to define the actual data and its relationships according to the authorization model you defined in the previous step. This represents the state of the system and will be changing as users interact with your application.
3. **Add authorization check to your API**. In the third step, you integrate authorization checks into your API and start leveraging the power of FGA.

### Define your authorization model

Going back to the bank account example, you can define your authorization model in Auth0 FGA by using its [configuration language](https://docs.fga.dev/modeling/configuration-language). The following code shows a minimal example of how your model could be written:

```yaml
model
  schema 1.1
type user
type branch
  relations
    define employee: [user]
type account
  relations
    define branch: [branch]
    define owner: [user]
    define can_create: employee from branch
    define can_view: owner or employee from branch
```

Notice that the last line in the model above defines the account owner and the employees of the branch where the account was opened as the legitimate viewers. This is the basis for avoiding the Broken Object Level Authorization problem.

Using the [Auth0 FGA Playground](https://play.fga.dev/), you can also get a visual representation of this model:

![The bank authorization model in the Auth0 FGA Playground](https://images.ctfassets.net/23aumh6u8s0i/3cklRF8G4IPBGWb07P4JsI/a75e9daf57459430a9c40f620aad7792/auth0-fga-bank-authorization-model.png)

> You can play with the model used in this article by [making your own copy](https://play.fga.dev/stores/create/?id=01GVMW810J23DEBPGT22MFE4M7).

### Store your authorization data

As the next step, you fill this model with actual data. You define your users and add a direct relationship to the objects in your model. You also define relationships between objects and other aspects that depend on your specific model. You provide data to the system using tuples. For example, the following tuples define some relationships related to the bank model presented earlier:

```json
[
  // User Mary is the owner of the account 12345
  {
    "user": "user:mary",
    "relation": "owner",
    "object": "account:12345"
  },
  // User John is an employee of the branch b1
  {
    "user": "user:john",
    "relation": "employee",
    "object": "branch:b1"
  },
  // Account 12345 was created in the branch b1
  {
    "user": "branch:b1",
    "relation": "branch",
    "object": "account:12345"
  }
]
```

To learn how [to populate your authorization model with data, read this document](https://docs.fga.dev/writing-data).

### Add authorization check to your API

Finally, you can add the authorization checks to your API using one of the [available SDKs](https://docs.fga.dev/integration/install-sdk). Referring back to the bank example, the Node.js Express code will perform its authorization checks as follows:

```javascript
const { OpenFgaApi } = require('@openfga/sdk');
const fgaClient = new OpenFgaApi({
  //...configuration...
});

// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          const { allowed } = await fgaClient.check({
            tuple_key: {
              user: `user:${userId}`,
              relation: 'can_view',
              object: `account:${req.params.accountNumber}`,
            },
          });
  
          if (allowed) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

The authorization check is performed by `fgaClient.check()`, which passes the tuple to be verified to the FGA engine. The FGA engine uses the authorization model and the data you provided to determine if the current user is authorized to view the requested account. Since you have defined there who the legitimate viewers of this account are, your API is not BOLA vulnerable. In addition, your code is kept clean.

Read more about [integrating FGA into your API](https://docs.fga.dev/integration).

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Summary

By the end of this article, you should have a clearer idea of what Broken Access Level Authorization is and how Fine Grained Authorization can help prevent it.

You have begun to explore what BOLA is and how it can be exploited with a practical example. You have seen that the root cause of this vulnerability is an inadequate authorization system. You learned about FGA and saw what Auth0 offers in this area.

Using the API example analyzed earlier, you learned how to integrate it with Auth0 FGA to overcome the BOLA vulnerability in three steps: define an authorization model, populate the model with data, and invoke the authorization check from the API.

In addition to avoiding BOLA vulnerabilities, Auth0 FGA provides a powerful authorization system to solve very complex scenarios effectively and efficiently. [Give it a try](https://fga.dev/).


How Fine Grained Authorization Solves the Most Critical API Security Risk

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps

[Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/definitive-guide-to-single-sign-on) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how **SSO authentication** is implemented for the web. Read on!

<AmpContent>
<amp-youtube
    data-videoid="Vp6kx4Sd_E0"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vp6kx4Sd_E0' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Federated Identity Glossary

The concept of a centralized or linked electronic identity is known as *federated identity*. Federated identity systems handle several concerns:

- Authentication
- Authorization
- User attributes exchange
- User management

The **authentication** aspect deals with validating user credentials and establishing the identity of the user.

**Authorization** is related to access restrictions (e.g., is the user allowed to access X resource?). 

The **attributes exchange** aspect deals with data sharing across different user management systems. For instance, fields such as *"real name"* may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. 

Lastly, **user management** is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the **authentication** part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

![What is single sign-on separator 1](https://images.ctfassets.net/23aumh6u8s0i/2xIzg7UIbBpGNvCeRsdn4k/32f29b73fc2b4bd33bac6fe124d9bfb1/what-is-sso-1)

## Single Sign-On (SSO) Authentication

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are **already logged-in** at domain X to be already logged-in at domain Y. This is what SSO is all about.

![Non-Single-Sign-On Scenario](https://images.ctfassets.net/23aumh6u8s0i/4pa532TumNn6TI3gQmMWEw/0a6182b447b75b24bea1b763c1ba73a1/non-sso-scenario)

The obvious solution to this problem is to **share session information** across different domains. However, for security reasons, browsers enforce a policy known as the [*same origin policy*](https://en.wikipedia.org/wiki/Same-origin_policy). This policy dictates that cookies (and other locally stored data) can **only be accessed by its creator** (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

![No cookie sharing](https://images.ctfassets.net/23aumh6u8s0i/2WJQLWBpByFyth3ufF3Af0/5f341d8816d77f20dc05c5a2f31ec89f/same-origin-policy-forbids-this)

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a **central domain**, through which authentication is performed, and then the **session is shared** with other domains in some way. 

For instance, the central domain may generate a signed [JSON Web Token (JWT)](https://auth0.com/docs/jwt), which may be encrypted using [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

![SSO - Central authentication domain](https://images.ctfassets.net/23aumh6u8s0i/2GrAhJRypY1XQx3TIDbqzO/ecbd47c21f1e1c1fd334a239b9015a08/using-central-auth-domain)

Whenever users go to a domain that requires authentication, they are **redirected** to the authentication domain. As users are **already logged-in** at that domain, they can be immediately redirected to the original domain with the necessary authentication token.

![Single Sign-On Authentication](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)


## SSO Authentication with Auth0

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, [SAML](https://auth0.com/docs/protocols/saml) is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

You can go and check our [docs on Single Sign-On](https://auth0.com/docs/sso/single-sign-on) and the [Auth0 SSO samples](https://github.com/auth0/auth0-sso-sample).

If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:

![SSO with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5n5APnJDhCtUiyZvyAG6rK/5a9faf400e436dd131bdee21b81c8761/auth0)

In this case, **Auth0 is the [Authentication Server](https://auth0.com/blog/what-is-an-authentication-server/)** and it works as a *bridge* between different SSO frameworks. 

<include src="ebook-ads/SsoGuide" />

## Conclusion

Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as [OpenID Connect](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog) and services such as the one we provide at Auth0 make [integrating Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

![What is single sign-on separator 3](https://images.ctfassets.net/23aumh6u8s0i/5L0CZk6C2On5CTXSHlE3MF/50e145cd648e88dd800f90ca19cfa1e4/what-is-sso-3)

What Is Single Sign-On Authentication (SSO) And How Does It Work?

Learn how to implement a Sinatra API and protect its endpoints using Auth0

Add Authorization to a Sinatra API using Auth0

arthur-bellore

I’m a tech content creator. I enjoy breaking up seemingly complicated topics into easy-to-understand pieces for people to read. When I’m not in front of a computer, you’ll usually find me reading books.

Cybersec Writer

Arthur Bellore

Transport Layer Security (TLS) is the cryptographic protocol behind pretty much any computer network used today: from web browsing to email, APIs, and VoIP. But how exactly does it work?

## SSL vs. TLS

SSL, or Secure Sockets Layer, is the predecessor to TLS. It was a cryptographic protocol developed by Netscape in 1994, but since it had serious flaws, it was never released to the public. SSL 2.0 was released publicly one year later, in 1995, but it, too, was found to have serious flaws. Finally, SSL 3.0 was rebuilt from the ground up and released in 1996.

Microsoft, who had its own version of the protocol, and Netscape agreed to hand over the project to the Internet Engineering Task Force (IETF) and make it an open standard. As part of the deal, the name was changed to TLS, Transport Layer Security, to signify that it no longer had ties with Netscape.

The first upgrade to SSL 3.0 was published in 1999 in [RFC 2246](https://datatracker.ietf.org/doc/html/rfc2246) as TLS 1.0. Tim Dierks, the editor of RFC 2246, has said [in his blog](https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html) that TLS 1.0 was really SSL 3.1, but they changed the name “so it wouldn’t look the IETF was just rubberstamping Netscape’s protocol.” Indeed, if you look at RFC 2246, it says:

This document describes TLS Version 1.0, which uses version { 3, 1 }. Version value 3.1 is historical: TLS version 1.0 is a minor modification to the SSL 3.0 protocol, which bears the version value 3.0.

TLS became the standard of encryption and authentication over computer networks, and it’s still being used today. The most recent version of the protocol is TLS 1.3, which was released in August 2018.

### What is the difference between SSL and TLS?

SSL hasn’t been updated since its release in 1996, and it was deprecated in 2015 in [RFC 7568](https://datatracker.ietf.org/doc/html/rfc7568). Most [modern browsers disable it by default](https://en.wikipedia.org/wiki/Version_history_for_TLS/SSL_support_in_web_browsers) or don’t support it outright anymore.

Despite this, because of the association between the two, many people still use the term SSL when they really mean to say TLS. Vendors typically use the same terms their target customers use to facilitate messaging, so their marketing collateral generally contains terms such as “SSL/TLS” or “SSL,” even though SSL is deprecated.

We now know that SSL and TLS are different things, but for the remainder of this article, SSL will be used interchangeably with TLS to match its everyday usage.

## Why SSL/TLS Was Created

For two computers to communicate with each other, they must perform a set of agreed-upon operations in a specific order. A **protocol** is what dictates those operations. The HTTP protocol is the protocol that web servers and clients use to establish a connection and communicate with each other through the Internet.

It works roughly as follows:

1. The server listens for new connections on port 80
2. The client connects to the server, and this starts a chain of operations as set forth by the HTTP protocol
3. The client sends a GET request to the server; the server receives the request, processes it, then sends back a response: headers and index.html, plus other content it might need to serve (CSS files, JavaScript files, cookies, etc.) for the client to render the content correctly.

This works to distribute content between two remote computers, but there is a problem: HTTP was intended to expand the local knowledge management tools throughout the multiple computers at CERN in the late 1980s, so it was designed as a clear text protocol.

Because it’s clear text, a malicious actor could insert themselves between client and server and potentially read sensitive information, such as credit card numbers or passwords, or they could intercept the client’s requests and serve back malicious files pretending to be server.

As the Internet evolved and the number of sensitive information flying around increased exponentially, an encryption layer sitting below HTTP was necessary. However, this is a bit tricky: if a bad actor can “listen in” the conversation between client and server while the connection is unencrypted, how can they exchange encryption keys securely?

One option would be for the two parties to create a public-private key pair and send over the public key pair to the other party, so they can use that to encrypt their packet before sending them over the wire.

The problem with this is that asymmetric (public-key) cryptography is _much slower_ than symmetric cryptography.

The "strength" of asymmetrical cryptography relies on modular arithmetic, mathematical operations that are very hard to do in the opposite direction. The numbers used in these operations need to be big enough to provide the necessary security, but performing arithmetic with very large numbers can be taxing on a CPU.

Symmetric cryptography, on the other hand, works differently and does not suffer from this problem. On top of that, most devices have AES instruction sets integrated into their CPUs to speed up AES operations, making AES encryption have almost zero overhead on modern devices.

The TLS protocol gets around this issue by using asymmetric cryptography to exchange keys at the beginning and then switch to symmetric keys (“sessions keys”) from then on in a process known as the TLS handshake.


## TLS handshakes

The exact steps of the TLS handshake will depend on which TLS version is supported by the client and server, as well as which parameters they are set to use.

Since most modern browsers still support TLS 1.2 and a lot of websites still use TLS 1.2 (according to a [paper published by Syed-Winkler](https://www.grin.com/document/1037281), as of February 2021, TLS 1.3 is supported by 42.9% of surveyed websites, while TLS 1.2 is supported by 99.3%), we will talk about TLS 1.2 first and then discuss how TLS 1.3 differs from 1.2.


### The TLS 1.2 handshake

TLS 1.2 can be configured to use many key exchange algorithms, and among them, the most well-known and widely used is the RSA key exchange algorithm. Let’s go over how the RSA algorithm works in TLS 1.2, then talk about how the process differs in TLS 1.3 with the [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) (DH) key exchange algorithm.

The RSA key exchange works roughly as follows in TLS 1.2:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** This message contains the TLS versions and cipher suites the client supports and a 32-byte random number known as Client Random.
3. **Server says “hello” back with a ServerHello message.** The server selects a cipher and the TLS version from the list provided by the client, then generates a different 32-byte random number known as Server Random and sends it all back along with the server’s own SSL certificate.
4. **Client uses the SSL certificate to verify the server’s identity.** SSL certificates contain a public key generated by the server and a digital signature signed with the private key of a trusted third party known as a certificate authority (CA). Most web browsers and operating systems come bundled with public keys from trusted CAs, which are used to verify that the CA issued the certificate.
5. **The client verifies the server has the matching private key to the certificate through ClientKeyExchange.** The client generates the pre-master secret (a 48-byte random number) and encrypts it with the server’s public key obtained from the certificate. If the server is the true owner of the certificate, it must be able to decrypt the message and obtain the original pre-master secret.
6. **Server decrypts the pre-master secret.** Now both the server and client have the pre-master secret, the Server Random, and the Client Random. They can use that to derive the master secret using the previously agreed cipher and arrive at the same (symmetric) key, which will become the session key once both parties verify their keys match.
7. **Client sends a ChangeCipherSpec message.** This indicates that the client is ready to create the session key and start communicating through an encrypted tunnel using that key.
8. **Client proves to server it has the correct keys.** The client hashes all handshake records up to that point, encrypts them with the session key, and sends them to the server. If the server generates the correct key, it will be able to decrypt that message and verify the record hashes (which the server can independently generate).
9. **Server proves to the client that it has the correct keys.** The server does the same thing and sends it to the client.
10. **A secure connection is established.** If both keys match, the TLS handshake is complete.

<br>
#### Problems with TLS 1.2

TLS 1.2 left a lot of its configuration parameters up to the users, which often resulted in bad choices (the old security adage of “among too many options, the worst one will be chosen”).

Additionally, in the name of backward compatibility, TLS 1.2 also allowed old, insecure ciphers to be used. (TLS 1.2 itself was released in 2008.) As time passed, it became more prone to attacks as vulnerabilities in older cipher or versions of TLS were discovered.

On top of all that, the RSA key exchange has a few weaknesses:

* **The same public-private key pair is used both to authenticate the server and to encrypt the pre-master secret (item #5 above).** If an attacker obtains the private key, they will be able to re-generate the session keys and be to decrypt the entire session.
* **There is no Perfect Forward Secrecy (PFS).** Since the server’s private key doesn’t change, an attacker might record and store encrypted data for years, hoping to decrypt it years down the line if the server’s private key is ever leaked or compromised.
* **Performance.** It’s necessary to make two round trips between the client and server until the session key is established.

To address these problems, the IETF began developing TLS 1.3 in 2013 and finally released it to the public in August 2018.

### What changed in TLS 1.3

In practice, the main differences between TLS 1.3 and 1.2 are:

* Shorter handshake
* Only supports key exchange algorithms with perfect forward secrecy (PFS), such as ephemeral Diffie-Hellman
* Support for 0-RTT (Zero Round Trip Time) resumption

This represents a bit of a paradigm change in TLS 1.3: shifting the focus from user configurability and backward compatibility to security by being more opinionated.

This allowed the designers to create a shorter handshake (by restraining DH as the only key exchange algorithm) but also prevented developers from choosing insecure options by restricting the number of options available in the first place.

For example, while it was technically possible to use DH as the key exchange method in TLS 1.2, the participants were responsible for setting the DH parameters. Picking the right parameters is crucial to make sure the DH exchange is secure, as some parameters can be trivially broken.

In 2015, security researchers [published a paper](https://weakdh.org/) describing how the WeakDH attack, which affected 8.4% of the top 1 million domains at the time, could trick servers into using small (insecure) DH parameters, enabling adversaries to decrypt data transmitted between client and server.

TLS 1.3 makes it impossible to use anything but a set of DH parameters that are believed to be secure.

### The TLS 1.3 handshake

Because there are significantly fewer options for the client and server to agree on, the TLS 1.3 handshake is much simpler:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** Since the list of cipher suites was vastly reduced in TLS 1.3 (from 37 to 5), the client assumes the server is going to use one of the five. It proactively calculates a key pair for each of the cipher suites and sends it to the server along with the protocol version.
3. **Server calculates the key session.** With the client’s key share, the server is able to generate the session key.
4. **Server says “hello” back with a ServerHello message.** The server generates its own key share and sends it over to the client, so it also can generate the session key, along with the server’s encrypted SSL certificate (using the session key created on #3).
5. **Client generates master secret and a secure connection is established.** The client receives the server’s key share and calculates the session key. It decrypts and verifies the server’s certificates, and if everything is good, the handshake is complete.

Note that there are two different public-private key pairs on an ephemeral DH exchange: the first is the ephemeral pair, created every time client and server establish a connection, which guarantees forward secrecy. The second pair, embedded on the SSL certificate, is used for authentication and doesn’t change.

Given that a new key is generated for every session, this feature guarantees PFS. If the encryption keys are compromised at a later date, the leaked key will only be able to decrypt the specific session to which it corresponds; all the prior sessions are still safe. As a result, large-scale storage of data transmitted between server and client is rendered worthless.

## How Auth0 Can Help

The temptation to intercept, undermine, and circumvent encryption has never been stronger. Cybercriminals are working to find ways to get around the issues that strong encryption presents due to the volume of valuable information that is sent between computers today.

While this rarely results in direct assaults against cryptographic algorithms or protocols, it frequently prompts attackers to devise novel methods of intercepting or capturing information. With these threats ever present, it is more crucial than ever to focus on maintaining strong and up-to-date implementations of effective encryption protocols.

Some applications are still running TLS versions older than 1.2, and others are still running the original SSL protocol. If yours is one of them, you should consider upgrading it immediately. Auth0 [supports both TLS 1.2 and TLS 1.3](https://auth0.com/docs/customize/custom-domains/self-managed-certificates/tls-ssl) and can help you keep your applications secure.

"IT"