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

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

Learn how Auth0 Token Vault uses OAuth 2.0 Token Exchange to provide secure, delegated access, letting AI agents act on a user's behalf without handling refresh tokens.

Auth0 Token Vault: Secure Token Exchange for AI Agents

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)

Dive deep into the common myths surrounding JSON Web Tokens (JWTs), from their security to their role as access tokens, and why they aren't a one-size-fits-all solution for session management.

JSON Web Tokens, or JWTs, are a cornerstone of modern application security and API protection. You've likely encountered them when implementing login flows, securing microservice communication, or working with standards like OAuth 2.0 and OpenID Connect. Their popularity, however, has given rise to a series of persistent myths and dangerous anti-patterns.

Many developers treat JWTs as a magical black box, leading to implementations that are either insecure or overly complex. Believing these myths can expose your application to significant vulnerabilities.

In this article, we will dissect and debunk five of the most common misconceptions about JWTs. By understanding what a JWT is&mdash;and what it isn't&mdash;you can leverage its power correctly and build more secure and robust systems.


**Ready to see JWTs in action?** Watch this quick video for a visual overview of how JSON Web Tokens work and why misconceptions around them are so common.
<iframe width="560" height="315" src="https://www.youtube.com/embed/Q53HnM3iVLg?si=9XWET4vBTMC4a-fg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

## Myth 1: A JWT Is Just Another Name for a Token

One of the most fundamental misunderstandings is that "token" and "JWT" are synonymous. While a JWT is a type of token, not all tokens are JWTs.

A "token" in the general sense is simply a piece of data that represents a fact, usually an authorization grant. Historically, many of these tokens have been **opaque strings**. An opaque token is a random, meaningless string from the client's perspective. It acts as a reference, like a ticket stub. To get any information from it (like who the user is or what permissions they have), the receiving server must make a call back to the issuing server. Here is an example of an opaque token:

```shell
w3VzBypV4S1zaYd1-390AFda9d1t3-A4fWsdr23as
```

In contrast, a JSON Web Token (JWT) is a **structured token**. As defined in [RFC 7519](https://tools.ietf.org/html/rfc7519), a JWT is a compact, URL-safe means of representing claims to be transferred between two parties. It's not opaque; it's a self-contained JSON object that is digitally signed or encrypted.

> To learn more about JWTs, check out the [JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook) and use [jwt.io](http://jwt.io) to decode them.

Because it's self-contained, a service that trusts the issuer can validate a JWT and use its claims without needing to contact the issuer. **This is the core benefit of JWTs: stateless, decentralized validation**.

## Myth 2: JWT and Access Token Are Interchangeable Terms

This myth often follows the first. In OAuth 2.0 terminology, an **access token** is a credential used by a client to access protected resources. The crucial detail is that the OAuth 2.0 specification *does not mandate a specific format* for access tokens. They can be opaque tokens, or they can be JWTs.

So, why the confusion? JWTs have become a very popular format for access tokens. The benefits are clear:

* A resource server (e.g., a web API application) can validate a JWT-based access token without calling the authorization server on every request. It just needs the issuer's public key to check the signature.  
* The token itself can carry essential data, such as the user ID and [permissions (scopes)](https://auth0.com/blog/permissions-privileges-and-scopes/), reducing the need for extra database lookups.

However, an authorization server could just as easily issue an opaque access token and require resource servers to validate it via an [introspection endpoint](https://datatracker.ietf.org/doc/html/rfc7662). This stateful approach offers a major benefit: the token can be revoked instantly.

As a takeaway, remember that an access token is a *concept*&mdash;a key that unlocks a door. A JWT is a *format* for that key. You can have an access token that is not a JWT, but you can't say a JWT is always an access token, as it could be an [ID token](https://auth0.com/blog/id-token-access-token-what-is-the-difference/) or used for other purposes.

## Myth 3: JWTs Are Vulnerable Because Their Payload Is Readable

As mentioned before, you can decode a JWT by using [jwt.io](http://jwt.io). The following screenshot shows the content of a test JWT:

![The jwt.io debugger showing the decoded header and payload of a sample JSON Web Token, demonstrating that the payload data is visible by default.](https://images.ctfassets.net/23aumh6u8s0i/m0lLoapwO9AvmrYuLOdi9/aabdf7590adc697c787b1d3aa433bbe5/jwt-decoder-online.png)

A common reaction upon seeing a JWT for the first time is alarm. "I can decode this\! The data is exposed\! JWT is an insecure format\!"

A standard JWT is normally signed. Its payload is simply Base64Url encoded, not encrypted. You can easily paste the payload into any Base64 decoder and read its contents.

This visibility is by design. The purpose of the signature on a JWT is to guarantee **integrity** and **authenticity**, not **confidentiality**. The signature ensures that:

1. The data has not been tampered with since it was signed.  
2. The token was genuinely created by the party holding the signing key.

You should **never** put sensitive or secret information in the payload of a JWT. If you need confidentiality, you must use [JWE (JSON Web Encryption)](https://auth0.com/docs/secure/tokens/access-tokens/json-web-encryption), which encrypts the payload.

## Myth 4: A Signature Makes a JWT Inherently Secure

The signature is the most critical security feature of a JWT, but it's not a silver bullet. A signature is only as strong as the processes around it. Believing that "it's signed, so it's safe" is a dangerous oversimplification.

For a signed JWT to be truly secure, you must:

- **Use a strong algorithm:** Always use strong signing algorithms like [`RS256` or `ES256`](https://auth0.com/blog/rs256-vs-hs256-whats-the-difference/). Critically, your validation library **must** prevent the "none" algorithm attack, where an attacker strips the signature and changes the `alg` header to `"none"`.  
- **Validate all relevant claims:** A valid signature only proves the token hasn't been modified. It doesn't mean the token is still usable. You must always validate the standard claims:  
   * `exp`: Is the token expired?  
   * `nbf`: Is the token being used before it's valid?  
   * `iss`: Was the token issued by the authority you trust?  
   * `aud`: Was this token intended for your service (the audience)?  
- **Protect your signing keys:** If an attacker steals your symmetric secret (`HS256`) or your private key (`RS256`), they can forge valid tokens for any user. Key management is paramount.  
- **Transmit securely:** Always transmit JWTs over a secure channel (HTTPS) to prevent man-in-the-middle attacks from stealing the token in transit.

A signature doesn't protect against token theft via [Cross-Site Scripting (XSS)](https://auth0.com/blog/cross-site-request-forgery-csrf/) or compromised client devices. It's one piece of a larger security puzzle.

## Myth 5: JWTs Are a Modern Replacement for Sessions

This is perhaps the most contentious and widely debated myth. Many tutorials present JWTs as the "modern" way to handle user sessions, replacing old-fashioned server-side sessions. This is a misleading and often harmful narrative.

Traditional server-side sessions store session data on the server and give the client a simple, opaque session ID (usually in an `HttpOnly` cookie). JWTs, when used for sessions, move this state to the client inside the token.

This "stateless" approach has a massive drawback for user sessions: **revocation is extremely difficult**.

* **You can't easily log a user out:** If a user clicks "log out," how do you invalidate their JWT? It remains valid until its expiration time.  
* **A compromised token is a lasting threat:** If a JWT is stolen, the attacker can use it until it expires. You have no immediate way to kill that session.

Workarounds like blocklisting tokens exist, but they reintroduce server-side state, defeating the primary purpose of using JWTs for statelessness in the first place. At that point, you've just built a more complicated version of traditional sessions.

JWTs excel for short-lived, transactional scenarios where statelessness is a key architectural driver (e.g., authorizing a request in a microservices mesh). For managing user login state, the ability to centrally manage and instantly revoke sessions often makes the "old-fashioned" server-side session model a safer and simpler choice.

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

## Myths at a Glance

When applied correctly, JSON Web Tokens are a powerful and useful specification. They provide a standard for creating self-contained, verifiable tokens ideal for stateless systems and inter-service communication.

However, understanding their limitations is just as important as knowing their benefits. Here is a quick recap of the myths analyzed in this article:

![A summary table debunking five common JWT myths, covering topics like JWT security, access tokens vs. JWTs, payload visibility, signature security, and session management.](https://images.ctfassets.net/23aumh6u8s0i/P4pyLFEAKbhF9OKDX4Ss3/74a24471de857f1b8465b79aa31ce9d7/jwt-myths-vs-reality.png)

By moving past these common myths, you can make more informed architectural decisions. Don't treat JWTs as a generic solution for all things authentication and session-related. Instead, see them as a specialized tool in your developer toolkit—one that is incredibly effective when used for the right job.

Five Myths About JWTs Debunked

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

A deep dive into OAuth 2.0 access tokens and the principle of least privilege to enhance your application's security by correctly scoping tokens and implementing robust validation strategies.

In the context of modern application security, access tokens play a prominent role in authorization. They are the digital keys that grant applications access to protected resources on behalf of a user. However, with great power comes great responsibility. A compromised access token can be a significant security liability. This is where the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) (PoLP) becomes not just a best practice, but a critical defense mechanism.

This article takes a deep dive into the intersection of access tokens and the principle of least privilege, with a focus on leveraging the capabilities of [OAuth 2.0](https://auth0.com/intro-to-iam/what-is-oauth-2) to build more secure and resilient systems. We'll explore the foundational concepts, advanced techniques, and provide a practical checklist for your security reviews.

## What is the Principle of Least Privilege?

The **principle of least privilege** is a core concept in computer security. It states that users, programs, or processes should only be granted the minimum permissions necessary to perform their function. In other words, every component within a system should operate with the lowest possible level of access, or 'privilege', required for its tasks.

Think of it like giving keys to a building. Instead of giving every employee a master key that opens every door (*high privilege*), you give each person only the keys to the specific rooms they actually need to access (*least privilege*). For example, a receptionist gets a key to the front desk area, a developer gets a key to their office, but neither has access to the executive offices unless explicitly required.

This approach enhances security by **limiting the potential damage from an accident, error, or security breach**. If an account with limited privileges is compromised, the attacker's access is confined to a small controlled area, preventing them from gaining control over the entire system. Therefore, applying this principle means ensuring that applications and users can only access the specific data and perform the exact actions they are explicitly authorized to do, and nothing more.

## OAuth 2.0 and its Role in Access Control

At its core, OAuth 2.0 is an authorization framework, not an authentication protocol. This distinction is crucial. While authentication is about verifying identity, authorization is about granting permission to access specific resources. OAuth 2.0 provides a standardized way for a client application to obtain an access token from an authorization server, with the user's consent, to access resources hosted by a resource server.

A solid grasp of the OAuth 2.0 components is essential for implementing the principle of least privilege. Let’s quickly recap them:

* **Roles:**  
  * **Resource Owner:** The user who owns the data and grants permission to the application.  
  * **Client:** The application requesting access to the user's data.  
  * **Authorization Server:** The server that authenticates the resource owner and issues access tokens after obtaining their consent, e.g., Auth0.  
  * **Resource Server:** The server that hosts the protected resources and accepts access tokens for authorization, typically implemented as an API.  
* **Tokens:**  
  * **Access Token:** A credential used by the client to access protected resources. It represents the authorization of a specific client to access specific resources.  
  * **Refresh Token:** A long-lived credential used to obtain a new access token when the current one expires.  
* **Scopes:** The mechanism within OAuth 2.0 that allows us to define the granular permissions a client can request.

With this basic knowledge, let's delve deeper into how to implement the LP principle in a system protected by access tokens.

> For a deeper understanding of OAuth 2.0, consider reading [OAuth 2.0 and OpenID Connect: The Professional Guide](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide).

## Scopes: The Heart of Least Privilege in OAuth 2.0

The true power of OAuth 2.0 in enforcing the principle of least privilege lies in the effective use of [scopes](https://auth0.com/blog/permissions-privileges-and-scopes/). Scopes are strings that define the specific permissions a client application is requesting. Unlike [OpenID Connect](https://auth0.com/docs/get-started/apis/scopes/openid-connect-scopes), OAuth 2.0 does not define standard scopes. The scopes used in an application scenario depend on the specific business case. Specifically, they are defined by the resource server (API) implementer and must be known to the client application. When designing the scopes for your API, follow a few best practices.

### No scopes, No party!

While the OAuth 2.0 specification does not explicitly forbid a client from [requesting an access token without a `scope` parameter](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1), doing so represents a significant security anti-pattern and a direct violation of the principle of least privilege.

When a client initiates an authorization request without specifying any scopes, [the authorization server's behavior can be ambiguous](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Since the OAuth 2.0 specifications do not define a standard behavior to handle this case, your application can receive an error message or a subset of predefined scopes, possibly empty.

Moreover, if API implementations do not accurately check scopes, you may find yourself in a scenario where the issued access token essentially grants the full permissions of the user.

This practice carries substantial risk. If a scopeless access token is compromised—leaked from a client-side application, intercepted in transit, or exfiltrated from a backend system—the attacker gains broad, unrestricted access to the user's resources. They could potentially read sensitive data, modify information, and perform actions on behalf of the user, all because the token's power was not constrained.

As a result, avoid scopeless access tokens. Always include the `scope` parameter in your application's authorization requests, and make your APIs always check for the expected scopes.

### Designing granular scopes

Vague or overly broad scopes defeat the purpose of least privilege. Consider an e-commerce API. You may think of scopes like `orders` or `profile` to allow access to the user’s orders and profile. However, these scopes are not explicit on the type of access they grant. Probably the `orders` scope says that your application can manage orders, i.e., it can read, create, update, print, for example. A more granular approach would be:

* `orders:read`: Allows the client to read a user's order.  
* `orders:write`: Allows the client to create new orders.  
* `profile:read`: Allows the client to read the user's profile information.  
* `profile:write`: Allows the client to update the user's profile.

This granularity ensures that a third-party analytics dashboard, for example, would only ever request and be granted the `orders:read` scope, mitigating the potential damage if its access token were to be compromised.

The following picture visually summarizes the application of the principle of least privilege using granular scopes:

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/4qzpht7LRcPnUerDwZXs07/6e09324185fd2afd7aa3488d1655b671/access-tokens-with-and-without-least-privilege.png" alt="A diagram comparing API access with and without the principle of least privilege, showing how OAuth 2.0 access tokens can provide granular, limited access for better API security." style="width:75%; margin: 0px auto;">
</picture>

### Leveraging hierarchical scopes

OAuth 2.0 does not strictly specify the format of scopes. They are generic strings whose meaning depends on the API context. As illustrated in the examples above, a common approach is to use the format `resource:action`. Some use the dot (`.`) as a separator instead of the colon (`:`). It really does not matter.

While you are free to use the format you prefer, consider taking advantage of the hierarchical structure of the format suggested above. For example, if you want to grant access only to the status of an order for informational purposes, but not at the details of the order, you can define a scope like `orders:status:read`. This allows you to have more granular control over a protected resource.

For more advanced scenarios, you may consider using [OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396), which allows you to specify detailed authorization requests.

### Using dynamic scopes

Modern applications often require different levels of access at different times. Instead of requesting all possible permissions upfront, a better user experience and security practice is to request scopes dynamically as needed. For instance, an application could initially request `profile:read` on user sign-up. Later, when the user wants to perform an action that requires more permissions, such as updating their profile, the application can initiate a new OAuth 2.0 flow to request the `profile:write` scope. This adheres to the principle of just-in-time access.

### Ensuring user consent

[User consent](https://auth0.com/docs/get-started/applications/confidential-and-public-applications/user-consent-and-third-party-applications) is a critical component in OAuth 2.0 authorization requests, directly supporting the principle of least privilege.

The authorization server must obtain explicit approval from the user, ensuring they understand and consent to the specific access an application client is requesting on their behalf. This consent should be freely given, with adequate information provided to the user.

In this context, a user-friendly description of the scopes a client application is requesting is key. The user should be aware of the permissions they are delegating to the application.

> A key aspect is that scopes do not create new permissions; they merely represent **a subset of the permissions the user already possesses** and delegated to the client application.

## Beyond Scopes: Advanced Token Security and Validation

While scopes are the primary tool for defining what an application can do on behalf of the user, a comprehensive strategy for least privilege involves more than just well-designed scopes. You must also consider the entire lifecycle of an access token.

### Token validation best practices

At the resource server, every incoming access token must be rigorously validated before granting access. This validation should go beyond simply checking the token's signature and expiration. Here are the fundamental steps to validate an access token before granting the application access to the resource:

1. **Signature Verification:** Always verify the token's signature against the authorization server's public key. This ensures the token was issued by a trusted source and has not been tampered with.  
2. **Expiration Check:** Check the `exp` claim to ensure the token has not expired.  
3. **Issuer and Audience Validation:** Verify the `iss` (issuer) and `aud` (audience) claims. The `iss` should match the expected authorization server, and the `aud` should match your resource server. This prevents tokens issued for one application from being used to access another.  
4. **Scope Enforcement:** This is the critical step for least privilege. The resource server must check the `scope` claim in the access token and ensure that the requested action is permitted by the granted scopes.  
5. **User Permissions Check**: Last but not least, make sure that the resource your application is requesting to access is actually accessible by the user with the permissions matching the scopes. Read [this article](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/) to learn more about this.

### Short-lived access tokens and refresh tokens

In addition to a correct design and use of scopes, the management of access tokens is a critical security component adhering to the principle of least privilege. A key strategy to bolster security is the implementation of short-lived access tokens. The rationale behind this approach is to drastically reduce the "*window of opportunity*" for a potential attacker. If an access token, which grants an application permission to access specific resources, were to be compromised, its utility would be severely limited by its short lifespan.

Typically, these short-lived access tokens are issued with a validity period ranging from a few minutes to a few hours, depending on the business case and the security level required.This brevity is a deliberate security measure connected to the principle of least privilege: not only your application must have the minimum permissions it needs, but it must have them for the minimum amount of time necessary. However, to ensure a seamless user experience without requiring re-authentication every few minutes, a complementary mechanism is employed: [refresh tokens](https://auth0.com/docs/secure/tokens/refresh-tokens).

When an access token expires, the client application can use the refresh token to request a new, valid access token from the authorization server. This process is transparent to the user, maintaining a continuous session.

Given their power to grant new access tokens, refresh tokens themselves must be securely managed to prevent security issues. Learn more [about refresh tokens by reading this article](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/).

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

## Security Review Checklist for Access Token-Based Systems

To assist in your development and review process, here is a checklist to help ensure you are adhering to the principle of least privilege and other access token security best practices.

**Scope and Permissions**

* Are scopes granular and well-defined, following the principle of least privilege?  
* Does the application request only the necessary scopes at any given time?  
* Is there a process for users to review and consent to the requested scopes?  
* Are there different levels of scopes for read vs. write vs. administrative actions?

**Token Issuance and Lifecycle**

* Are access tokens short-lived?  
* Are refresh tokens used to obtain new access tokens?  
* Are refresh tokens stored securely on the client?  
* Is there a mechanism to revoke refresh tokens and access tokens?

**Token Validation at the Resource Server**

* Is the token's signature verified on every request?  
* Is the token's expiration (`exp` claim) checked?  
* Is the issuer (`iss` claim) validated against a trusted value?  
* Is the audience (`aud` claim) validated to ensure the token is intended for this API?  
* Is the `scope` claim inspected, and are the permissions enforced for the requested operation?

## Conclusion

Building secure applications is not an afterthought but a core responsibility. The principle of least privilege is a powerful paradigm for mitigating the risks associated with access tokens. By meticulously designing granular scopes, implementing robust token validation, and managing the token lifecycle effectively, you can significantly enhance the security posture of your applications.

The OAuth 2.0 framework provides the tools necessary to implement a least privilege model, but it is your responsibility as developers to use them correctly and diligently. By following the best practices and using the checklist provided, you can be more confident in the security and resilience of your access token-based systems.

OAuth 2.0 Access Tokens and the Principle of Least Privilege

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

Learn about the new classification of MCP servers as OAuth Resource Servers, implementing Resource Indicators to prevent token misuse, and the clearer security best practices designed to help you build more robust and secure MCP applications

As developers, we're building the next generation of applications on a foundation of interconnected services. The Model Context Protocol (MCP) is rapidly becoming a key part of that foundation, enabling seamless context sharing between AI models and applications. But as adoption grows, how do we ensure the connections we build are secure?

The [latest changelog](https://modelcontextprotocol.io/specification/2025-06-18/changelog), released on June 18, 2025, introduces updates that clarify how authorization should be handled for MCP Servers and how MCP Clients should implement [Resource Indicators](https://www.rfc-editor.org/rfc/rfc8707.html) to prevent malicious servers from obtaining access tokens.

Let's break down what’s new for auth and what it means for you as you build with MCP.

## MCP Servers Now Classified as OAuth Resource Servers

MCP servers are now officially classified as [OAuth Resource Servers](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#authorization-server-discovery). This might seem like a small semantic change, but it has significant implications for security and discovery.

By defining MCP servers this way, the protocol now includes a mechanism to add protected resource metadata. What does this mean in practice? It allows an MCP server to advertise where its corresponding Authorization Server is located. This discovery mechanism is vital for clients, as it removes ambiguity and ensures they request tokens from the legitimate, intended authority, streamlining the authorization process securely.

## Preventing Token Misuse by Implementing Resource Indicators (RFC 8707)

Have you ever worried about a token intended for one service being misused at another? This is a legitimate threat known as "token mis-redemption." To combat this, MCP clients are now required to implement Resource Indicators, as specified in [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707).

![A diagram illustrating MCP security, showing how Resource Indicators (RFC 8707) prevent token misuse by locking an access token to a specific audience (resource server)](https://images.ctfassets.net/23aumh6u8s0i/5H7veAQxKRIcnI6bOHWyEI/c2c6881322830a9283a5360af6906c68/Uploaded_from_Model_Context_Protocol__MCP__Spec_Updates_from_June_2025__One_Small_Step_for_a_Spec__One_Giant_Leap_for_Security)

By using a resource indicator in the token request, a client explicitly states the intended recipient (the "audience") of the access token. The Authorization Server can then issue a token that is _tightly scoped_ and only valid for that specific MCP server. This prevents a malicious or compromised server from taking a token it received and using it to access a different protected resource on the user's behalf. Put plainly, this practice ensures your tokens can't be used where they don't belong.

## Clearer MCP Security Guidance and Best Practices

Building secure systems is easier when the rules of the road are crystal clear. This update brings significant clarifications to the core [authorization spec's security considerations](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#security-considerations) and introduces a brand new, dedicated page for [security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices).

This new guidance provides actionable advice for developers like you and me so we can implement both clients and servers more securely. It centralizes security guidance, making it easier to build robust and secure MCP integrations from the ground up. We strongly recommend all developers working with MCP review these pages.

## Building a More Secure Future

These updates represent a significant step forward in hardening the Model Context Protocol. By formalizing the roles of servers, mandating token protection with resource indicators, and providing clearer documentation, the MCP is becoming an even more robust and trustworthy standard for the AI application ecosystem.

While these aren’t the only changes in the June 18th MCP specification changelog, they are the most impactful ones concerning authentication and authorization. If you are building and securing MCPs you should check out our documentation on Auth for MCP and the Getting Started with Auth0 Model Context Protocol (MCP) Server.

Now you’re ready to go forth and enhance the security of your MCP servers and clients.

Model Context Protocol (MCP) Spec Updates from June 2025: One Small Step for a Spec, One Giant Leap for Security

The final release of Vittorio Bertocci’s book about OAuth 2.0 and OpenID Connect is finally out! Learn more about the project journey and download your free copy.

The final release of the ebook [OAuth 2.0 and OpenID Connect: The Professional Guide](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide) has been published. [Get your free copy here!](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide)

Born from the initiative of one of the most influential personalities in the world of Identity, the late [Vittorio Bertocci](https://auth0.com/blog/in-celebration-of-vittorio-bertocci/), the book analyzes OAuth 2.0 and OpenID Connect, explaining not only how they work but also the motivations that led to the creation of these standards as they are today.

## The Origins of the Project

I met Vittorio when I joined Auth0 in 2019. I only knew him as an authoritative expert in the field of Identity, and I knew very little about that topic. Usually, he was in charge of onboarding training for the technical staff, but when I went to Bellevue for my onboarding, another trainer was assigned. However, he came to the office to greet me because he had learned an Italian was in the group of new hires. A clear signal that he was more than just an Identity expert: he was a person full of empathy.

I had the honor of working closely with Vittorio at the beginning of my career at Auth0. Partly for helping him with this book and partly for his review of other developer content my team and I created. This gave me the opportunity to learn a lot, not only about the technical aspects of Identity but also about how to explain complex concepts based on the specific audience. His style, which is rich in metaphors and anecdotes (you will find several in this book), has always fascinated me. His histrionic manner, his marked accent, and his all-Italian gestures establish him in my imagination as a great storyteller.

We started this book project at the end of 2019 and have published it incrementally in two editions. Vittorio had already drawn up the roadmap for the book and shared diagrams and notes with me, but his innumerable commitments led him to postpone its completion.

## Vittorio's Premature Passing

His untimely death in October 2023 shocked me, as well as the entire community of Identity professionals. Several times, I received requests for information from developers about the book's completion. Therefore, I thought it was right not to disappoint readers and honor Vittorio's memory by completing the book according to the original roadmap and based on his notes. I tried as much as possible to maintain his style, even if it was unique and unrepeatable. Since this project started, some things have changed, so I had to update some references, even in the already published chapters. In this work of adaptation, updating, and revision, the help of [Aaron Parecki](https://aaronparecki.com/) and [Filip Skokan](https://cz.linkedin.com/in/filipskokan) was invaluable, and my heartfelt thanks go to them.

## A Final Note on the Book

One last note before leaving you to read the book. This is not a technical handbook about OAuth 2.0 and OpenID Connect. This book will not give you detailed guidelines on how to use OAuth 2.0 and OpenID Connect in your applications. Or rather, you will learn this too, but more than anything else, this guide will explain to you the reason for the small details of these protocols, why we arrived at them, and how we arrived at them.

Understanding the reason for the technical choices and, therefore, the history behind them will help you better understand OAuth 2.0 and OpenID Connect and gain professional knowledge of them. That said, I hope you will enjoy [reading this book](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide)!

OAuth 2.0 and OpenID Connect: The Professional Guide

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

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

Learn how to prevent CSRF attacks from compromising your users when implementing Google OAuth for user registration and user login.

Growing an active user base is a top priority for all developers. Your product pages need copy, design, and engineering that can efficiently and effectively convert visitors into users. A visitor is an anonymous person browsing your site or app. A user is a visitor who exchanges some information to access more layers or features of your app. Even with just an email address or username, you can build a profile or identity for a user.

As such, user authentication is the backbone of conversion. User registration and login must be secure and as frictionless as possible. Long and tedious forms or requirements during registration can turn prospects away. Errors or downtime during login can frustrate even your most loyal customers, leading to dissatisfaction or support tickets.

## Why Use Google OAuth for User Authentication

A reliable way to implement user registration and authentication in an application and turn visitors into users quickly and securely is by using a registration and authentication system that your visitors already use and trust, such as Google.

As a developer, you can take advantage of Google's high security and trust Google as a source to safeguard user credentials so that you don't have to. Google social login leverages the OAuth 2.0 protocol for authorization and uses [OpenID Connect (OIDC)](https://developers.google.com/identity/openid-connect/openid-connect) as the standard for user authentication. You can delegate to Google's UI/UX and engineering the burden of password requirements, password protection, password error handling, email verification, profile data collection, and more. 

How easy or difficult is it to implement Google Login on your own? It depends. On the surface, it may be like a simple endeavor: In the JavaScript ecosystem, use a library like [`google-auth-library`](https://www.npmjs.com/package/google-auth-library), write a few lines of code, and call it a day.

While `google-auth-library` is a robust client library for using OAuth 2.0 authorization and authentication with Google APIs, it's essential to know how to use it effectively to avoid introducing security vulnerabilities in your application that could put your end-users and your organization at risk.

For instance, a recent [post on X](https://x.com/forgebitz/status/1858616526540042521) went viral: a developer named Klaas shared with the X developer community a code snippet on how to implement "google login with just the google-auth-library, no frameworks in 50 lines of code":

```typescript
export const googleLoginAction = {
  getAuthUrl: () => {
    const query = {
      client_id: oauth_google.client_id,
      redirect_uri: oauth_google.redirect_uri,
      response_type: "code",
      scope: oauth_google.scopes,
    };

    const url = new URL(oauth_google.endpoint);
    url.search = new URLSearchParams(query).toString();
    return url.toString();
  },
  verifyGoogleCode: async ({ code }: { code: string }) => {
    log.info({ code }, "verifying google auth code");

    try {
      const tokenResponse = await fetch("https://oauth2.googleapis.com/token", {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: new URLSearchParams({
          client_id: oauth_google.client_id,
          client_secret: oauth_google.client_secret,
          code,
          grant_type: "authorization_code",
          redirect_uri: oauth_google.redirect_uri,
        }),
      });

      const tokenData = (await tokenResponse.json()) as { id_token: string };

      const ticket = await client.verifyToken({
        idToken: tokenData.id_token,
        audience: oauth_google.client_id,
      });

      const userData = ticket.getPayload();
      log.info({ userData }, "google auth successful");
    } catch (error) {
      log.error({ error }, "failed to verify google auth code");
      throw new Error("Failed to verify Google authentication");
    }
  },
};
```

Klaas' X post ignited a passionate discussion around user authentication and general security. As of the time of writing, the post had gathered 449k impressions, 4.7k likes, 387 reposts, and 83 comments.

## Google OAuth Implementation Can Go Wrong

Some of the commenters asked questions about the code's security posture, while others offered insights and advice on how to improve the security of that Google OAuth implementation.

Some commenters assumed the code was running on the client and were alarmed by the code handling a client secret, which could lead to a security compromise. Klaas clarified that the code is intended to run in the backend and [further explained its purpose as follows](https://x.com/forgebitz/status/1858776267266441324):

 "_this [code] has two simple functions, create a URL where you redirect the user to and a verify code function, you have the create a /callback (on the server) to get that URL. You still need to make authentication/authorization_"

Some other commenters pointed out that the code could be subject to a [Cross-Site Request Forgery (CSRF) attack](https://en.wikipedia.org/wiki/Cross-site_request_forgery), which confused others: How can there be a CSRF attack if there's no cookie involved or when the code does not run in the client?

First and foremost, let's recap what a Cross-Site Request Forgery (CSRF) attack is. [Andrea Chiarelli](https://auth0.com/blog/authors/andrea-chiarelli), Principal Developer Advocate at Okta, [summarizes a CSRF attack as follows](https://auth0.com/blog/cross-site-request-forgery-csrf/#--What-is-CSRF--):

- A typical Cross-Site Request Forgery (CSRF or XSRF) attack aims to perform an operation in a web application on behalf of a user without their explicit consent.
- The attacker leads the user to perform an action, like clicking a link.
- This action sends an HTTP request to a website on behalf of the user.
- If the user has an active authenticated session on the trusted website, the request is processed as a legitimate request sent by the user.

Andrea warns us that "even though CSRF attacks are commonly associated with session cookies, be aware that [Basic Authentication sessions](https://en.wikipedia.org/wiki/Basic_access_authentication) are also vulnerable to CSRF attacks" and that, in fact, "a CSRF vulnerability relies on the authenticated session management".

[Sandrino Di Mattia](https://x.com/sandrinodm) is a Senior Director on the Product Architecture team at Okta with robust and deep experience in cloud, identity, and security. In the thread, Sandrino commented that the code doesn’t seem to perform any state validation, making it open to CSRF attacks.

You may be wondering like others did: ["CSRF attack without any cookies, must be a new thing"](https://x.com/__morse/status/1858951728852295909). Let's explore how improperly implemented OAuth can lead to a CSRF attack.

## Cross-Site Reference Forgery (CSRF) Are Not About Cookies

Sandrino shares that CSRF is not related to cookies. Missing state validation is the most basic vulnerability in OAuth flows. [OAuth 2.0 specification recommends a `state` parameter](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1) that allows you to verify the authenticated state of your browser. The `state` parameter preserves the browser's authenticated state set by the client in an authorization request, and the authorization server makes it available to the client in the response.

[The `state` parameter helps you mitigate CSRF attacks](https://datatracker.ietf.org/doc/html/rfc6749#section-10.12) by using a unique and non-guessable value associated with each authentication request about to be initiated. That value allows you to prevent the attack by confirming that the value from the response matches the one you sent.

**But how does a CSRF attack work without cookies?**

Sandrino explains that an attacker can go through the OAuth flow but stop right when the redirect with the authorization code to the callback URL happens. Now, the attacker can send the link to the callback URL, including the code, to the victim, which consumes the code on their machine.

Depending on the implementation of your application, a few security, privacy, and data exploits could happen. For example, the attacker's account is now forced on the victim’s browser. The victim now could be uploading docs or filling in and sending personal data to the attacker's account, thinking it’s the victim's account. Or a worse scenario: the victim is already signed in, and now this new identity (the attacker's identity) is automatically linked to the victim's existing account.

## Prevent CSRF Attacks in Google OAuth

Sandrino advises us that preventing this type of attack takes a few lines of code. In practice, on redirect, you store a random value in a cookie. You then send that value to Google using the `state` param. On callback, you validate the incoming `state` parameter with the value in the cookie. If the `state` value in the response does not match the `state` value in the cookie, you reject the login operation and stop further access. The `state` parameter and PKCE can help prevent this type of attack.

> For a deep dive on this topic, you can consult the ["More Guidelines Than Rules: CSRF Vulnerabilities from Noncompliant OAuth 2.0 Implementations"](https://www.cise.ufl.edu/~butler/pubs/dimva15.pdf) paper from the Georgia Institute of Technology and the University of Florida. Check out section 3.3 on page 8.

There's a saying that goes: "You don't know what you don't know". But then, how can you know? By doing precisely what Klaas did: share code with others and be open to feedback and constructive criticism. At the same time, you can leverage the knowledge and expertise of others who have been through similar and more complex situations, which can help you avoid falling into traps or dangerous holes.

You may be thinking, "I can rely on AI for that!" You can use AI tools to learn and understand, but remember that those tools are imperfect, as they are an aggregation of human knowledge and can also make mistakes. There are instances where an AI tool can present you with "security" code with high confidence. Still, that code could be anything but secure, missing the implementation of security best practices or defensive mechanisms.

## Use Libraries to Implement Google OAuth 

It's important to highlight that if you want to implement a standard protocol yourself, you need to understand its specifications well, be aware of its nuances, and follow its details diligently. Instruments like the `state` parameter and all other security measures included in specifications and standards are the result of discussions and experience of industry experts throughout the years.

As developers, we often fall into the dilemma of reinventing the wheel (do it yourself) or relying on those who have already done it in the best way (use a library).

Sandrino suggested in the thread that it's better to use a library like Passport.js over the code shared on the tweet&mdash;or rather, X post. Passport.js implements OAuth 2.0 the way that the standard defines it. You can inspect the implementation of Google OAuth in Passport.js by looking at the [`lib/strategy.js`](https://github.com/jaredhanson/passport-google-oauth2/blob/master/lib/strategy.js) file of the [`passport-google-oauth20`](https://github.com/jaredhanson/passport-google-oauth2/tree/master) npm package.

The `OAuth2Strategy` from Passport is well-documented. The comments in the code can quickly guide you on what's happening through that flow:

- The Google authentication strategy authenticates requests by delegating to Google using the OAuth 2.0 protocol.
Applications must supply a `verify` callback function that accepts an `accessToken`, `refreshToken`, and service-specific `profile` and then calls another `cb` callback function, supplying a `user`. The `user` value should be set to `false` if the credentials are invalid. If an exception occurs, `err` should be set.

Let's see an example of how you'd use Google OAuth login with Passport.js:

```javascript
passport.use(new GoogleStrategy({
    clientID: '123-456-789',
       clientSecret: 'shhh-its-a-secret'
       callbackURL: 'https://www.example.net/auth/google/callback'
     },
     function(accessToken, refreshToken, profile, cb) {
       User.findOrCreate(..., function (err, user) {
         cb(err, user);
       });
     }
));
```

As you inspect the implementation code, you'll notice that Passport.js does much more than handle the login. [OAuth 2.0 provides consented access and restricts actions](https://auth0.com/intro-to-iam/what-is-oauth-2) of what a client app can perform on resources on behalf of the user without users ever sharing their credentials with the application. Using Google OAuth 2.0, you can also request access to user contacts and other resources on the Google platform. As the needs of your application scale, you may see yourself needing a more complex data access policy that calls for more code to write and maintain and more scenarios and edge cases to be aware of.

## Google OAuth Attacks Go Beyond CSRF Attacks

Security is an ever-evolving landscape. It's critical for you to stay on the vanguard regarding security in the industry, especially with the rise of artificial intelligence (AI). Implementing authentication on your own is an investment in money, risk, and time. Relying on robust, time-tested libraries or identity service providers can minimize some of those costs.

As mentioned in the post, implementing social login with Google OAuth for your app is just one piece of the authentication puzzle. Once you have users, you are responsible for protecting the data they entrust you. For example, depending on the region where you operate, you may be subject to regulations around user management and privacy, such as GDPR, which also extends to logs, not just the user data you have in your databases.

As you scale and grow in popularity, you may also gain unwanted attention from bad actors and attackers who may want what you are securing: rich user data. But, even on a small scale, you may become the target of bad actors looking to test their skills to break into apps.

> Recommended read: [The biggest underestimated security threat of today](https://techcrunch.com/2024/11/01/the-biggest-underestimated-security-threat-of-today-advanced-persistent-teenagers/)

In the X thread we have been discussing, Jared Hanson, the creator of Passport.js and a Principal Product Architect at Okta, validated that "checking a nonce or state is highly recommended." Jared added, "It’s less simple, but it protects against common attacks."

[Aaron Parecki](https://aaronparecki.com/), Director of Identity Standards at Okta, reminded me that it's not just CSRF attacks that are the concern when it comes to OAuth 2.0 flows. Even if you fix the CSRF attacks we have described, you could still be open to an OAuth 2.0 authorization code injection attack, which you can prevent with PKCE. You can learn more about that type of attack by watching the video below: 

<AmpContent>
<amp-youtube
    data-videoid="1ot45WwQWJE"
    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/1ot45WwQWJE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

Aaron also hosted an "OAuth Happy Hour", which includes [a demo of the authorization code injection attack](https://www.youtube.com/watch?v=moQidjdV5cw). Be sure to check it out!

Let us know if you'd like a detailed follow-up blog post covering the OAuth 2.0 authorization code injection attack.

## Aside: Use Auth0 to Implement Google Social Login

Auth0 makes it even easier to get started with Google. Every new tenant has the Google social connection enabled by default. You don't even have to set up a Google Cloud project to see Google social login in action. Auth0 maintains a set of developer keys you can use to start testing Google social login in your applications in development. Follow the ["Google Social Connection to Login"](https://developer.auth0.com/resources/labs/authentication/google-social-connection-to-login#introduction) lab to learn how to use those Google dev keys and set up ones for production.


Prevent CSRF Attacks in OAuth 2.0 Implementations

Learn what Pushed Authorization Requests are and when to use them to strengthen the security of your OAuth 2.0 and OpenID Connect-based applications.

In highly sensitive contexts, such as in financial or healthcare sectors, the security bar must be raised to prevent any breach of information and artifacts that could give unauthorized access to user data. [Pushed Authorization Requests (PAR)](https://datatracker.ietf.org/doc/html/rfc9126) is one extension that enhances OAuth 2.0  and OpenID Connect so that they can be securely used in these scenarios. Let's explore how this OAuth 2.0 extension works.

## Why use PAR?

Let's start by first understanding why you may need PAR and what problem it tries to resolve.

### The OAuth authorization request

If you have some experience with OAuth 2.0 and OpenID Connect, you know that the initial step that a client application must take to get the tokens it needs is to send an authorization request to the authorization server. For this purpose, the user's browser is redirected to the authorization server with a URL similar to the following:

```bash
https://your-authorization-server.com/authorize?
    client_id=1234567890&
    redirect_uri=https://your-app/callback&
    scope=openid profile email phone address&
    response_type=code&
    audience=https://myapi&
    state=12c1d32c1aba2cc14f9b907a9ec90
```

This authorization request URL is pretty basic, but you can add other parameters based on the [OAuth flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow) you are using or on the specific extension/customization your authorization server implements. For example, if you are using the [Authorization Code Flow with PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce), you should also add the `code_challenge` and `code_challenge_method` parameters. In Auth0, you can also specify the `organization` or `invitation` parameters if you are using the [Auth0 Organizations](https://auth0.com/docs/manage-users/organizations) feature, and so on. The complexity of the authorization request can grow considerably depending on your specific use case.

### What's the problem with the authorization request?

As you can see, the authorization request is nothing but a GET HTTP request against a URL with its parameters:

```http
GET /authorize?
    client_id=1234567890&
    redirect_uri=https%3A%2F%2Fyour-app%2Fcallback&
    scope=openid%20profile%20email%20phone%20address&
    response_type=code&
    audience=https%3A%2F%2Fmyapi&
    state=12c1d32c1aba2cc14f9b907a9ec90 HTTP/1.1
Host: your-authorization-server.com
```

In this form, it may raise a few concerns:

- **The authorization request can be altered**. Usually, the client application redirects the user's browser to the authorization server with the authorization URL. Nothing prevents a malicious actor from changing one or more parameters of this request before sending it to the authorization server.
- **No guarantee of the request's provenance**. The authorization request is normally built by the client application, and the user's browser is in charge of sending it to the authorization server. However, there is no guarantee that the request has been built by the client application. Anyone can build an authorization request once they know a few data, such as the client ID and the redirect URI.
- **No guarantee of confidentiality**. Although the browser sends the authorization request via HTTPS, the request parameters can be intercepted by third-party applications, such as a proxy, a load balancer, or even a browser plugin. A malicious network component of this type can inject or change the request parameters, not to mention that the request itself can be logged.
- **Browser limitations**. Finally, a very complex query string in the authorization request may incur [possible browser limitations on URL length](https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers).

This is where Pushed Authorization Requests come into play.

## How PAR Works

The basic idea of Pushed Authorization Requests is very simple: instead of redirecting the user's browser to make the authorization request with all the parameters, the client application *pushes* that request directly to the authorization server with a POST request and gets an identifier for that request. Now, the client application redirects the user's browser to the authorization server with just that identifier to make its authorization request, avoiding exposing all the details.

### The PAR endpoint

The first requirement for an authorization server supporting PAR is to expose the PAR endpoint. This is an additional endpoint that will accept authorization requests with the parameters in the payload. The following example shows how a request to the PAR endpoint looks like:

```http
POST /oauth/par HTTP/1.1
  Host: your-authorization-server.com
  Content-Type: application/x-www-form-urlencoded
  client_id=1234567890&
  client_secret=<YOUR_SECRET>&
  redirect_uri=https%3A%2F%2Fyour-app%2Fcallback&
  scope=openid%20profile%20email%20phone%20address&
  response_type=code&
  audience=https%3A%2F%2Fmyapi
```

Notice the reference to the `/oauth/par` path and how the parameters are passed through POST. You can see some differences between the parameters passed in the standard GET-based authorization request and this request. Apart from the usual parameters such as `client_id`, `redirect_uri`, `scope`, etc., you may notice that the `client_secret` is passed here. This is a request coming from a [confidential client](https://auth0.com/docs/get-started/applications/confidential-and-public-applications#confidential-applications), that is, a client capable of securely storing a secret, such as a server-running application. By passing `client_id` and `client_secret`, the request is authenticated by the authorization server resolving the confidentiality concerns we discussed earlier.

> The PAR specification does not limit access to the PAR endpoint to confidential clients only. It states that "*the rules for client authentication as defined in [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)] for token endpoint requests, including the applicable authentication methods, apply for the PAR endpoint as well.*"
>
> This entails that even public clients can potentially access the PAR endpoint. However, their public nature does not allow them to safely determine their identity, so some of the concerns about the integrity and confidentiality of the request still remain in this case.

As a response to this request, the authorization server will respond with something like the following:

```http
HTTP/1.1 201 Created
Content-Type: application/json

{
  "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACi5bwq064ltcg4eY28s",
  "expires_in": 30
}
```

The authorization server's response is a JSON object with two properties:

- `request_uri`. This is the identifier of the authorization request pushed by the client application.
- `expires_in`. This is the number of seconds that the authorization request is valid.

With these basic notions, let's take a look at how the whole authorization process works.

### The PAR authorization flow

The following diagram illustrates the OAuth authorization flow using PAR:

![Pushed Authorization Request flow](https://images.ctfassets.net/23aumh6u8s0i/6FWUrUsNmimPr10XuqI26k/984cf829065bab1dacd1a6dafc08e92c/pushed-authorization-requests-flow.png)

Here are the steps highlighted in the diagram:

1. The client application sends an authorization request to the PAR endpoint of the authorization server.

2. The authorization server authenticates the application client, validates the request, and stores it. Then, it replies with a response containing the authorization request's identifier (`request_uri`) and the validity time (`expires_in`).

3. The client application uses the `request_uri` to build the authorization request URL for the user's browser and redirects it to the authorization server. The authorization request URL will look like the following:

   ```bash
   https://your-authorization-server.com/authorize?
       client_id=1234567890&
       request_uri=urn%3Aietf%3Aparams%3Aoauth...4ltcg4eY28s
   ```

4. The user's browser sends a GET request to the authorization server using the authorization request URL received by the client application. The authorization server retrieves the authorization request identified by the `request_uri` value, and from now on, the usual steps of the requested OAuth flow are carried out.

As you can see, the browser's request no longer contains the details of the authorization request. There is no risk of tracking or in-transit manipulation of the request. Also, the complexity of the URL is considerably reduced.

## PAR Metadata

OAuth and OpenID Connect servers publish the configuration metadata in the `/.well-known` URI to publicly declare the supported capability and other protocol details. PAR specification adds two new keys to this metadata:

- `pushed_authorization_request_endpoint`. This key defines the PAR endpoint where the client application can push the authorization request and get the corresponding  `request_uri`.
- `require_pushed_authorization_requests`. This key has a boolean value indicating whether using PAR is mandatory (`true`) or optional (`false`). If this key is not present, the default value is `false`.

With this metadata, your application can check if an authorization server supports PAR using the usual [discovery approach](https://auth0.com/docs/get-started/applications/configure-applications-with-oidc-discovery).

## PAR and Auth0

Auth0 supports PAR as part of the [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity) add-on of the Enterprise plan. Highly Regulated Identity is Auth0's implementation of FAPI 1, the set of standards that raises the security level to protect application operations in sensitive contexts, such as finance, healthcare, e-commerce, etc.

By default, PAR is not active in an Auth0 tenant. You have to enable it at the tenant level to make the PAR endpoint available to your applications. You can do it through your Auth0 dashboard. Follow [the steps described here to enable PAR](https://auth0.com/docs/get-started/applications/configure-par#set-par-for-a-tenant) in your Auth0 tenant.

Once you enable PAR at the tenant level, your applications can use the classic authorization endpoint or the PAR endpoint. If you want to make the endpoint mandatory for a specific application, you should require it at the Auth0 application configuration level. You can use the Auth0 dashboard or the Auth0 Management API to set PAR endpoint mandatory. Follow [these instructions](https://auth0.com/docs/get-started/applications/configure-par#set-par-for-an-application) to enable mandatory PAR for your application.

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

## Conclusion

Pushed Authorization Requests (PAR) are a great addition to strengthen the security of OAuth 2.0 and OpenID Connect protocols. As you have learned, it enables client applications to make authorization requests without exposing the details of the call to potential tracking and manipulation.

This security improvement is critical in scenarios where data confidentiality must be preserved, and Auth0 offers PAR support through Highly Regulated Identity (HRI). Combined with other strong security enhancements supported by HRI, you can build applications with high-security standards and comply with the most common regulations. Check out this document to learn more about [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity).



What Are OAuth Pushed Authorization Requests (PAR)?

A wrong interpretation of the OAuth specifications can lead to hours of debugging and headaches. Learn the details to avoid them.

Specifications aim to find a common way to interoperate. This is why they need to be precise and unambiguous. But sometimes wrong interpretations occur, leading to implementations that break that desired interoperability. The “case” of the bearer scheme in OAuth 2.0 is one of these situations.

## The Problem with the Bearer Scheme

Imagine your application is calling a protected third-party API and getting an error you don’t understand. Everything worked fine in your test environment when you mocked the API. Why does it fail when you call the actual API? This happens many times, but you have checked everything this time, and your code looks fine. You are passing an access token, which you are sure is valid and not expired. Yet you still have that *500 - Internal Server Error* as response status code or, if you're lucky, *401 - Unauthorized*.

After hours of investigations, you find that you were using “bearer” as the string that qualifies the scheme of your access token while the API expects “Bearer”. That's to say, your HTTP request is like the following:

```http
GET /shop/orders
Host: api.example.com
Authorization: bearer eyJhbGciOiJIUzI1...
```

But the API expects a request like this:

```http
GET /shop/orders
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1...
```

The letter case of "b" in "bearer" is the only difference! 😳

You can’t change the third-party API, of course, so you need to change your application. Is it fair?

## The Discussion on the Bearer Scheme Case

You may think that the situation described in the previous section is an exceptional case. Actually, it's more common than you think (see [this](https://www.googlecloudcommunity.com/gc/Apigee/Case-sensitivity-of-AccessTokenPrefix-is-not-properly-handled/m-p/640501), [this](https://community.auth0.com/t/call-protected-apis-from-a-blazor-web-app/132123/26), [this](https://github.com/golang/oauth2/issues/113), and [this](https://jira.atlassian.com/browse/BCLOUD-14135?focusedId=3315945&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel), just for a few public examples).

There are many discussions about the correct letter case of the bearer scheme identifier in OAuth 2.0. Some say it should be capitalized, while others say it should be case-insensitive. Someone turned from case-insensitive to capitalized just to *honor* the specifications, not because they had any issue ( [here](https://github.com/mauriciovigolo/keycloak-angular/issues/217) and [here](https://github.com/spring-attic/spring-security-oauth/issues/457), for example).

Many argue that the first letter should be capitalized and mention [the specifications](https://datatracker.ietf.org/doc/html/rfc6750#section-2.1):

```
The syntax for Bearer credentials is as follows:
     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token
```

Others claim that it should be case-insensitive and mention [the specifications](https://datatracker.ietf.org/doc/html/rfc6749#section-5.1) as well:

```
token_type
         REQUIRED.  The type of the token issued as described in
         Section 7.1.  Value is case insensitive.
```

It sounds like a philosophical discussion, but it has practical consequences. Who is right?

## Solving the Bearer Scheme Case

The [OAuth 2.0 specifications](https://datatracker.ietf.org/doc/html/rfc6749#section-5.1) clearly state that the token type (i.e., the "bearer" string) must be case insensitive. However, the syntax defined in [the Bearer Token Usage specifications](https://datatracker.ietf.org/doc/html/rfc6750#section-2.1) seems to contradict what the other one established. The [ABNF](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) expression defining the syntax uses "Bearer", the capitalized version:

```
b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
```

Apparently the specifications seem inconsistent. 🤔

However, according to [the specifications of the ABNF grammar](https://www.rfc-editor.org/rfc/rfc5234#page-5):

```
NOTE:
      ABNF strings are case insensitive and the character set for these
      strings is US-ASCII.
   Hence:
         rulename = "abc"
   and:
         rulename = "aBc"
   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
   "ABC".

   To specify a rule that is case sensitive, specify the characters
   individually.

   For example:
         rulename    =  %d97 %d98 %d99
   or
         rulename    =  %d97.98.99
   will match only the string that comprises only the lowercase
   characters, abc.
```

That means that the *case-insensitive party* is right! 🎉

You can write the "bearer" keyword however you like. This is more of a warning to API implementers than client builders because to be truly OAuth 2.0 compliant, they MUST accept any form of "bearer" keyword.

To remove any doubt, the OAuth discussion group added a note to the upcoming [OAuth 2.1 specifications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11#section-5.1.1):

```
As described in Section 2.3 of [RFC5234], the string Bearer is case-insensitive. This means all of the following are valid uses of the Authorization header:

Authorization: Bearer mF_9.B5f-4.1JqM

Authorization: bearer mF_9.B5f-4.1JqM

Authorization: BEARER mF_9.B5f-4.1JqM
```

Keep in mind that even `auThoriZation: bEAReR mF_9.B5f-4.1JqM` must be accepted. The [HTTP header field names are case-insensitive](https://datatracker.ietf.org/doc/html/rfc2616#section-4.2), too. 😜

## Conclusion

Small details that may seem insignificant can sometimes create incompatibility problems, and it may take a lot of time to figure out what's going on and find the correct solution. Writing (and reading) protocol specifications is complex. You must avoid ambiguities in their drafting and have a good technical background to read and implement them correctly.

I hope that this brief digression into the details of the OAuth specifications will be helpful to you and save you hours of debugging when an API is a little reluctant to accept creative ways of writing "bearer". 😇


The Curious “Case” of the Bearer Scheme

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

A step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift and integrated with Auth0.

Calling a Protected API from an iOS Swift App

A step-by-step guide to leveraging OAuth 2.0 Refresh Tokens in an iOS app built with Swift and integrated with Auth0.

Using a Refresh Token in an iOS Swift App

jimena-garbarino

Jimena is an experienced result and value-oriented programmer with a strong engineering background. She excels with Ruby on Rails, Java, and Scrum development. She has worked in web development for 10+ years in many industries and has a master's degree in software engineering from Universidad de Buenos Aires.

Spring Cloud Developer

Jimena Garbarino

Learn how to use Spring Boot, Java, and Auth0 to secure a feature-complete API by implementing authorization in Spring Boot with Auth0.

Add Security and Authorization to a Java Spring Boot API

Let’s explore the latest security enhancements in the OAuth 2.0 specification.

OAuth 2.0 is now widely adopted, but some security concerns remain. Recently, two new specifications were released to improve OAuth 2.0 security and address some of these concerns: *Demonstrating Proof of Possession* (DPoP) and *Step-Up Authentication Challenge Protocol*. Let’s take a high-level look at them to understand how they work.

## Demonstrating Proof of Possession (DPoP)

The most popular artifact associated with OAuth 2.0 is the access token. This token, as well as the refresh token, is a **bearer token**, and [there is a specification on how to use it](https://datatracker.ietf.org/doc/html/rfc6750). As mentioned in that specification, a fundamental feature of a bearer token is "that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can."

While this feature simplifies the token management, it raises some security concerns. In fact, if a bad actor manages to steal an access token, they can use it without any problem. Therefore, some [security measures](https://datatracker.ietf.org/doc/html/rfc6750#section-5) should be taken to mitigate potential threats.

> Read [this article to learn more about access tokens and how they differ from ID tokens](https://auth0.com/blog/id-token-access-token-what-is-the-difference/).

[Demonstrating Proof of Possession (DPoP)](https://www.rfc-editor.org/rfc/rfc9449) is a mechanism designed to restrict who can use an access or refresh token. With this mechanism, the authorization server issues a token that is bound to the requesting client, so that no one other than that specific client can use the access or refresh token. In other words, a token issued by using DPoP is no longer a bearer token.

### Request a DPoP access token

The client using an access token with DPoP must prove that it is the legitimate recipient of the token. This is done using public key cryptography: the client must prove that it has the private key of the public/private key pair. But let's go in order to understand how DPoP works with a standard OAuth 2.0 flow.

For simplicity, we will use the [Authorization Code flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow), but the same applies to the other flows. The high-level steps are listed below:

1. The user is redirected to the authorization server with a request to initiate the flow.
2. The authorization server authenticates the user and redirects them back to the application with an authorization code.
3. The client application generates a public/private key pair and creates a DPoP proof, which is a JWT containing the public key and the method and URI of the HTTP request where it will be used. This also binds the DPoP proof to a specific HTTP request.
4. The client application sends the authorization code to the authorization server to request an access token. The HTTP request includes the DPoP proof in the `DPoP` header field. The following is an example of access token request with DPoP proof:

```http
POST /token HTTP/1.1 
Host: server.example.com 
Content-Type: application/x-www-form-urlencoded 
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...  
grant_type=authorization_code 
&code=3LgurgEWbtafaqTn2VxkASV 
&redirect_uri=https%3A%2F%2Fapp.example.com 
```

5. The authorization server validates the DPoP proof by checking the signature and the request details (HTTP method and URI). It then generates a hash of the client's public key (JWK thumbprint) and embeds it in the access token. For non-JWT access tokens, the JWK thumbprint can be checked through the [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html). Finally, the authorization server sends the access token with the JWK thumbprint to the client application.

### Use a DPoP access token

When the client application needs to call a protected API, it performs the following steps:

1. The client application creates a new DPoP proof bound to the HTTP request it's about to make.
2. The client sends the access token in the `Authorization` header field of the HTTP request using the `DPoP` scheme. It also provides the DPoP proof in the `DPoP` header field. The following is an API call example with DPoP proof:

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

3. In addition to the standard access token validation, the API also validates the DPoP proof to make sure that this request comes from the intended sender.

While using DPoP provides more security than the simple bearer token, this does not mean that there are no threats to DPoP access tokens. Take a look at [the security considerations in the DPoP specification](https://www.rfc-editor.org/rfc/rfc9449#section-11) to learn more.

> To learn [the details about DPoP, check out this article](https://auth0.com/blog/protect-your-access-tokens-with-dpop/).

## Step-Up Authentication Challenge Protocol

A second security enhancement to OAuth 2.0 has been introduced with the [Step-Up Authentication Challenge Protocol specification](https://www.rfc-editor.org/rfc/rfc9470.html), which has our [Vittorio](https://auth0.com/blog/authors/vittorio-bertocci/) as its author along with [Brian Campbell](https://www.pingidentity.com/en/resources/blog/author/brian-campbell).

This specification adds [Step-Up Authentication](https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/) to OAuth 2.0-protected APIs to enforce stronger authentication requirements when a risky operation is requested by a client. In other words, when a client calls a critical API endpoint, the server checks that the access token meets specific authentication requirements, and if it's doesn't, it returns an error response to the client with directions on what is required.

### The step-up authentication flow

Basically, the high-level flow has the following steps:

1. The client sends a request to a critical API endpoint including the access token.
2. The API endpoint extracts information about user authentication from the access token.
3. If the user authentication information meets the authentication requirements for that endpoint, the request is processed. Otherwise, the API endpoint returns an error response that includes the authentication requirements.
4. The client requests a new access token from the authorization server that meets the authentication requirements.

### The authentication requirements

The specification defines two types of authentication requirements:

- *Authentication Context Class Reference* (ACR): This requirement indicates one or more specific authentication methods. For example, it can specify that Multi-Factor Authentication (MFA) is required.
- *Maximum Authentication Age*: This requirement specifies the elapsed time since the last *active* user authentication. An active user authentication occurs when the user is actively involved, for example by entering a username and password. An implicit authentication due to a still valid authenticated session is not considered an active user authentication.

These requirements are embedded in a JWT access token through the standard `acr` and `auth_time` claims. For non-JWT access tokens, the requirements can be verified through the [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html).

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

## Summary

This article provided a high-level overview of the new specifications released in September 2023 to improve the security of OAuth 2.0. The DPoP specification defines a mechanism to bind an access token to the client application that requested it, overcoming the risks associated with bearer tokens. The Step-up Authentication Challenge Protocol defines a way to request more stringent authentication requirements when accessing a critical resource or requesting a risky operation from a client.

OAuth 2.0 Security Enhancements

alisa-duncan

Alisa Duncan is a Senior Developer Advocate at Okta, a full-stack developer, and a community builder who loves the thrill of learning new things. She is a Google Developer Expert in Angular and organizes coding workshops and community events locally and internationally. Her background is primarily working on enterprise software platforms, and she is a fan of all things TypeScript and JavaScript.

Senior Developer Advocate

Alisa Duncan

OAuth 2.0 provides a more secure model than API keys for machine-to-machine communication. Learn why.

Why You Should Migrate to OAuth 2.0 From API Keys

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

Should developers know Identity protocols like OIDC and OAuth, or should they only rely on high-level abstractions like SDKs?

Do developers need to understand the underlying details of OpenID Connect, OAuth, and other standards to implement authentication and authorization? Maybe yes, maybe no. Let’s explore some different points of view.

## The Hard Journey to Identity

Sooner or later, a developer will have to deal with authentication and authorization, whether they are building a SPA, an API, a mobile app, or a microservice, whether they are using Java, C#, JavaScript, or other programming languages.

Some will probably try to implement a homemade solution because it is, after all, a simple login box 😱. And after overcoming the hurdle of username and password authentication, they face the burden of [single sign-on](https://auth0.com/docs/authenticate/single-sign-on), delegated authorization, [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication), and so on. Perhaps just by trying to build a homemade solution, they will understand the complexity of the problem and look for proven solutions.

As they learn about standards such as [SAML](https://auth0.com/blog/how-saml-authentication-works/), [OIDC](https://auth0.com/docs/authenticate/protocols/openid-connect-protocol), [OAuth](https://auth0.com/docs/authenticate/protocols/oauth), [WebAuthn](https://auth0.com/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn), etc., they will probably realize that they have tried to reinvent the wheel. And most likely, they have not considered scenarios that could compromise the security of their application.

But even if you look at these standards from a high level, you will realize that there are many facets, many different scenarios to consider, several details and nuances.

In summary, sooner or later, developers will learn that Identity management is hard.

## To Know or to Ignore? That Is the Question

Once they understand that following standards is the high road to managing the identity of their application users, developers are at a crossroads:

1. Understand and implement the details of these standards.
2. Use a library or SDK and completely ignore the underlying complexity.

The two options seem divergent: know the details or ignore them altogether. Perhaps they reflect the two approaches that developers can take to deal with standards, not just in the Identity space. The choice may depend on the developer's inclination but also on other factors, such as competencies, available time and budget, and so on.

### Developers don't care...

[Someone has argued](https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect) that "*99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC, or any other security specifications. All they want to do is find the simplest and most straightforward way to support user authentication and authorization in their application. They don’t care about standards, specifications, grant types, JWTs, or scopes and timeouts – all they want to do is log a user in and check to see what permissions they have.*"

That's pretty understandable. As a developer, I want to solve my problem as quickly as possible without getting lost in the details. If I'm developing an e-commerce application, I want to focus on the business logic of my application. I don't want to worry about every technical detail that my application relies on. I don't want to know the little internal details of the framework my application runs on, the necessary compilation steps, or the network infrastructure that it will use. I prefer to use tools that take care of that and abstract the internal behavior. Tools that are accurately built by real experts in their field. After all, that is what we at Auth0 are trying to do: take care of the complexity of Identity and free developers from knowing the details of standards and security issues.

### ...developers do care

On the other hand, there are [those who argue](https://www.scottbrady91.com/oauth/why-developers-do-care-about-oauth-and-openid-connect) that "*there is an appetite from developers to learn more about OAuth and OpenID Connect and how to use them effectively. So maybe it’s a little too much to state that developers don’t care.*"

Well, in my experience, that is also true. I've found a lot of developers trying to understand how to properly use an [access token](https://auth0.com/docs/secure/tokens/access-tokens) and which [OAuth flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) to use in a given scenario, even if they're using a third-party library. And I think that's pretty understandable as well. While I don't want to learn every little detail of the infrastructure my application will run on, I can't ignore it completely. Some features of my application might depend on it to work well.

So, what is the right choice to make when dealing with standards in the Identity management space (and also in other areas)? Know their details or ignore them?

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

## The Third Way

“[Zen and the Art of Motorcycle Maintenance](https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance)” is one of the cult books of the 1970s. It is a kind of philosophical novel in which the author, [Robert M. Pirsig](https://en.wikipedia.org/wiki/Robert_M._Pirsig), explores the concept of quality by interweaving it with his almost-fictional biography and his passion for motorcycles.

### Two types of developers

In one of the book's disquisitions, the main character divides humanity into two types:

- Those who see the world as a complex mechanism to be explored in its inner workings (*classical understanding*).
- Those who see the world primarily in its superficial appearances (*romantic understanding*).

Romantic people are those who ride their motorcycles without worrying about how they work. They are not interested in the mechanics of the drivetrain or the ignition or the lubrication system. If their motorcycle breaks down, they take it to the mechanic. And they hardly hear in advance that something is going to break down.

Classical people are those who feel their motorcycle. When they ride it, they hear every little noise, they imagine the movement of the chain, they are one with their means of transportation. They feel when something is about to go wrong because they know every little part of their bike and prefer to fix it themselves.

These two categories of people also apply to developers, in my opinion. Romantic developers don't care about the underlying technology or standard. They want to use a library that simplifies their lives and gets right to the point. Classical developers, on the other hand, want to know what happens inside a library: what technology, standard, and algorithm it uses. Classical developers are the traditional hackers, the ones who get their hands dirty with grease to fix or customize the engine of their motorcycle.

Maybe the choice between the two options for dealing with Identity management is driven by these two developer personalities. And perhaps each of you can identify with one of these two profiles.

<include src="BigQuote" quoteText="Although motorcycle riding is romantic, motorcycle maintenance is purely classic." quoteAuthor="R. M. Pirsig" />

### In medio stat virtus

Starting from a *classical* position, the protagonist realizes that virtue lies in the middle, just as the Latins used to say (*in medio stat virtus*). And virtue, excellence, quality is what he is looking for: what the ancient Greeks called *areté* and Eastern cultures call *Dharma*.

While each developer tends to use a romantic or classical approach to the Identity management problem, based on their personal nature, I think that each of the two positions should only be a starting point.

If Identity management is not your business, it is not cost-effective to implement standards from scratch and take care of all the details. Standards evolve, as do scenarios, best practices, etc. If your core business is not Identity management, implementing OIDC, OAuth, and the other standards may be too expensive and risky for your project.

On the other hand, simply using a library or SDK and ignoring what lies beneath it cannot last long. It can be frustrating when problems occur and you have no idea what is going on. You don't know if the problem depends on your code, your configuration, your library, the environment your application is running in. Understanding at least at a high level how the library you are using works and what standards it uses can help you at least to narrow down the area of investigation when problems occur.

In summary, I think every developer has their own starting point for dealing with problems. But whether you decide to do everything yourself based on standards or prefer to ignore everything under a library, in either case, it will impact the cost of your application.

I think the best solution is to get a medium level of expertise in technologies and standards so that you can at least choose your library with knowledge. What do we call this type of developer? The *pragmatic developer*?

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

## What Auth0 Offers

Whether you are a romantic or classical developer, Auth0 helps you integrate authentication and authorization into your applications by letting you use the approach you prefer.

You have [SDKs and libraries](https://auth0.com/docs/libraries) that abstract the complexity of Identity management, but you are not locked into using our libraries. Your choice is free. But you can look into [our code](https://github.com/auth0) and contribute.

You also have [documentation on standards](https://auth0.com/docs/authenticate/protocols), [guides](https://developer.auth0.com/resources/guides) specific to your favorite framework, [code samples](https://developer.auth0.com/resources/code-samples), [videos](https://www.youtube.com/oktadev), and a [community](https://community.auth0.com/) to share what you've learned.

You can choose your preferred path to becoming a *pragmatic* developer by taking advantage of the resources Auth0 provides.

What kind of developer are you? Are you romantic or classical? Are you aiming to become a pragmatic developer? How can we help you? Leave your comments below.


Zen and the Art of Identity Management

amin-abbaspour

G'day. I look after Professional Services in APAC. I'm passionate about helping customers build and secure their applications and get the best value out of their investment with Auth0. Besides work, I love spending time with my kids, Ryan and Adeline, as well as reading, weightlifting and watching NRL (National Rugby League).

Lead Solutions Architect

Amin Abbaspour

Learn how to add user authentication to Flutter apps using OAuth 2.0 and OpenID Connect.

Get Started with Flutter Authentication

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. 

Developer Advocate

Matt Raible

Use JHipster to build a photo-sharing app for web and mobile that has a React front-end with OIDC authentication and a Spring Boot back-end with OAuth2 authorization.

Integrate React Native and Spring Boot Securely

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Learn how to secure your Electron applications using standards like OpenID Connect and OAuth 2.0.

Securing Electron Applications with OpenID Connect and OAuth 2.0

rinor-maloku

Rinor ([@rinormaloku](https://twitter.com/rinormaloku)) is an engineer at [Solo.io](http://solo.io/) working on application-aware networking solutions. He co-authored the book [Istio in Action](https://www.manning.com/books/istio-in-action?utm_source=rinor&utm_medium=affiliate&utm_campaign=book_posta2_istio_9_30_18&a_aid=rinor&a_bid=9f6a70f3) with Christian Posta ([@christianposta](https://twitter.com/christianposta)), and blogs about best practices on [his page](https://rinormaloku.com/).

Previously, he worked at Red Hat, where he built middleware software that enabled teams to ensure the high availability of their services.

Rinor Maloku

Learn how Istio secures service-to-service traffic for your Kubernetes clusters and how to integrate with Auth0 for securing end-user traffic.

Authenticating and Authorizing end-users with Istio and Auth0

adam-mcgrath

I've been working as an Engineer on the web for over 20 years at companies including the BBC, Google and IG. At Auth0, I build and maintain our JavaScript SDKs for servers and browsers.

SDK Engineer

Adam McGrath

Learn how the OAuth 2.0 Express SDK released by Auth0 makes protecting your Express API easier.

Auth0 has released [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer), a new [Express](https://expressjs.com/) SDK that makes it super easy to protect APIs with JWT Bearer Tokens. Let's take an overview of its features.

## Why a New Express SDK?

Auth0’s previous advice for protecting Express APIs was with a combination of three SDKs: [express-jwt](https://github.com/auth0/express-jwt), [express-jwt-authz](https://github.com/auth0/express-jwt-authz), and [jwks-rsa](https://github.com/auth0/node-jwks-rsa). And whilst these work well and are popular SDKs, we felt the developer experience could be improved.

We first wanted to simplify the process of protecting an Express API by reducing the number of dependencies from three to one. This also reduces the install size from ~2 MB to ~500 KB. You can see the benefit by comparing our [QuickStart](https://auth0.com/docs/quickstart/backend/nodejs) before and after implementing the new SDK, as shown in the following screenshot:

![SDK code lines comparison](https://images.ctfassets.net/23aumh6u8s0i/3Mkzs9yeeOboyJkwJIR9Pb/2518cadc35f2e378edbb5cb925f69026/express-sdk-comparison.jpg)

We also wanted to teach the developer community how to protect their APIs with authorization standards like OAuth2.0 rather than a collection of libraries representing token formats, algorithms, and industry abbreviations (`jwt`, `jwks`, `rsa`, and `authz`).

This is why the project's first incarnation, [express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer), was released experimentally to support our excellent [Identity Labs](https://auth0.com/docs/identity-labs/identity-lab-2-calling-api) series ([express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer) will now be deprecated in favor of [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer)).

## The Role of Standards

[express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) protects Express APIs using a combination of the well-established [OAuth2 Bearer Token Usage spec](https://datatracker.ietf.org/doc/html/rfc6750) and the new specification of [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068).

While there’s always been a clear path for developers to acquire an Access Token from a request using the Bearer Token Usage spec, they’ve relied on best practice and industry convention when determining how to verify their authenticity.

With [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens spec](https://datatracker.ietf.org/doc/html/rfc9068), they are able to leverage new standards to consume Access Token JWTs in an interoperable manner. [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) partially implements the JWT Profile for OAuth 2.0 Access Tokens specification. It implements the full specification when you enable the `strict` option. Also, it is deeply customizable so that you can use it across a broad range of Identity Providers.

## Protect an Express API with JWT Bearer Tokens

[express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) uses a similar mechanism to [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) to configure itself, so it’s easy to set up with minimal effort. In just a few lines of code, you can easily add it to your API to protect it with Access Tokens issued by Auth0, for example.

To easily protect your Express API with Auth0, start by installing the SDK using npm or yarn, as in the following example:

```bash
npm install express-oauth2-jwt-bearer
```

You can initialize the SDK in code or via environment variables. For the latter, the minimal `.env` file would look like the following:

```bash
ISSUER_BASE_URL=https://<YOUR_TENANT>.auth0.com
AUDIENCE=<YOUR_API_IDENTIFIER>
```

Replace `<YOUR_TENANT>` and `<YOUR_API_IDENTIFIER>` with the values of your Auth0 tenant name and API identifier that you’ll find in the [Auth0 Dashboard](https://manage.auth0.com/). 

Then add the [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) middleware to your API like so:

```javascript
const express = require('express');
const { auth } = require('express-oauth2-jwt-bearer');
require('dotenv').config(); // Load the .env variables

const app = express();
app.use(auth());

app.get('/api/private', (req, res) => {
  res.json({ message: `Hello ${req.auth.payload.sub}!` });
});

app.listen(3000, () => console.log('listening at http://localhost:3000'))
```

You can then start your API and test it using curl:

```bash
curl http://localhost:3000/api/private \
--header 'Authorization: Bearer ${YOUR_JWT_ACCESS_TOKEN}'
```

If you’re wondering where to get an Access Token from, you can get one for testing purposes from the Test tab of your [API configuration in the Auth0 Dashboard](https://manage.auth0.com/#/apis), as shown in the following picture:

![Copy access token from Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/785NRBn9KBkiML9UF3NGO5/bcd2954c29af6637f783426e7b89ed7c/copy-access-token.png)

Check out [express-openid-connect](https://github.com/auth0/express-openid-connect) to see an example of how to [programmatically obtain an Access Token to call external APIs](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#4-obtaining-access-tokens-to-call-external-apis).

## Checking for Required Scopes

If you want to additionally check the Access Token’s scopes for a specific route you can use the `requiredScopes` middleware, as shown below:

```javascript
const express = require('express');
const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');
require('dotenv').config();

const app = express();
const checkJwt = auth();

app.get('/api/private-scoped', checkJwt, requiredScopes('read:msg'), (req, res) => {
  res.json({
    message: 'You need to be authenticated and have a scope of read:messages to see this.'
  });
});
```

You can also check custom claims in the Access Token using [claimCheck](https://auth0.github.io/node-oauth2-jwt-bearer#claimcheck), [claimEquals](https://auth0.github.io/node-oauth2-jwt-bearer#claimequals), and [claimIncludes](https://auth0.github.io/node-oauth2-jwt-bearer#claimincludes) (see [the docs for the full API](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer#api-documentation)).

## Under the Hood

[express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer) is a small [Express](https://expressjs.com/) wrapper around two framework agnostic packages:

- [oauth2-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/oauth2-bearer): it gets Bearer tokens from a request and issues errors per the [Bearer Token Usage spec](https://tools.ietf.org/html/rfc6750).
- [access-token-jwt](https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/access-token-jwt): it verifies and decodes Access Token JWTs following the [JWT Profile for OAuth 2.0 Access Tokens spec](https://datatracker.ietf.org/doc/html/rfc9068) using the [jose](https://github.com/panva/jose) library.

The following diagram shows the dependencies among these packages:

![OAuth2 Express SDK dependency graph](https://images.ctfassets.net/23aumh6u8s0i/78D0oQvCSHj5SUTANEFihw/31924abc24a7841cbb73db1afd297f83/oauth2-express-libraries-dependency.png)

## What’s Happening to `express-jwt`, `express-jwt-authz`, and `jwks-rsa`?

[express-jwt](https://github.com/auth0/express-jwt), [express-jwt-authz](https://github.com/auth0/express-jwt-authz) and [jwks-rsa](https://github.com/auth0/node-jwks-rsa) are well used and loved by many Auth0 customers and remain fully supported. There’s no need to rush to update your existing apps. We will keep fixing bugs and patching them. We plan to stop adding new features to these SDKs, though, and the bar for the bugs we fix will be tuned accordingly.

If you are about to start a new Express API project, we recommend using [express-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/tree/main/packages/express-oauth2-jwt-bearer), as it will be our target for all innovation for authorization on the Node.js platform for the foreseeable future.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## What’s Next

[oauth2-bearer](https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/oauth2-bearer) and [access-token-jwt](https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/access-token-jwt) are as yet unpublished and currently just share space in the [node-oauth2-jwt-bearer](https://github.com/auth0/node-oauth2-jwt-bearer) monorepo. However, you can see how they could easily be used standalone or to create simple wrappers for other Node.js server frameworks like [Koa.js](https://www.simform.com/blog/best-nodejs-frameworks/#Koa), [Nest.js](https://www.simform.com/blog/best-nodejs-frameworks/#Nest), [Hapi.js](https://www.simform.com/blog/best-nodejs-frameworks/#Hapi). You can also use them in a range of serverless platforms, which we’ll be reviewing as part of our roadmap going forward.

If you have feedback or notice any issues hit us up via the [issues list](https://github.com/auth0/node-oauth2-jwt-bearer/issues) or the [Auth0 community](https://community.auth0.com/).

Happy coding!


Introducing the OAuth 2.0 Express SDK for Protecting APIs with JWT Bearer Tokens

Supporting Sign in with Apple on iOS and web apps can be an easy task if you use the right tools.

How to Implement Sign in with Apple Easily on iOS Apps

jenny-obrien

I'm a former business journalist who's fascinated by the intersection of tech and business strategy — in particular how the right solution can transform an idea into reality. I specialize in ROI, data privacy, and identity.

Business Content Manager

Jenny O'Brien

Following Apple’s release of Sign in with Apple and iOS13, Auth0 support coming next week



Using third-party or social login services such as Facebook or Google for app login? Apple’s new App Store Developer Guidelines require that if your app exclusively uses a third-party or social login service to setup or authenticate the user’s primary account, the app [must](https://developer.apple.com/news/?id=06032019j) provide Sign in With Apple for your end-users (existing apps and app updates have until April 2020 to be compliant.)

![Sign In with Apple feature landing page mockup screenshot](https://images.ctfassets.net/23aumh6u8s0i/7mvfWW2HPoJ1fAZzJ5wKNc/6d6b119e6ba2723024e5e2875297d56d/hero)

## Smooth Adoption Expected

Once iOS users complete their initial sign-in, they’ll be able to subsequently sign in using the native bio verification mechanisms built into iOS devices like thumbprints and Face ID. When users can do this instead of having to enter a password, we expect this will quickly become the login path of choice.

## Privacy Play

GDPR sparked a [global shift in data privacy](https://auth0.com/explore/data-privacy/). While organizations are thinking harder about the data they store and where it flows, Apple has realized the need to support end-user choices — which is why SIgn In With Apple allows users to obfuscate their real identity from third-parties including app developers.

So if I use Sign in with Apple, and select “Hide my Email”, application developers will not have any personally identifiable information from my login. The application will only recognize me based on a randomly generated email address from Apple that is uniquely identifiable so that Apple can maintain the correct association. 

This causes a slight problem for application developers who rely on email addresses to associate accounts to actual people. Apple has taken a hard stance on this but it is also evolving its identity practices at a rapid pace. Auth0 has kept up with these recent changes and will be releasing a solution that has been beta-tested with actual customers and end-users next week.

If you need Sign In With Apple to do business and you’re doing it yourself, you’re about to touch code — and then every time Apple makes a change, you’ll need to touch it again to ensure that code is keeping pace. The advantage of Auth0 is that we shield you from every change from Apple or other identity providers. Even adding features like multi-factor authentication can easily be switched on with a toggle.

## What’s Coming Next Week

![Sign-in with Apple Flows](https://images.ctfassets.net/23aumh6u8s0i/4Ir5yzLS6BxzCoIXjg8U1a/95e05a6faf160e091ee3a4afc2981c76/siwa-flows)

The General Availability (GA) of our Sign In With Apple integration will include Native flows and Web flows. Web flows have been in [public beta since June](https://auth0.com/blog/try-sign-in-with-apple-in-your-auth0-apps-today/), enabling customers who want to use Sign In with Apple in web applications to try it out. At Auth0, Sign In With Apple will be an out-of-the-box feature — a simple toggle + minimal code.

![Sign In With Apple Has Been In Public Beta Since June](https://images.ctfassets.net/23aumh6u8s0i/3rMC0k1THr4rYHnQ22y2zx/891a90db2e67aed1b0e233a26713139b/social-connections)

Offloading authentication to Auth0 means touching code when YOU want to make a change, not when your identity provider tells you to. And it means you can quickly comply with Apple’s mandate while leveraging the benefits of Face or Touch ID and eliminate the need for usernames/passwords.

With 1.4 billion iOS devices already in the market and nearly two million apps competing for iOS users’ attention this change could be a big deal — if Auth0 didn’t already have you covered.


Ready for 1.4 Billion iOS Devices?

What is the difference between permissions, privileges, and scopes in the authorization context? Let's find out together.

Access control is a complex thing. It involves users, resources, and applications, and you have to set it up properly to prevent bad surprises. However, setting up access control is not just a matter of writing code or configuring a system. It includes (or better, it relies on) understanding a few basic concepts. Things can get even more complicated when delegated authorization comes into the picture, such as when using OAuth.

In this context, three core concepts are usually misunderstood and confused: **permissions**, **privileges**, and **scopes**. Let's try to go to the basics to better understand these concepts and their relationship.

By the way, here is a video version of this article:

<AmpContent>
<amp-youtube
    data-videoid="z2Ma0ZsEF7Y"
    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/z2Ma0ZsEF7Y'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

## Actors of Access Control

Consider a scenario with the following actors:

- The **user**, the entity that wants to perform an action on an object.
- The **resource**, the object that a user wants to use.
- The **application**, the software that mediates the interaction between the user and the resource.

In this scenario, **access control is the selective restriction of access to a resource**. It determines who can do what on a resource. The relationship between the three actors described above contributes to the complexity of access control, as we will see in a moment.

## What Are Permissions?

Usually, you have a clear understanding of what a permission is. Commonly, you say that you have the permission to drive your car, load stuff in its trunk compartment, inspect its hood, clean it, sell it, and so on.

These common activities make you think that a permission is something related to you, the user. Actually, in the computer security context, a permission is something related to an object, to a resource, not to the user of that resource.

**A permission is a declaration of an action that can be executed on a resource**. It describes intrinsic properties of resources, which exist independently of the user. In the scenarios depicted above, driving and filling the trunk are actions you can do with your car: they are permissions attached to your car. The same happens with the action of accessing your computer, reading your emails, and so on. They all are permissions on those resources.

I know, that looks weird and a bit pedantic, even philosophical in some ways. But it is fundamental to accurately define this concept to understand the rest.

## What Are Privileges?

If permissions are bound to the resource, how can you express the ability to perform an action on that resource? How can you express the fact that someone is authorized to drive their car? What you need are privileges.

Simply put, **privileges are assigned permissions**. When you assign a permission to a user, you are granting them a privilege. If you assign a user the permission to read a document, you are granting them the privilege to read that document. Do you see the subtle difference?

I know. Usually, permissions and privileges are used interchangeably, but technically they have precise and different meanings in the context of computer security.

So, resources expose permissions. Users have privileges.

> For simplicity, we'll talk about privileges assigned to users, but keep in mind that privileges can also be assigned to applications. Consider, for example, an application running without user involvement that needs to access a resource.

## Authorization Scenarios

Once you understand the exact definition of permissions and privileges, we can easily talk about authorization scenarios. I mean, you can easily imagine a scenario where an entity protects a resource, and a user wants to exercise their privilege to use that resource. **The entity that protects the resource is responsible for restricting access to it, i.e., it is doing access control**.

Consider the following example. The concierge of a hotel is the entity that supervises the hotel's rooms (the resources) from unauthorized access. Each room has the ability to accommodate one guest (permission). A customer is assigned one room, so they have the privilege of being accommodated in that room. When the customer goes for a walk and then comes back to the hotel, the concierge checks if actually the customer has been assigned the permission to be accommodated in that room by consulting the booking list. If everything fits, the customer can come in, and we're all happy.

Imagine that one day, while the customer is out, a person shows up at the concierge desk. That person says they were requested by the customer to come into the room to get their briefcase. The concierge doesn't allow them to come in, of course. They need to do their own verifications to confirms what that person is asserting, such as calling the customer on the phone, for example.

However, even after everything is clear, the concierge needs to make sure that person will only do what they came to the hotel to do: take the customer's briefcase. Nothing else. The concierge will likely walk the person to the customer's room and make sure nothing else is done other than what was agreed upon.

The first scenario looks quite straightforward: it reduces the access control to comparing the customer booking data with the hotel's booking list. The second scenario is a bit more complex: it requires an additional check on what the person declares and control on what they are allowed to do.

These two scenarios may seem fictitious, but they have equivalent scenarios in authorization systems. The first scenario corresponds to the situation where a user attempts to access a protected resource for which they have privileges. This is the typical and most known authorization scenario.

The second scenario represents the case in which a third-party application wants to access a protected resource on behalf of a user. This case is known as a delegated authorization scenario.

The delegated authorization scenario is the typical scenario introduced by the [OAuth 2 Authorization Framework](https://auth0.com/docs/protocols/protocol-oauth2). This framework allows a third-party application to operate on a resource on behalf of a user. In other words, the application exercises the user's privilege to use a resource. But how does it happen? How can the application be delegated to access the user’s resource? Here, scopes come into the scene.

## What Are Scopes?

**Scopes enable a mechanism to define what an application can do on behalf of the user**. Recalling the hotel example, taking the customer's briefcase is the scope of the person who introduced themselves to the concierge.

The application requests these scopes to the authorization server, i.e., the server responsible for authorizing the third-party application in the delegated scenario. [Scopes were introduced in OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) and are specific to that authorization framework.

In practical terms, **scopes are strings that represent what the application wants to do on behalf of the user**, as shown in the following authorization request example:

```bash
https://YOUR_DOMAIN/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://YOUR_APP/callback& 
  scope=read:email&   #👈 here is the requested scope
  audience=YOUR_API_AUDIENCE&
  state=YOUR_STATE_VALUE
```

Typically, scopes are permissions of a resource that the application wants to exercise on behalf of the user. In other words, the application wants to exercise user's privileges on a resource such as reading their emails.

Actually, it is not the authorization server that allows the application to exercise the user's privileges. The final word on granting delegated access to the application is the user's own. The user can approve or reject delegated access to their resource with specific scopes by using a consent screen similar to the following:

![Consent screen](https://images.ctfassets.net/23aumh6u8s0i/1TrkMwEcKSR149zd878WEJ/8ae011dc08b89698c0dce24e8ce01e43/consent-screen.png)

You can experience it firsthand by <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">signing up for Auth0</a> and securing an application built with [several supported technologies](https://auth0.com/docs/libraries).

The granted scopes allow the application to access only the user's resources, say the user's emails. Just as the user cannot access other users' emails, the application cannot access other users' emails either. Usually, **the scopes granted to a third-party application are a subset of the permissions granted to the user**.

Keep in mind, however, that an application can request scopes corresponding to privileges that the user doesn't have. And the user can grant them. This may look tricky, but it covers situations where the user doesn't have a given privilege in the moment they grant the scopes to the application, but they will have that privilege when the application exercises that scope. The vice versa can happen too: a user has a given privilege and grants a delegated access for the corresponding scope, but the user loses the privilege when the application tries to exercise its scope. At the end of the day, what is relevant when the application exercises its scopes is the possession of the corresponding privileges by the user at that time. This means that **the application can't do more than the user can do**.

Once the user approves the application's request, the authorization server communicates the granted scopes to the application so that it can access the resource with the limited granted privileges.

## A Complicated Relationship

Now you have a clearer picture of what permissions, privileges, and scopes are. Unfortunately, this may not be enough. In fact, these items are strictly related, and often this relationship gets confusing. Let's try to clarify the most common misunderstandings.

### Scopes and privileges

Often, developers think that scopes are application's privileges. After all, the user granted their consent to use them. However, they usually miss a little detail: applications are authorized to exercise those privileges **on behalf of the user**. If the user doesn't have a privilege, the application cannot exercise it.

This means that, on the resource side, **users' privileges must be checked even in the presence of granted scopes**. Remember that, in a delegated authorization scenario, the application may act on behalf of the user even when the user is not logged in. If the user no longer has those privileges between their consent and the exercise by the application, the application must be prevented from exercising its delegated access. This should clarify why **scopes should not be considered application's privileges**.

These may look like philosophical issues, but they have practical implications. Check out [this article on the nature of scopes](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/) to learn more about this.

### Scopes and permissions

Once you know what permissions, privileges, and scopes are, you might assume that there is a natural mapping between permissions and scopes. In other words, if a resource has permissions A and B, the scopes X and Y respectively will exist to allow an application to exercise those permissions on the resource and vice versa. While in most cases permissions are exposed as scopes, this mapping is not strictly correct for a few reasons.

In a delegated scenario, not all the permissions on a resource should necessarily be made available to be requested as scopes. You could reserve some permissions for the user and decide that they are not delegable. For example, you could decide that the permission to delete a document is never delegated to a third-party application.

So you might think that this supposed mapping is not between scopes and permissions but between scopes and privileges. This way, you can't map a scope to a permission not assigned to the user. Actually, this is not accurate either. There are scopes that don't have a match among the resource's permissions or the user's privileges. Consider the `openid` scope defined by [OpenID Connect specifications](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). This scope does not correspond to any permission on a specific user's resource. It is a request for the authorization server to return an ID token as the result of the user's authentication. The same applies to the other [scopes defined by OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims): `profile`, `email`, `address`, and `phone`.

So, you should avoid this unconscious mapping between scopes and permissions.

## Summary

At the end of this journey, you learned the subtle differences between permissions, privileges, and scopes and their mutual relationship. Understanding these concepts and their thin borders will help you build more secure applications. The following picture tries to summarize what you learned in this article:

![Permissions, privileges and scopes](https://images.ctfassets.net/23aumh6u8s0i/2wSDOXUzAKuCAA0rw79Fx8/8f66ad24881e3da2a73249a2a7b05e27/permissions-privileges-scopes.jpg)


Permissions, Privileges, and Scopes

pablo-cibraro

Pablo is an internationally recognized expert and entrepreneur with more than 22 years of experience in designing and implementing large distributed systems with Microsoft technologies and a Connected System MVP. <br>
For the last few years, Pablo has helped numerous Microsoft teams develop tools and frameworks for building service-oriented and web applications with .NET. <br>
Pablo now focuses on technologies that enable developers to build large-scale systems and web applications on the cloud, such as HTML5, Node.js, ASP.NET, Windows Azure and Amazon AWS.

Agilesight Cofounder

Pablo Cibraro

Understand the Backend For Frontend authentication pattern and how it can be implemented in ASP.NET with Auth0.

Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

A first-person account of how modern open identity standards are made

From Idea to Standard: How the JWT Profile for OAuth 2.0 Access Tokens Became RFC9068

Learn what ID and access tokens are and how to correctly use them in the OpenID Connect and OAuth context.

"Let’s use a token to secure this API call. Should I use the ID token or the access token? ​🤔 The ID token looks nicer to me. After all, if I know who the user is, I can make better authorization decisions, right?"

Have you ever found yourself making similar arguments? Choices based on your intuition may sound good, but what looks intuitive is not always correct. In the case of ID and access tokens, they have clear and well-defined purposes, so you should use them based on that. Using the wrong token can result in your solution being insecure.

"What changes after all? They are just tokens. I can use them as I see fit. What’s the worst that could happen?"

Let’s take a closer look at these two types of tokens to better understand their role in authentication and authorization processes.

If you prefer, you can also watch this video on the same topic:

<AmpContent>
<amp-youtube
    data-videoid="M4JIvUIE17c"
    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/M4JIvUIE17c'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>


## What Is an ID Token?

An ID token is an artifact that proves that **the user has been authenticated**. It was introduced by [OpenID Connect](https://openid.net/connect/) (OIDC), an open standard for authentication used by many identity providers such as Google, Facebook, and, of course, Auth0. Check out [this document for more details on OpenID Connect](https://auth0.com/docs/protocols/openid-connect-protocol). Let's take a quick look at the problem OIDC wants to resolve.

Consider the following diagram:

![ID token scenario](https://images.ctfassets.net/23aumh6u8s0i/QAHEJgeyGWL3otdWNnWNT/2f3dcdfb6ef72ae91c48d9cd180028dd/id-token-scenario.jpg)


Here, a user with their browser authenticates against an OpenID provider and gets access to a web application. The result of that authentication process based on OpenID Connect is the ID token, which is passed to the application as proof that the user has been authenticated.

This provides a very basic idea of what an ID token is: proof of the user's authentication. Let’s see some other details.

An ID token is **encoded as a JSON Web Token** (JWT), a standard format that allows your application to easily inspect its content, and make sure it comes from the expected issuer and that no one else changed it. If you want to learn more about JWTs, check out [The JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook).

To put it simply, an example of ID token looks like this:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw
```

Of course, this isn't readable to the human eye, so you have to decode it to see what content the JWT holds.  By the way, the ID token is not encrypted but just [Base 64](https://en.wikipedia.org/wiki/Base64) encoded. You can use one of the [many available libraries](https://jwt.io/#libraries-io) to decode it, or you can examine it yourself with the [jwt.io](https://jwt.io/?id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibmFtZSI6IkphbmUgRG9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9.bql-jxlG9B_bielkqOnjTY9Di9FillFb6IMQINXoYsw) debugger.

Without going deeper into the details, the relevant information carried by the ID token above looks like the following:

```json
{ 
  "iss": "http://my-domain.auth0.com", 
  "sub": "auth0|123456", 
  "aud": "1234abcdef", 
  "exp": 1311281970, 
  "iat": 1311280970, 
  "name": "Jane Doe", 
  "given_name": "Jane", 
  "family_name": "Doe"
}
```

These JSON properties are called **claims**, and they are **declarations about the user** and the token itself. The claims about the user define the user’s identity.

> Actually, the OpenID Connect specifications don't require the ID token to have user's claims. In its minimal structure, it has no data about the user; just info about the authentication operation.

One important claim is the `aud` claim. This claim defines the **audience** of the token, i.e., the web application that is meant to be **the final recipient of the token**. In the case of the ID token, its value is the client ID of the application that should consume the token.

> Remember this small detail about the audience claim because it will help you better understand what its correct use is later on.

The ID token may have additional information about the user, such as their email address, picture, birthday, and so on.

Finally, maybe the most important thing: the ID token is signed by the issuer with its private key. This guarantees you the origin of the token and ensures that it has not been tampered with. You can verify these things by [using the issuer's public key](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/).

Cool! Now you know what an ID token is. But what can you do with an ID token?

First, it demonstrates that the user has been authenticated by an entity you trust (the OpenID provider) and so **you can trust the claims about their identity**.

Also, your application can **personalize the user’s experience** by using the claims about the user that are included in the ID token. For example, you can show their name on the UI, or display a "best wishes" message on their birthday. The fun part is that you don’t need to make additional requests, so you may get **a little gain in performance** for your application.

## What Is an Access Token?

Now that you know what an ID token is, let’s try to understand what an access token is.

Let's start by depicting the scenario where the access token fits:

![Access token scenario](https://images.ctfassets.net/23aumh6u8s0i/5DLgYCLtVgxLPT0Nqco53r/ec4ccd3c9d33734a38ef85d01dfe6b0e/access-token-scenario.jpg)


In the diagram above, a **client application** wants to access a **resource**, e.g., an API or anything else which is protected from unauthorized access. The other two elements in that diagram are the user, which is the **owner** of the resource, and the **authorization server**. In this scenario, the access token is the  artifact that **allows the client application to access the user's resource**. It is issued by the authorization server after successfully authenticating the user and obtaining their consent.

In the [OAuth 2](https://auth0.com/docs/protocols/protocol-oauth2) context, the access token **allows a client application to access a specific resource to perform specific actions on behalf of the user**. That is what is known as a **delegated authorization scenario**: the user delegates a client application to access a resource on their behalf. That means, for example, that you can authorize your LinkedIn app to access Twitter’s API on your behalf to cross-post on both social platforms. Keep in mind that you only authorize LinkedIn to publish your posts on Twitter. You don't authorize it to delete them or change your profile’s data or do other things, too. This limitation is very important in a delegated authorization scenario and is achieved through scopes. **[Scopes](https://auth0.com/docs/scopes)** are a mechanism that allows the user to authorize a third-party application to **perform only specific operations**.

Of course, the API receiving the access token must be sure that it actually is a valid token issued by the authorization server that it trusts and make authorization decisions based on the information associated with it. In other words, the API needs to somehow use that token in order to authorize the client application to perform the desired operation on the resource.

How the access token should be used in order to make authorization decisions depends on many factors: the overall system architecture, the token format, etc. For example, an access token could be a key that allows the API to retrieve the needed information from a database shared with the authorization server, or it can directly contain the needed information in an encoded format. This means that **understanding how to retrieve the needed information to make authorization decisions is an agreement between the authorization server and the resource server**, i.e., the API.

[OAuth 2 core specifications](https://datatracker.ietf.org/doc/html/rfc6749) say nothing about the access token format. It **can be a string in any format**. A common format used for access tokens is JWT, and [a standard structure is available](https://datatracker.ietf.org/doc/html/rfc9068). However, this doesn’t mean that access tokens should be in that format.

Alright! Now you know what an ID token and an access token are. 🎉 So you are ready to use them without any fear of making mistakes. But, wait. I do not see you convinced. 🤔 Maybe you need some other information. Ok. So, let’s see what these tokens are _not_ suitable for.

## What Is an ID Token NOT Suitable For?

One of the most common mistakes developers make with an ID token is using it to call an API.

As said above, an ID token proves that a user has been authenticated. In a first-party scenario, i.e. in a scenario where the client and the API are both controlled by you, you may decide that your ID token is good to make authorization decisions: maybe all you need to know is the user identity.

However, even in this scenario, the security of your application, consisting of the client and the API, may be at risk. In fact, **there is no mechanism that ties the ID token to the client-API channel**. If an attacker manages to steal your ID token, they can use it to call your API like a legitimate client.

For the access token, on the other hand, there is [a set of techniques, collectively known as *sender constraint*](https://auth0.com/blog/identity-unlocked-explained-episode-1/), that allow you to bind an access token to a specific sender. This guarantees that even if an attacker steals an access token, they can’t use it to access your API since the token is bound to the client that originally requested it.

In a delegated authorization scenario where a third-party client wants to call your API, **you must not use an ID token to call the API**. In addition to the lack of mechanisms to bind it to the client, there are several other reasons not to do this.

If your API accepts an ID token as an authorization token, to begin with, you are ignoring the intended recipient stated by the audience claim. That claim says that it is meant for your client application, not for the resource server (i.e., the API).

You may think this is just a formality, but **there are security implications** here.

First of all, among other validation checks, your API shouldn’t accept a token that is not meant for it. If it does, its security is at risk. In fact, if your API doesn't care if a token is meant for it, an ID token stolen from any client application can be used to access your API. Of course, checking the audience is just one of [the checks that your API should do to prevent unauthorized access](https://auth0.com/docs/security/tokens/access-tokens/validate-access-tokens).

In addition, your ID token will not have granted [scopes](https://auth0.com/docs/scopes) (I know, this is another pain point). As said before, scopes allow the user to restrict the operations your client application can do on their behalf. Those scopes are associated with the access token so that your API knows what the client application can do and what it can't do. If your client application uses an ID token to call the API, you ignore this feature and potentially allow the application to perform actions that the user has not authorized.

## What Is an Access Token NOT Suitable For?

On the access token side, it was conceived to demonstrate that you are authorized to access a resource, e.g., to call an API.

Your client application should use it only for this reason. In other words, the access token **should not be inspected by the client application**. It is intended for the resource server, and your client application should treat access tokens as opaque strings, that is, strings with no specific meaning. Even if you know the access token format, you shouldn’t try to interpret its content in your client application. As said, the access token format is an agreement between the authorization server and the resource server, and the client application should not intrude. Think of what can happen if one day the access token format changes. If your client code was inspecting that access token, now it will break unexpectedly.

## A Quick Recap

The confusion over the use of ID and access tokens is very common, and it can be difficult to wrap your head around the differences. Maybe it mostly derives from not having a clear understanding of the different goals of each artifact as defined by the OAuth and OpenID Connect specifications. Also, understanding the scenarios where those artifacts were originally meant to operate has an important role in preventing confusion on their use. Nevertheless, I hope this topic is a little more clear now.

To recap, here is a quick summary of what you learned about what you can and can’t do with ID and access tokens:

![ID token vs access token](https://images.ctfassets.net/23aumh6u8s0i/2y2MCTq87UqQ1uzCJsl4M/c6f127f738f0d13017ff47544958d880/id-token-vs-access-token.jpg)

If you want to see ID and access tokens in action, <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a> and start to add authentication and authorization to your applications in minutes with [your preferred programming language and framework](https://auth0.com/docs/libraries).

ID Token and Access Token: What's the Difference?

ben-dechrai

A technologist with a staunch focus on security and privacy. I love helping developers find the joy of experimentation, and designing unconventional solutions for the purposes of learning something new.

Ben Dechrai

Configure MongoDB as an Auth0 custom database to simplify user migration or just add OAuth/Open ID Connect.



Configuring MongoDB as an Auth0 custom database can simplify your user migration process, or even just add an OAuth and OpenID Connect layer on top of your existing database of users. Whatever your reason, let's step through the process of connecting Auth0 to MongoDB.

<div style="text-align: center; font-style: italic">This article is also available in video format</div>
<AmpContent>
<amp-youtube
    data-videoid="TXnDFU4sG0A"
    layout="responsive"
    width="480" height="270">
</amp-youtube>

</AmpContent>

<NonAmpContent>

<iframe width="560" height="315" src="https://www.youtube.com/embed/TXnDFU4sG0A" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

</NonAmpContent>

## Enabling Custom Databases

Don't already have an Auth0 account yet? <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">**Sign up for free today!**</a>

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

Once you're logged in, head to the [Database Connections](https://manage.auth0.com/#/connections/database) page, and click on the **Create DB Connection** button.

Give this database configuration a meaningful name, click the **Create** button, and then switch to the **Custom Database** tab.

![Creating a new Custom Database in Auth0](https://images.ctfassets.net/23aumh6u8s0i/496MewuOZuw98e3bzPjxYP/39e421381b97dc89bb189cb35496095c/02-enable-custom-database)

On this screen, you can enable the **Use my own database** option and define the JavaScript that will run when the following events are triggered:

* **Login** - executed each time a user attempts to login, to validate the authenticity of the user against a MongoDB record;
* **Create** - executed when the user signs up, to create a record in MongoDB;
* **Verify** - executed after a user signs up and follows the email "verification" link, to set a corresponding flag in MongoDB;
* **Change Password** - executed when the user changes their password, or the reset email was sent and the user follows the "change password" link, to update a record in MongoDB;
* **Get User** - executed to determine the current state of existence of a user, which returns a matching MongoDB record if any, without requiring the user's credentials; and
* **Delete** - executed when a user is deleted, to deactivate or delete the respective MongoDB record.

For each of these scripts, you'll see a **Templates** drop-down above the code editor, and MongoDB is one of the options that come out of the box. You'll come back to this later.

![Using a predefined custom database script template](https://images.ctfassets.net/23aumh6u8s0i/1tHHzz76Yla76NbwM0Y7H0/b90b814d25bb6eb9600156ee00c82d32/02-custom-db-script-editor)

## Setting up a MongoDB Cluster

Before you do that, though, set up your MongoDB instance. Assuming you already have an account at [https://mongodb.com/](https://mongodb.com/), head to your dashboard and go to the **Projects** tab. Then create a new project, and in that project, create a new cluster. The free, shared clusters with the default settings are sufficient for our purposes, but you might want to consider one of the paid options if their features better suit your needs.

>This guide should also work fine if you're using an existing database, but you might need to tweak some of the upcoming instructions to your specific circumstances.

Once the cluster is built, which can take up to three minutes, you need some connection details to use in the scripts back in the Auth0 dashboard.

Click on the **Connect** button, and configure the IP Addresses that can connect to your cluster. If you look back in the Auth0 interface, you'll see a list of IP addresses under the code editors for any of your scripts. Add these in using the **Add a different IP Address** button in MongoDB.

![Finding Auth0's IP addresses for allowing access to MongoDB](https://images.ctfassets.net/23aumh6u8s0i/5OM015On791Fbrcfx6VvvV/52cad1ca1e118ceb94547c93ecf8a6cf/auth0-ip-addresses-closeup)

The next thing you need to do is define a user that's allowed to connect to the system. Choose a username and sufficiently strong password, and continue.

Finally, you get to choose a connection method. The scripts you're configuring in Auth0 fall under the **Connect your Application** scenario, and clicking on this will reveal the connection string you need to use in your scripts.

![Obtaining connection details from MongoDB](https://images.ctfassets.net/23aumh6u8s0i/4cSocZbkMPCMFOggiaXyT0/6ec4e02b4cb76cd64d09197d1d4964b7/03-mongodb-connection-details-window)

## Defining the Auth0 Custom Database Scripts

Copy the connection string from MongoDB, and switch back to the Auth0 interface. Select to edit the **Login** script, and choose MongoDB from the templates drop-down.

You'll see the following line in the code:

``` javascript  
const client = new MongoClient('mongodb://user:pass@localhost');
```

Replace the entire connection string with the value you just copied from MongoDB, and you'll see something that looks like:

``` javascript  
const client = new MongoClient('mongodb+srv://user:<password>@xxx.mongodb.net/<dbname>?...');
```

You can remove `<dbname>` from this connection string, because it's already specified later in the script.

``` javascript  
const client = new MongoClient('mongodb+srv://user:<password>@xxx.mongodb.net/?...');
```

Now you need to replace `<password>` with the actual password, but you know it's bad practice to keep these in the scripts.

There's a solution for this, though. Under the script editor, you'll see a **Settings** section that allows you to store data exposed to all the scripts via environment variables. This is a much more secure way to store the password.

Add a key/value pair with the key `MONGO_PASSWORD` and the password you provided when configuring access in MongoDB.

![Storing credentials securely for use in Auth0 custom database scripts](https://images.ctfassets.net/23aumh6u8s0i/2qRxG3H9r2JrR8oAkKuhUn/b2c23edc2154e7482165fc8623eacc53/04-custom-db-script-settings-window)

You'll then be able to copy the **Code Snippet** from the new entry, and use that in your connection string instead:

``` javascript  
const client = new MongoClient('mongodb+srv://user:' + configuration.MONGO_PASSWORD + '@xxx.mongodb.net/<dbname>?...');
```

## Creating the Mongodb Database to Store Users In

The next thing you'll need to do is create a database and collection in MongoDB. Jumping to the MongoDB interface again, close the dialog box containing the connection information and click on the **Collections** button.

On the Collections page, click the **Add My Own Data** button, and provide the database name `db-name` and the collection name `users` and click **Create** to continue.

![Creating a database and collection in MongoDB](https://images.ctfassets.net/23aumh6u8s0i/2FGBFo0xCA7WIuAv1rBeTj/d9fc99f7483d0adc4d969845c2aed954/05-create-db-and-collection-window)

That's it for this step! The database is ready, and you just need to finish up the Auth0 custom database configuration.

## Finalizing the Auth0 Custom Database Scripts

Switch back to the Auth0 interface again and you should see the **Login** script editor. The script is already connecting to the `db-name` database and pulling users out of the `users` collection. If you used other names in the previous step, make sure you update the code in all the scripts on around lines 8 to 10:

![Code showing database and connection name definitions](https://images.ctfassets.net/23aumh6u8s0i/J3utFvV9KFRfeUuy2Vwax/d2cb5e1ef195473184403244a1daf165/script-configure-db-and-connection-names)

Before you move on, copy line 4 into your clipboard, which instantiates the client with the correct connection string.

To configure the other scripts, simply iterate through each one, select MongoDB from the templates dropdown, and replace the client instantiation line with the one you just copied from the **Login** script.

There are just two more little changes you'll need to make to make everything work.

By default, each new user won't have an `email_verified` flag at all, so setting it later won't work. To remedy this, head back to the **Create** script, and find the line that defines the value of `user.password`:

``` javascript  
user.password = hash
```

This is probably line 24. Directly after this line, add the following:

``` javascript  
user.email_verified = false
```

Now, when someone creates a new account, the new user object in MongoDB will be created with the `email_verified` flag as false.

The second change is to the **Delete** script. On around line 11, you'll see the line that tells MongoDB to delete the user:

``` javascript  
users.remove({ _id: id }, function (err) {
```

The issue here is that the value of `id` is the user's email address, whereas the `_id` in MongoDB is an object ID. Change the key in this filter to `email` in order to correctly identify the MongoDB record to be removed:

``` javascript  
users.remove({ email: id }, function (err) {
```

Clicking on the **Save** button above the code editor will save all changes in all the scripts. So hit that, and you're done!

## Testing the Database

You can use the **Try** button to test each of these scripts out now. If you're starting with a new database, try the **Create** script first, and go from there.

![Testing the Auth0 custom database by creating a new user](https://images.ctfassets.net/23aumh6u8s0i/1hc21gDm65ROXTXVQstdYB/8becfaa89d9735532be3d1c449a9a208/06-user-created)

If you're using an existing database, you can try logging in with an existing user's credentials. If you're having authentication issues, make sure the **Login** script is using the same hashing mechanism as the code that generated these users in the first place.

And if you're having trouble, head over to our Community Forum and drop your request below.


Connecting Auth0 to MongoDB

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Sam Bellen

Learn about refresh tokens and how they help developers balance security and usability in their applications.

What Are Refresh Tokens and How to Use Them Securely

Learn how to develop RESTful APIs with Node.js and Express while securing it with Auth0.

Node.js and Express Tutorial: Building and Securing RESTful APIs

## What is The OAuth 2 Game?

The OAuth 2 game is a fun and easy way to learn about how to use OAuth to protect the most common types of applications.

The OAuth 2 specification lists different ways of obtaining access tokens meant to leverage the different capabilities and security characteristics of distinct client (application) types. We call those different ways grants through the years. The OAuth 2 family of specifications gained new methods, called extension grants, meant to provide guidance for new types of clients. 

It is not always easy to know what grant to use for your application, especially if you aren’t an identity expert. Usually, SDKs and libraries help, taking care of details for you, but it is often useful to know what is going on behind the scenes - for example, when you need to troubleshoot an issue.

The OAuth 2 game can help you to familiarize yourself with the most common grant choices for the most frequently used application types. It features two dice, one for grants and another for application types. Throw the dice and consult the instructions to discover whether the combination of grant and application type you obtained happens to be a good one! Play a few times, and before you know it, you’ll be familiar with the most common combinations!

## Learn More About OAuth 2

Naturally, there’s only so much we can express with two dice. The OAuth 2 game is based on the most obvious choices of grant per application type, but there are always nuances, exceptions, and more things to consider. If you want to take your understanding of OAuth 2 to the next level, here’s a collection of links to help you take your next steps:

* The Authorization code grant, in both its public and confidential client flavors, is defined in the original [OAuth 2 core](https://www.rfc-editor.org/rfc/rfc6749.html) specification. PKCE, a security measure device to further protect the exchange of authorization codes, is defined [here](https://www.rfc-editor.org/rfc/rfc7636.html).
* The client credentials grant is also defined in the O[Auth 2 core specification](https://www.rfc-editor.org/rfc/rfc6749.html).
* The device authorization grant is an extension grant defined [here](https://www.rfc-editor.org/rfc/rfc8628.html).
* The resource owner password grant was introduced in the original [OAuth 2 core specification](https://www.rfc-editor.org/rfc/rfc6749.html) but is being omitted by the [OAuth 2.1 revision](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02) given its poor security track record.
* You will find useful information on how to apply OAuth 2 in best practice documents - in particular for [native clients](https://www.rfc-editor.org/rfc/rfc8252.html), [browser apps](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) and for [security best practices](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18).
*   Finally, if you want a high-level discussion on modern identity development and some tips on how to choose grants per-app type, you can check out [this session ](https://identiverse.gallery.video/detail/videos/developer/video/6188857523001/modern-identity-for-developers-101?autoStart=true)from the Identiverse 2020 conference. 

## OAuth 2 on Identity, Unlocked Podcast

Want something to listen to while you play? OAuth 2 made several appearances in the last two seasons of Identity, Unlocked.

#### What’s new with OAuth 2.1 with Aaron Parecki

<AmpContent>
<div><iframe width="100%" id="casted-embed-c71b9fbd" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c71b9fbd"></iframe></div>
</AmpContent>
<NonAmpContent>
<div><iframe width="100%" id="casted-embed-c71b9fbd" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c71b9fbd"></iframe><script type="text/javascript">window.addEventListener("message", function(message){if(message.origin === "https://identityunlocked.auth0.com" ) { if( message.data.event) { if(message.data.event === "castedSizeUpdate") { var casted_episode_player = document.getElementById('casted-embed-' + message.data.payload.slug); if(casted_episode_player) { casted_episode_player.height = message.data.payload.height;if(casted_episode_player.contentWindow) {casted_episode_player.contentWindow.postMessage({ event: "castedStopUpdate" }, "https://identityunlocked.auth0.com");}}}}}}, false)</script></div>
</NonAmpContent>

<br \> 

#### A Lap Around the OAuth 2 Security BCP with Daniel Fett

<AmpContent>
<div><iframe width="100%" id="casted-embed-23714281" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/23714281"></iframe></div>
</AmpContent>
<NonAmpContent>
<div><iframe width="100%" id="casted-embed-23714281" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/23714281"></iframe><script type="text/javascript">window.addEventListener("message", function(message){if(message.origin === "https://identityunlocked.auth0.com" ) { if( message.data.event) { if(message.data.event === "castedSizeUpdate") { var casted_episode_player = document.getElementById('casted-embed-' + message.data.payload.slug); if(casted_episode_player) { casted_episode_player.height = message.data.payload.height;if(casted_episode_player.contentWindow) {casted_episode_player.contentWindow.postMessage({ event: "castedStopUpdate" }, "https://identityunlocked.auth0.com");}}}}}}, false)</script></div>
</NonAmpContent>

<br \>

#### JWT Profile for OAuth 2 Access Tokens with Vittorio Bertocci

<AmpContent>
<div><iframe width="100%" id="casted-embed-7efd0ecb" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/7efd0ecb"></iframe></div>
</AmpContent>
<NonAmpContent>
<div><iframe width="100%" id="casted-embed-7efd0ecb" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/7efd0ecb"></iframe><script type="text/javascript">window.addEventListener("message", function(message){if(message.origin === "https://identityunlocked.auth0.com" ) { if( message.data.event) { if(message.data.event === "castedSizeUpdate") { var casted_episode_player = document.getElementById('casted-embed-' + message.data.payload.slug); if(casted_episode_player) { casted_episode_player.height = message.data.payload.height;if(casted_episode_player.contentWindow) {casted_episode_player.contentWindow.postMessage({ event: "castedStopUpdate" }, "https://identityunlocked.auth0.com");}}}}}}, false)</script></div>
</NonAmpContent>


<br \>

## Wanna Play?

The OAuth2 Game will be available at Identiverse 2021, but check back here soon for your chance to receive your own set.

Introducing: The OAuth 2 Game

JWT Profile for OAuth 2.0 Access Tokens with Vittorio Bertocci

## The Overview

In this episode of _Identity, Unlocked_, the CTO and co-founder of Auth0, Matias Woloski, appears as acting host and interviews Vittorio Bertocci, principal architect at Auth0 and the regular host of _Identity, Unlocked_, on the JWT profiles for OAuth2 access tokens specification. 

This spec describes how to encode OAuth2 access tokens in use JWT format in an interoperable way, by giving a minimal list of claims, how to emit a JWT depending on specific aspects of the request, and most importantly, describes how to validate an incoming token based on very specific rules. The document also features sections on security and privacy, highlighting common pitfalls and suggesting ways to prevent and minimize issues.

Vittorio walks Matias through the creation process of this spec, beginning with recognizing that, despite encoding access tokens in JWT was common practice across the industry, there was no guidance on how to do so in any existing standard. After gathering examples of JWT access tokens issued by several different identity products and services, Vittorio presented the general idea for this new spec at the [2019 OAuth Security Workshop](https://osw2019.sec.uni-stuttgart.de/). After receiving interest, he proceeded to produce and propose an internet draft at [IETF104](https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00).

Once the spec was adopted as an official working group item, the workgroup provided an overflow of feedback and the discussions went into much greater and productive detail. While not every interaction in the workgroup is going to be worthwhile or a game changer, Vittorio explains that the working group process is key for producing high quality, widely applicable documents that have been vetted for security and correctness by some of the best experts in the industry. The [specification document ](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12)has now been approved and submitted for IESG publication, one step closer to reaching the status of the official standard.  

Matias and Vittorio speak further about how using this spec JWT profile tokens will make it possible to develop truly interoperable SDKs, allowing developers more time to devote on creating their apps, rather than focusing on low-level implementation differences. Vittorio also hopes this spec will stop the use of ID tokens in place of access tokens, streamline the code required to handle authorization, and help to keep privacy considerations into account when designing API solutions.

The episode closes with a call for action. The work of identity standards groups touches everyone in our industry, but not everyone is represented. Participation is easier than ever, and contributions are welcome - Vittorio encourages reaching out to him for help, extending an invitation to anyone who would like to take part in the process but don’t know where to start.

## Key Takeaways

What is the JWT profile spec, in a nutshell:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/c4eb1494"></iframe>

How a spec evolves from an idea:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/226f297c"></iframe>

The JWT profiles for OAuth2 access tokens spec through the workgroup process:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/9a3722e2"></iframe>

Vittorio explains the potential advantages of this JWT spec:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/f870c54e"></iframe>

Vittorio’s Call to Action: 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/56147e11"></iframe>

### Links/Resources:

- Connect with Matias Woloski on [LinkedIn](https://www.linkedin.com/in/matiaswoloski/)
- Connect with Matias Woloski on [Twitter](https://twitter.com/woloski)

<br>

- Connect with Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)
- Connect with Vittorio Bertocci on [Twitter](http://www.twitter.com/vibronet)

<br>

- Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)
- Learn more about [Auth0](https://auth0.com/)
- Learn more about the sponsor for this season, the [OpenID Foundation](https://openid.net/foundation/)

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />

Identity, Unlocked... Explained: Season 2, Ep 8

Aaron Parecki joins the show to discuss the development of the OAuth 2.1 specification.



### The Overview

In this episode of _Identity. Unlocked_, principal architect at [Auth0](https://auth0.com) and podcast host, Vittorio Bertocci, speaks with Aaron Parecki. Aaron is currently senior security architect at [Okta](https://developer.okta.com/), and he has spent much of his career focusing on [OAuth](https://oauth.net/). He writes and teaches on the subject and joins Vittorio to discuss the latest project he's been working on: the development of the OAuth 2.1 specification.

OAuth 2.1 is a revision of the OAuth 2 core specification and involves a dramatic reduction in the amount of reading that identity providers and SDK authors need to get up to speed on OAuth. The project aims to consolidate current material on OAuth, offering a guide to best practices and including the most relevant guidance directly in the core specification.

Moving into more of the details of the project, Vittorio first asks what OAuth2.1 adds to the OAuth 2 core.
One major addition is the requirement to use PKCE in every authorization grant, including the cases involving confidential clients. 
Recommendations for browser-based apps are in the works, and the new guide will include some stricter requirements defined in the security best current practices document, such as restrictions around refresh tokens. OAuth 2.1 will also introduce a new term, "credentialed client," defined as a client that has credentials but no confirmed identity. The concept already exists in OAuth 2, OAuth 2.1 simply gives it a name so that it can be treated as a legitimate client type, along with the classic public and confidential.
Aaron also explains that OAuth 2.1 omits any mention of implicit flow and password grants, and he and Vittorio finish the conversation with a deep dive on the differences between id tokens and access tokens.

### Highlights

**[5:59]** - Vittorio asks Aaron about OAuth 2.1.

As mentioned during the discussions, [OAuth 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00) (currently in [draft 00](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00))consolidates a number of different specifications. Here's the current list:

* [OAuth 2.0 Core (RFC6749)](https://tools.ietf.org/html/rfc6749)
* [OAuth 2 Bearer Token Usage (RFC6750)](https://tools.ietf.org/html/rfc6750)
* [Proof Key for Code Exchange by OAuth Public Clients (RFC7636)](https://tools.ietf.org/html/rfc7636)
* [OAuth2 Security BCP (draft 15)](https://www.ietf.org/id/draft-ietf-oauth-security-topics-15.html)
* [OAuth2 for Native Apps (RFC8252)](https://tools.ietf.org/html/rfc8252)
* [OAuth2 for Browser-Based Apps BCP (draft 6)](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-06)

By providing a single document with the best & more relevant sections of all those specifications, developers building identity tools, authorization server products, and SDKs will have a much easier time finding the most up to date guidance on how to implement delegated authorization in their scenarios. 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=89b892de&embed=true"></iframe> 

**[11:00]** - Addressing the main additions to the OAuth 2 core, Aaron first talks about the main new requirement introduced by OAuth2.1: imposing the use of PKCE for every authorization grant, regardless of the client type. 

The PKCE requirements is currently introduced in [section 4.1.1 of OAuth 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-4.1.1) (location likely to change as the spec structure evolves). We don't go in the details of PKCE here, as we'll cover the topic more in-depth in an upcoming episode this season (the one about the OAuth2 security BCP, with Daniel Fett); however, if you are interested in the details of the code injection attack, Aaron mentions, please check out [this video](https://www.youtube.com/watch?v=1ot45WwQWJE).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=baa5b4f0&embed=true"></iframe> 

**[14:30]** - Besides PKCE, what is being added to the core?

You can find a good backgrounder on refresh token rotation in [this post](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/). 
The podcast episode discussing sender constraint, MTLS and DPoP can be found [here](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add).

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=9ab6f037&embed=true"></iframe> 

**[20:48]** - Vittorio and Aaron turn to credentialed clients, the new term defined in OAuth 2.1.

Credentialed clients are defined in [Section 2.1](https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-2.1) of the current draft of the OAuth 2.1 specification.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=bfe41a40&embed=true"></iframe> 

**[25:55]** - What has been removed from the core? 

The arguments for not including in OAuth 2.1 the resource owner password grant (ROPG) are well known; hence there isn't much to add or explain on top of what we say on the podcast.

The implicit discussion is a bit more nuanced. You can find a more in-depth discussion in this post from a while back- but there's no doubt about its omission from OAuth 2.1 being a good move. The detail that is perhaps worth expanding on is how the considerations that led to omitting the implicit flow from OAuth 2.1 don't really impact the use of implicit + form POST to get an id token in OpenID Connect for web sign-on in traditional web apps.

In a nutshell: OAuth 2 introduced the implicit flow as a way of getting access tokens, the only token type it defines, directly from the authorization endpoint- and mostly with single-page apps in mind. As we have seen in the podcast episode on sender constraint, leaking access tokens meant to be used as bearer tokens has serious consequences, as attackers can successfully reuse leaked tokens. If you consider the fact that returning access tokens via implicit flow for single-page apps specifically creates more attack surface for stealing tokens (token bits in referral headers, browser history, etc.), you can see how it's prudent to fall back on more robust methods, such as authorization code with PKCE directly in JavaScript.

None of the above really applies to get id tokens via implicit + form post when implementing web sign-on in OpenID Connect That's for two main reasons, as identified in the podcast discussion:

1. The mechanics of returning a token via form post are more robust than the ones using a fragment. Tokens returned via form post don't end up in referral headers or the browser history as query elements do.
2. More importantly: OpenID Connect implements measures that make it hard to reuse a leaked id token, for example, by using a nonce.

To better understand the last point, take a look at the following diagram.

![Diagram Token](https://images.ctfassets.net/23aumh6u8s0i/5JM77M913ht4ohtWiulli4/091cff95c794b0b13f30a3dc6c83b725/diagram-token)

When a web app wants to perform a sign in with an OpenID Connect provider, it generates a nonce (random unguessable string), it saves the value of the nonce so that it can be retrieved in the context of the current transaction (for example, by asking the browser to save a cookie containing the nonce value and somehow protected from tampering, for example by signing the cookie with a secret) and it includes the nonce in its sign-in request.

Leg 1 in the diagram shows the step right after all that occurs, with the sign-in request including the nonce reaches the authorization server acting as OpenID Connect provider.  
Upon successful authentication, the provider returns an id token that, besides being signed (not shown in the diagram), featuring the canonical claims, etc. etc., also includes a nonce claim carrying the nonce value received during the sign-in request.

In the form post case, the browser reacts as shown in leg 3- by immediately POSTing a form containing the id token to the requesting app, along with the nonce cookie created at request time.
Upon receiving the id token, the web app validates it as established by the OpenID Connect spec, and, as part of its validation checks, it verifies that the nonce claim value corresponds to the nonce saved in the tamper-proof cookie. If the values do match, the web app considers the request valid- and, as shown in leg 4 of the diagram, establishes a session of its own and, importantly, removes the nonce tracking cookie (or any other measure that would make the nonce single use).

If an attacker manages to steal the id token and attempts to use it, they will be unable to present a corresponding nonce tracking cookie with the value matching the id token content- as they don't have access to the crypto material the web app uses to manufacture and verify such cookies. Voila, the replay attack is defeated! 

Although this is not directly germane to OAuth 2.1 per se, you can expect discussions like above to be common in the months ahead as the community digests the impact of the changes in OAuth 2.1. Hopefully, this diagram, and this podcast episode in general, equipped you to contribute to those discussions and decide how to apply this knowledge to your own scenarios!

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c71b9fbd?clip=714b5bc0&embed=true"></iframe> 

If you want to dig further on the topic of OAuth 2.1, you can also take a look at the recording of a 30 mins session from the ASC 2020 conference [here](https://www.youtube.com/watch?v=tEUIsc6skJQ).

### Links/Resources:

Learn more about [Aaron Parecki](https://aaronparecki.com/)<br />

Aaron Parecki on [Twitter](https://twitter.com/aaronpk)<br />
Aaron’s ebook on [OAuth](https://oauth2simplified.com/)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
Vittorio Bertocci on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 2

A preview of our new ebook about OIDC, the de facto standard for handling authentication in the modern world.



**TL;DR:** In August 2019, Auth0 published an ebook called [The OpenID Connect Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook) to help developers leverage this modern identity layer to provide an easy and secure authentication mechanism to their users. This ebook covers all the main concepts that you must know to integrate your app with OpenID Connect providers. If you are in a hurry and would like to dive right into the content of the ebook, click the link below to get your free copy.

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

The rest of this article will summarize the content of the ebook so you can take a glimpse of what you will learn about on the ebook.

<include src="TweetQuote" quoteText="The OpenID Connect Handbook teaches you everything you need to handle end-user authentication securely."/>

## The Contents of the OpenID Connect Handbook

As of October 2019, the handbook covers six main areas related to OpenID Connect. Each area has a chapter of its own that is subdivided into other sections to help you understand OpenID Connect, how this identity layer was born, and how to use it to secure your applications:

1. Introduction
2. OpenID Connect Introduction
3. OpenID Connect in Action
4. OpenID Connect and Traditional Web Applications
5. Traditional Web Apps and the Delegated Authorization Flow
6. OpenID Connect and Single-Page Applications

The following sections will cover each one of these chapters separately, so you can learn what to expect on them. Hopefully, if you are looking to learn about a topic in particular, you will be able to download the free ebook and dive right into it.

## Introduction

The Introduction chapter of this handbook disserts about topics that are not part of OpenID Connect per se, but that are important for you to grasp before you start learning about it. In this chapter, you will learn about the terms Entity and Identity and you will learn about how they are interconnected. There, you will learn that an entity has multiple identities and that people, or other entities, perceive entities through their identities.

![Every entity have multiple identities that others use to perceive them.](https://images.ctfassets.net/23aumh6u8s0i/2nKkQmov8tv3VgxNExyjjp/b0898dc4882fc7104241af91feb63850/entity-identity-concepts)

After that, you will learn about the terms Authentication and Authorization. More specifically, you will learn how these terms are related, how one thing can lead to another, and how they differ. Authentication vs. Authorization is an important topic that causes great confusion, even on members of the IT workforce around the world.

![Authentication and authorization are topics that cause confusion and that are often used interchangeably by mistake.](https://images.ctfassets.net/23aumh6u8s0i/olPsGOC0fQLSBHxkP4Ujp/384681fbed0a5587f1646e7becb0e378/end-user-authentication)

## OpenID Connect Introduction

After learning about the conceptual topics that preamble this ebook, you will start learning about OpenID Connect. This chapter will begin by guiding you through a ten-thousand-foot overview of how an OpenID Connect authentication transaction works. After that, you will briefly read about other authentication mechanisms and how the IT community went from simple usernames and passwords, to Kerberos, to SAML, and OpenID Connect.

![A brief illustration that shows how SAML works.](https://images.ctfassets.net/23aumh6u8s0i/2l4JlPlLlYCqLPfYCZILmj/bbbb9ea320109fa04ee89c2344fb666d/an-illustration-of-how-saml-works)

The chapter will then move into more details about the OpenID Connect specification and will talk about OAuth 2.0, the underlying technology that the identity layer builds on top. In the end, you will read about some OpenID Connect use cases so you can learn when this technology can be helpful.

## OpenID Connect in Action

The next chapter on the ebook, called OpenID Connect in Action, will start to teach you the inner workings of the OpenID Connect specification. There, you will set up an OpenID Connect provider that you will use through the hands-on exercises, and you will prepare your local environment to run the samples that you will learn about. As the goal of the ebook is to show, step by step, how you can secure your applications with OpenID Connect, the exercises will use the most popular programming language in the world (i.e., JavaScript) to lower the barrier.

![Creating an OpenID Connect provider to use throughout the handbook exercises](https://images.ctfassets.net/23aumh6u8s0i/3XeqIvJa9337fCbQyqQAtM/a133df9d47c5e2f1f5dcc93a7d56d0a7/creating-an-openid-connect-provider)

## OpenID Connect and Traditional Web Applications

Having created your OpenID Connect provider and prepared your local development environment, the next chapter will be the first hands-on activity of the ebook. However, besides being a hands-on activity, the chapter will also teach about important topics such as [the authentication flows](https://auth0.com/docs/flows). You will find a few other useful resources on the internet that inform you about OpenID Connect. The main problem with them, which this ebook aims at solving, is that they introduce a lot of theory before giving you anything you can use.

In this ebook, you will see that you will learn about the abstract parts of OpenID Connect on the fly. That is, instead of investing time to learn about all the different authentication flows that OpenID Connect supports and about all the abstract terms involved in them, this ebook will briefly teach you about them, then it will use these concepts right away.

For example, after you read about what an authentication flow is, you will jump right into using one. Besides that, you will read and learn how to use Discovery Endpoints, an prominent piece of OpenID Connect providers, right away. You will also learn about other important topics in this chapter like the Authentication Callback and user profiles.

## Traditional Web Apps and the Delegated Authorization Flow

After you learn about how OpenID Connect securely promotes end-user authentication, the ebook will continue by teaching you about one of the most prominent scenarios where OpenID Connect and OAuth 2.0 are used: on delegated authorization. The chapter will show you all you need to know about this kind of authorization but, basically speaking, delegate authorization is when you let an app act on your behalf. The example that you will read about everywhere, including in this ebook, is when a third-party application wants to help you schedule tweets. In this scenario, this third-party app will have to ask you for permission to tweet on your behalf on the date and time you configure it. When this app issues a request to Twitter to create the tweet, the app will be acting on your behalf.

![Delegated authorization sample where the app wants to tweet on behalf of the user.](https://images.ctfassets.net/23aumh6u8s0i/6JNFmYekPxdetLv4IP2E7H/7613f4ab8889cda76b97605430526401/delegated-authorization)

## OpenID Connect and Single-Page Applications

The last chapter of the handbook (so far, because we will publish more chapters soon) talks about how to secure Single-Page Applications with OpenID Connect. In the modern internet, most popular apps (and those that are not popular also) are using this approach to promote a better user experience to their customers. Therefore, it wouldn't make sense to have an ebook that does not cover the most popular paradigm when it comes to web development.

In this chapter, you will learn about terms like PKCE (Proof of Key for Code Exchange) while integrating a single-page app with your OpenID Connect provider. Besides that, you will also take a look at a popular alternative called the Implicit Grant and why this approach is not encouraged anymore. As SPAs are usually hosted as static files in a cloud provider, you will also use delegated authorization in this chapter. That is, you will have an API that contains data that belong to users and you will make the SPA ask users permission to consume this API on their behalf.

![Single-Page Apps can securely authenticate end-users with OpenID Connect providers by using PKCE.](https://images.ctfassets.net/23aumh6u8s0i/338DB6V09xi9ufeUEy5nzS/b76da928c2481cf90500ef5492094b6e/spa-and-the-pkce-flow)

## Conclusion

As you can see, if you are interested in learning about OpenID Connect and how this technology can help you secure your applications, you came to the right place. In this ebook, you will learn everything you need to make your apps behave as OpenID Connect clients and how to make them consume APIs on their users behalf. Another interesting thing that you will learn in this handbook is about how popular and official SDKs (like the ones supported by Auth0) can help you be more efficient. That is, the ebook will show you everything you need to code in any application to make it integrate with an OpenID Connect provider, but it will also show you a more straightforward way to achieve your goals. With this, you will have both the tools to debug any misconfiguration and to be as focused as possible on what makes your app unique.

If you need help with any matter related to the OpenID Connect Handbook or to identity, authentication, and authorization, let us know in the comment box below.

<include src="TweetQuote" quoteText="OpenID Connect is an easy and powerful tool you can use to secure your applications."/>

<include src="asides/AboutAuth0" />


The OpenID Connect Handbook

2b7b341132c3df90155a9914f13b6deb

Former Auth0 Employee

Zach Walchuk

Why the OpenID Foundation's open letter to Apple might not matter for your applications.



Last week, the OpenID Foundation posted an [open letter to Apple](https://openid.net/2019/06/27/open-letter-from-the-openid-foundation-to-apple-regarding-sign-in-with-apple/), encouraging them to bring the recently announced Sign In with Apple login feature in line with the [OpenID Connect (OIDC) protocol](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog). As we pointed out when it was first announced, [Sign In with Apple](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/) aligns with some of the requirements laid out in the OIDC and [OAuth 2.0](https://tools.ietf.org/html/rfc6749) specifications, but Apple makes little mention of these standards in their official documentation.

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

![OpenID Foundation and Apple logo illustration](https://images.ctfassets.net/23aumh6u8s0i/47vwPJFYvPU0hM9s7rMakE/a5f080fb33d7c3e95d9a7b40aa1eefd5/apple-oidc)

The letter from the OpenID Foundation was [accompanied by a document](https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md) outlining where Sign In with Apple differs from the OIDC specification. This document, drafted by the OpenID Foundation’s Certification team and other members of the identity community (including Filip Skokan, an engineer at Auth0), calls out the OIDC spec violations that increase the risk of attacks and privacy concerns, as well as additional peculiarities that will make it difficult for developers to incorporate Sign In with Apple into their existing applications.

## What This Means For Application Developers

While Sign In with Apple is still very much under development and a number of significant changes can be expected, a lot of attention is being paid to the implementation specifics even at this early stage. This is largely due to the fact that Apple will require the Sign In with Apple option for all applications in their ecosystem that support third-party logins. A new identity provider that complies with established standards could greatly reduce the burden on application developers, as many applications are already set up to handle similar connections that do follow the standards.

Of course, Apple may choose not to align with the OIDC specification for any number of reasons related to their goals and requirements as a hardware and software provider. Identity and access management is not a core product for Apple, and establishing interoperability with systems outside of their ecosystem may very well not be a high priority. As with any identity solution tightly coupled with a company’s other software, features that benefit general use may only be put into place when they overlap with the specific requirements of operating within that company’s primary offerings. But interoperability is not the only concern addressed in the OpenID Foundation’s letter — it remains to be seen how Apple will address the attack surface exposed by not complying with parts of the specifications that deal with preventing known attacks.

## Managing Discrepancies with an Independent Identity Platform

Independent identity platforms, focused solely on [identity and access management](https://auth0.com/blog/identity-as-a-service-in-2018/), do not run into these same issues with competing priorities. It is in their best interest, and the interests of their users, to connect as easily and widely with other systems as possible. At Auth0, we provide simple configuration options to set up a variety of [social](https://auth0.com/docs/identityproviders#social) and [enterprise](https://auth0.com/docs/identityproviders#enterprise) connections that follow the standards established by OIDC and OAuth 2.0, SAML, WS-Federation, and many others. For those connections that don’t entirely comply with specifications, we work to bridge the gaps by implementing the best options the providers offer and adding measures where we can to harden against attacks. And while we continue to be active in the identity community to encourage the adoption of recognized standards, the Auth0 platform is built to address and keep up with any differences, so that application developers can be free from worrying about changes that might affect their code.

Because Auth0 is a [certified OpenID provider](https://openid.net/certification/), you know what to expect when connecting with our platform. Any application already supporting an OIDC-compliant provider is already set up to quickly integrate with Auth0 and connect to a vast array of identity providers by simply turning on a few switches. And with our [collection of SDKs](https://auth0.com/docs/libraries#sdk-repositories-and-support-status) across multiple languages, it’s easy to secure any application with Auth0 without having to worry about implementation details.

## Aside: Try Sign In with Apple on Auth0 Today

Auth0's beta support of Sign In with Apple makes it easy to get started:

* <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for an Auth0 account.</a>
* Use the [QuickStart](https://auth0.com/docs/quickstarts) of your choice to integrate Auth0 into your application, or start from scratch and have a secure app deployed in minutes.
* Add Sign In with Apple under “Connections” > “Social”, and test with Auth0's developer credentials.

![Auth0 Dashboard - Social Connections with Sign In with Apple included](https://images.ctfassets.net/23aumh6u8s0i/3rMC0k1THr4rYHnQ22y2zx/891a90db2e67aed1b0e233a26713139b/social-connections)


Apple ID, OIDC, and How Identity Independence Keeps You Free

Learn how the OAuth 2.0 Device Flow offers smooth authentication and authorization to limited-input devices.



Tired of wrestling with remote controls and on-screen TV keyboards to enter credentials on your smart TV? You’ve dealt with it too many times, and you can bet your customers have to. What if you could help them get logged in with just a few taps on their cell phone?

![Image of person using TV remote control to enter credentials](https://images.ctfassets.net/23aumh6u8s0i/40YgdeQssI4jVCDkuUFBhK/84a3c8111f80e7c8f1e0c45c0366f7ac/do-not-use-remote-controls-to-enter-credentials)

Hi, Dan from Auth0 here bringing you the [**OAuth 2.0 Device Flow**](https://auth0.com/device-flow/): a fast, easy, and safe way to log into apps on your Smart TV and other input-constrained devices. No keyboard? No browser? No problem!

Ordinary login can be tedious and error-heavy. The OAuth 2.0 Device Flow is lightweight, authenticates you in seconds and not only works with TVs, but also with game consoles, CLIs, printers, and much more!

Auth0 offers developers a fully compliant implementation of the OAuth 2.0 Device Flow to tackle this user experience pain point easily. Let’s learn more about what input-constrained devices are, how this authorization grant works, and how Auth0 can help.

## What Are Internet-Connected, Input-Constrained Devices?

Do you have an internet-connected device that either (1) has no browser or (2) offers impractical ways for you to input text?

If you answered yes, then you have an input-constrained device! What type of devices came to your mind? I am thinking...

- All-in-One printers
- Fitness trackers
- Streaming devices
- Toothbrushes
- Game consoles
- Fridges
- Teddy bears
- Car infotainment systems
- Smart TVs
- Really, anything with the word “smart” in front of it

![Smart TVs, printers, gaming consoles, and other typical input-constrained devices](https://images.ctfassets.net/23aumh6u8s0i/2f4VYWXdICGOnMhmtm0u1G/d847718b30d453a63bd3f4d21c9d0e89/typical-input-constrained-devices)

The Internet of Things (IoT) frenzy has put a lot of devices online. Today or in the future, the software running on these devices may talk to your service APIs to get the data needed to offer your customers a rich user experience across devices and platforms. However, that user experience may not be so rich or secure if a device doesn’t offer a convenient way to authorize external services.

<include src="TweetQuote" quoteText="Granting authorization on input-constrained devices is challenging. But what are input-constrained devices anyway? Learn more in this blog post!"/>

As a competitive business, you don’t want to limit the devices that can use your services by not being able to provide browserless authentication. But, if the device does offer a browser or user interface, you wouldn’t want your customers to enter credentials using the arrows of a TV remote control to select keys from a giant on-screen keyboard. Their credentials could be compromised by someone recording their screen as they slowly input them, for example.

Furthermore, you’ll want to ensure that user credentials are not entered on systems that you don’t control and that may store them for future access, like smart displays that sometimes leverage proprietary systems or third-party clients that access your APIs.

What you do want is a way to authorize third-party applications with controlled access to your APIs on a variety of devices. The OAuth 2.0 Device Flow lets you do exactly that! Even on devices without a browser, you can take advantage of the security and user experience benefits of a standard delegated authorization protocol.

<include src="ProfileCard" picture="https://cdn.auth0.com/blog/auziro/julian-lywood-mulcock-mini.png" name="Julian Lywood-Mulcock" title="Customer Success Architect" team="Customer Success" location="London, United Kingdom" body="With Device Flow, we reduce end-user frustration and we ensure the log-in action is as secure as it can be. <br /><br />By decoupling the log-in experience from input-constrained devices, end-users can benefit from a secure method of authentication while having a frictionless user experience they will tell their friends about."/>

To understand how to go with the Device Flow, it’s better for you to see it at play using a video streaming app as an example.

## OAuth 2.0 Device Flow In Action

Say that you want to watch AuthU TV, _a fictional video platform for techies_, on your television. You start by downloading the AuthU TV app to your smart TV. When you open the app for the first time, you’ll be welcomed by a login screen.

To kick things off, you’ll be asked to visit a URL on another device (like a smartphone or laptop), enter a short code, and then log in to your AuthU account to authenticate yourself.

Completing this process gives the software on your TV access to your AuthU account and lets you use your remote control to navigate AuthU content &mdash; not enter credentials.

![Illustration of OAuth 2.0 Device Flow that connects your devices](https://images.ctfassets.net/23aumh6u8s0i/2fc4mgnGc7TLVmFSyFCEmq/a1a849dbf53cc82ec7c30e6f6ff63b31/device-flow-banner-2)

At a high level, this process is very similar to how YouTube redirects to accounts.google.com to process a user login. With the OAuth 2.0 Device Flow, you manage the authentication process on a centralized login page, using a secondary device to make the input of credentials faster and more secure. By moving authentication off the device and into a browser, you are able to take advantage of more advanced identity and security features, such as MFA, SSO, and Social Login.

But talk is cheap: let’s see the Device Flow in action! Our engineers at Auth0 created an interactive demo that lets you simulate the authorization of the AuthU smart TV app right from your browser.

Start by visiting the [_Device Flow Playground_](https://auth0.github.io/device-flow-playground/). Once there, you can either try the playground with our default demo settings or configure with your Auth0 account settings to try in your own applications.

> Need an Auth0 account? <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Get started for free today</a>. You’ll be saying “Wow!” while using everything that Auth0’s free trial has to offer!

You can also select the desired scopes you want to have. Once that’s done, click on “Get Started”.

![Image showing dashboard for how to get started with Auth0 Device Flow](https://images.ctfassets.net/23aumh6u8s0i/2kEgfhvZh84ty2XsEfjDS4/282e39d53d32deef8e381d012bbce385/getting-started)

Next, to stream content from the mock AuthU TV app, you are prompted to authorize the app by clicking on the “Authorize” button.

![Auth0 Device Flow: authorization request](https://images.ctfassets.net/23aumh6u8s0i/YYQyy8IRjr6yMu5bZ2CVK/a1d955489836849e35411d38da360a2e/authorization-request)

Now you are prompted to authorize the device by navigating to the activation URL, [_acme-demo.auth0.com/activate_](https://acme-demo.auth0.com/activate), using another device and entering the code displayed on your smart TV. You can also scan the QR code, which would automatically input the user code. The TV app will be waiting for you to complete the process on your secondary device which would trigger an authorization response it can use to get access to the AuthU TV service.

![Auth0 Device Flow: token request](https://images.ctfassets.net/23aumh6u8s0i/1kbV5mJIgdzqj1zKttXvhx/edefed4de2bfd100c411b0e4192c6892/token-request-2)

Visit the provided link, enter the one-time code, and click “Continue”. You can do this using another browser tab or your smartphone mobile browser.

![Auth0 Device Flow: device activation](https://images.ctfassets.net/23aumh6u8s0i/2DyardhZGZL9dsFkyv1ntI/eeee2eee9563b6c32066c3b5df3223c2/device-activation-enter-code)

![Auth0 Device Flow: device activation code](https://images.ctfassets.net/23aumh6u8s0i/5PUMsCJHIxEqQuqBhec3oC/6b3a2704a91bfd070ac57ad87983d7c9/device-activation-code-entered)

Confirm that the code displayed on the site matches the one shown on the smart TV and click “Continue”.

![Auth0 Device Flow: device confirmation](https://images.ctfassets.net/23aumh6u8s0i/7c5GzgdHLuYt2iPuqDzBhd/c5cd28ea0e35deee1a8648a757fd18d6/device-confirmation)

Next, sign up for an account or log in with an existing one.

![Auth0 Device Flow: user authentication](https://images.ctfassets.net/23aumh6u8s0i/1s4Z8pZ2FknPYkMD3BtcNr/0e46e566969ef95f364bb30afd12bb5e/authentication)

A message will show up on the site confirming that the device is now connected.

![Auth0 Device Flow: device connection](https://images.ctfassets.net/23aumh6u8s0i/6rJnFfbuz2vv0gn5Du3ivY/3df5ee90405b34ebe7816149d8777d7f/your-device-is-now-connected)

Back on the smart TV, the AuthU app is ready to start streaming content. The TV app has the authorization to fetch additional information about you to customize the UI.

![Auth0 Device Flow: activation completion](https://images.ctfassets.net/23aumh6u8s0i/01qheEW2pvdEikaQlCUq2l/12338b0c904089d2d86eace3f955cff7/activation-complete)

That’s it for a high-level technical overview of the OAuth 2.0 Device Flow. Let’s peek under the hood at how using Auth0 as your identity platform facilitates this process.

## OAuth 2.0 Device Flow Made Easy with Auth0

When your input-constrained device needs to fetch user data from your API, the following process takes place:

![Overview of OAuth 2.0 Device Flow with API calls](https://images.ctfassets.net/23aumh6u8s0i/2Ykjsm2pB8MBDiqWLTq6RQ/e80d6aa8ab913d990107e81b2aa41dbc/overview-flow-call-api-device-app)

1. If the device application is not already authorized, your device application calls your Auth0 Authorization Server to retrieve a device code.

2. Auth0 responds with a URL and user code. Your device app asks the user to visit a specific URL on a secondary device (like a laptop or smartphone) and provide the activation code.

3. Your device app begins to poll your Auth0 Authorization Server for an Access Token and a Refresh Token.

4. The user authenticates with Auth0 on the secondary device using one of your already configured authentication methods. Auth0 is an identity hub that supports many [_Identity Providers using various protocols_](https://auth0.com/docs/identityproviders) (like OpenID Connect, SAML, WS-Federation, and more).

5. Once authentication is complete, Auth0 responds to your device app with an Access Token and a Refresh Token, which lets you refresh the Access Token without having to request permission from the user again.

6. The Access Token can be used to call your API and retrieve requested data.

<include src="TweetQuote" quoteText="With access tokens and refresh tokens, you make authentication fast and make it last! Learn more about how tokens work in the OAuth 2.0 Device Flow."/>

## Recap

Today, you learned what internet-connected, input-constrained devices are, the challenges that these devices present to developers and customers alike, and how Auth0 along with OAuth 2.0 let you tackle those challenges through the implementation of the Device Flow.

The best part of the OAuth 2.0 Device Flow is that it lets you extend your existing authentication solutions to smart device platforms. This authorization grants simply lets your customers authenticate and authorize applications running on one device through another.

You may be curious about how you or your development team can implement this through code. We'll provide you with a detailed tutorial on Device Flow soon. Stay tuned! In the meantime, check the following resources for more information:

- [Introducing Device Flow](https://auth0.com/device-flow/)

- [Auth0 Device Authorization Flow Documentation](https://auth0.com/docs/flows/concepts/device-auth)

- [Calling an API Using the Device Authorization Flow](https://auth0.com/docs/flows/guides/device-auth/call-api-device-auth)

- [OAuth 2.0 Device Authorization Grant, Draft 15](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15)

<include src="TweetQuote" quoteText="The OAuth 2.0 Device Flow is designed for applications executed on internet-connected devices that either don’t have a browser or are input-constrained. It enables end-users to authorize device applications to access service APIs."/>

<include src="asides/AboutAuth0" />


OAuth 2.0 Device Flow, No Hassle Authentication - As Seen On TV

Integrated support for Sign In with Apple is now available in Auth0 as a beta feature.



Two weeks ago, Apple announced the launch of a new authentication feature, [Sign In with Apple](https://developer.apple.com/sign-in-with-apple/). According to Apple, Sign In with Apple offers a number of benefits for Apple users, including enhanced privacy (with the ability to hide your email address) and a seamless experience across Apple devices and the web. Reactions to this announcement included a point of concern for application developers — all apps in the App Store that offer authentication through third-parties (such as Google, Twitter, or Facebook) will be required to support Sign In with Apple, and integrating a new identity provider which may not fully comply to standard protocols is not an easy task.

In our [initial coverage of the news](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/#Implementing-Sign-In-with-Apple), we mentioned that using an identity management service like Auth0 greatly reduces the effort required to integrate a new identity provider. With a [follow-up post](https://auth0.com/blog/implement-sign-in-with-apple-using-auth0-extensibility/), we demonstrated how our [Custom Social Connections](https://auth0.com/docs/extensions/custom-social-extensions) feature could help you integrate Sign In with Apple without making changes to your application code, using a simple script run on our servers.

Today, we are happy to announce that integrated support for Sign In with Apple is available in Auth0 as a beta feature, making it far easier than anything we've shown yet to preview the experience in your own applications. You don't even need an Apple Developer account to get started — just flip a switch and give it a try!

## Add Sign In with Apple to Your Applications

For <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Auth0 users</a>, adding Sign In with Apple to your applications is simple:

* For the easiest setup, go to "Universal Login" in the Auth0 dashboard and click "New".
    * If you prefer the Classic Universal Login experience, click the "Login" tab and turn on "Customize Login Page". Find the line in your HTML that pulls in the Lock script and update to reference Lock version 11.16:  
    `<script src="https://cdn.auth0.com/js/lock/11.16/lock.min.js"></script>`
* Save your changes, then go to “Connections” > “Social”:
![Auth0 Dashboard - Social Connections with Sign In with Apple included](https://images.ctfassets.net/23aumh6u8s0i/3rMC0k1THr4rYHnQ22y2zx/891a90db2e67aed1b0e233a26713139b/social-connections)
* Click on the Apple icon to turn on the Sign In with Apple connection. To test right away with Auth0's developer credentials, leave the fields blank. To test more fully with your own Apple Developer account, you can follow these steps (more details in our [previous post](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/#Implementing-Sign-In-with-Apple)):
    * The `Client ID` is the identifier you choose after registering a Services ID in the Apple Developer portal.
    * Your [domain](https://auth0.com/docs/custom-domains) will need to be verified with Apple as part of the service configuration.
    * The `Client Secret Signing Key` can be downloaded when you register a new key in the Apple Developer portal. The `Key ID` will also be available after this step.
    * Your `Team ID` can be found [here](https://developer.apple.com/account/#/membership).
![Auth0 Dashboard Sign In with Apple provider settings](https://images.ctfassets.net/23aumh6u8s0i/21TYVKzlcsyCQA1MVrMCGh/e034e39c10a8203a8cdb6c0f35dd836b/sign-in-with-apple-settings)
* Click “Save”, then before exiting the window click the “Applications” tab to select which of your Auth0 applications should allow the Sign In with Apple option. Click “Save” one more time.
* Navigate to your application’s login page to verify the change:
![Auth0 Sign In with Apple identity provider Login form preview](https://images.ctfassets.net/23aumh6u8s0i/7hJCOMwmV588En96HxkM1w/7908df4dd2dadaeb5172ee02e7964b69/apple-login-page)

> **Note:** Testing Sign In with Apple with your own Apple Developer account does require a [custom domain](https://auth0.com/docs/custom-domains), as you will need to verify ownership of your domain with Apple.

We’re still in the early days of this beta feature from Apple, and the current implementation is missing some necessary functionality. At the time of this post, Apple doesn’t return names and email addresses for signed-in users, and you can bet a number of extensive changes to the service will be made before it is fully released. While we can’t guarantee that the level of integration shown in this preview will always be available, we’ll be keeping track of any necessary changes and doing everything we can so that when Sign In with Apple is ready for production, you will be too.

## Get Started with Auth0

If you aren’t already using Auth0, it’s easy to get started:

* <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for an Auth0 account.</a>
* Use the [QuickStart](https://auth0.com/docs/quickstarts) of your choice to integrate Auth0 into your application, or start from scratch and have a secure app deployed in minutes.
* Add Sign In with Apple under “Connections” > “Social”, and test with Auth0's developer credentials.

## What’s Next

Sign In with Apple is just one of the identity providers that can be added to your application with the flip of a switch, and adding social connections is only one of the many features available to Auth0 users. As we continue to learn more about Apple’s requirements for this service, we’ll maintain support with our built-in integration and share how Auth0’s advanced features (such as [account linking](https://auth0.com/docs/link-accounts), more to come soon) can help you give your users an optimal sign-in experience.

If you have any feedback or questions regarding the Sign In With Apple beta, please let us know in the [Auth0 Community forum](https://community.auth0.com/c/auth0-beta-programs/sign-in-with-apple).






Try Sign In with Apple in Your Auth0 Apps Today

abhishek-hingnikar

I am a Specialist Solutions Engineer at Auth0. I specialize in Identity and Access Management and enjoy building software. I have experience developing software in several frameworks and a variety of domains. I enjoy traveling, cooking, and building robots!

Specialist Solutions Engineer

Abhishek Hingnikar

Extend Auth0's core functionality to support Sign In with Apple in your application.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  Integrated support for Sign In with Apple is now available in Auth0 as a beta feature! <strong><a href="https://auth0.com/blog/try-sign-in-with-apple-in-your-auth0-apps-today/">Implement Sign In With Apple now</a>.</strong>
</div>

Last Thursday, [we took a look at Sign In with Apple](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/), the new identity provider features Apple released at WWDC 2019. In that post, we included simple steps to add support for Sign In with Apple in a Node.js application. Today, we're going to show you how you can support Sign in with Apple without adding any special code to your app — thanks to [Auth0's Custom Social Connections](https://auth0.com/docs/connections/social/oauth2), Apple is just one of the many [identity providers](https://auth0.com/docs/identityproviders) you can leverage when connecting to Auth0.

## Extending Auth0’s Core Functionality

We recently wrote about our [vision and guiding principles](https://auth0.com/blog/the-developer-first-identity-platform-auth0-story-and-future/). Developers don’t want to feel like they are constrained by their tools and libraries, especially with an infrastructure component like authentication. Extensibility within our product is a first class citizen, and this is reflected by the fact that 87% of our customers extend the platform. One of the extensibility points we provide allows for adding a new federated authentication method, as highlighted below. This is what we will use to add support for Sign In with Apple:

![Auth0’s extensibility options](https://images.ctfassets.net/23aumh6u8s0i/76ZZsR3TMEJbf9WBnLMRma/7e91db2ea59764168e13721b2db8829a/auth0-engine-custom-connections)

## Prerequisites

To add support for Sign In with Apple, you'll need to have an Auth0 Tenant [set up with a custom domain](https://auth0.com/docs/custom-domains), as well as a web application configured to use Auth0 for authentication at that domain. You can get an application up and running in a few simple steps by using any of our [quick starts](https://auth0.com/docs/quickstarts). Note that for the purpose of this post, your application can use any development stack: Node.js, ASP.NET, Java, and so on.

## Register with Apple

Once you have your application set up, you'll need to create an Apple App ID and a Services ID. We covered these steps in detail in our [previous post](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/#Implementing-Sign-In-with-Apple), but in summary the steps are:

* Create an [Apple Developer Account](https://developer.apple.com)
* Go to ["Certificates, IDs, & Profiles"](https://developer.apple.com/account/resources/certificates/list) -> [ "Identifiers"](https://developer.apple.com/account/resources/identifiers/list/serviceId) -> "Register an App ID"
* Choose "App IDs" as the identifier type and hit "Continue"
* Provide a description and a Bundle ID (reverse-domain name style, i.e., `com.mycustomdomain`)
* Scroll down and check "Sign In with Apple", then "Continue" followed by "Register"
* Back at the "Certificates, IDs, & Profiles" section, click the blue icon next to "Identifiers"
* Choose "Services IDs" and click "Continue". Fill in the description and identifier (`com.mycustomdomain.webapp`)
* After checking "Sign In with Apple", click on "Configure"
* Define your "Web Domain" (`mycustomdomain.com`) and "Return URL" (`mycustomdomain.com/callback`)
* Click "Save", and then "Continue" followed by "Register"

Once you have your Services ID, you'll need to verify your domain with Apple:

* On the "Certificates, IDs, & Profiles" page, click your newly created Services ID
* Hit the "Configure" button next to the "Sign In with Apple" feature, then click "Download" 
* Copy the `apple-developer-domain-association.txt` file to your application server and make it accessible at `https://mycustomdomain.com/.well-known/apple-developer-domain-association.txt` (see our [previous post](https://auth0.com/blog/what-is-sign-in-with-apple-a-new-identity-provider/#Implementing-Sign-In-with-Apple) for a detailed example)
* When this is ready, click "Verify" on your Services ID configuration page. If no error is raised, you are good to go

## Create a Custom Social Connection

In the next step, you’ll add Apple to the collection of identity providers you can integrate with via Auth0.

After you've registered your application with Apple, visit the Auth0 Dashboard and go to **Connections > Social**, scroll to the bottom, and click **Create Custom**.

Most of the information you'll need to create this custom connection has been established in previous steps. To generate the client secret, do the following:

* Head to ["Keys"](https://developer.apple.com/account/resources/authkeys/list) under the "Certificates, Identifiers, & Profiles" section of your Apple developer dashboard
* Click on the round, blue icon to add a new key
* Enter a "Key Name" and check the "Sign In with Apple" option
* Click on "Configure" to make sure the "Choose a Primary App ID" field is filled with your App ID
* Hit "Save", "Continue", and then "Register"
* Download the key, move to its own directory, and rename to `authkey.p8`. Make a note of the Key ID
* Use a JWT library with support for the ES256 algorithm to generate the client secret from the key — the example below uses Node.js, but libraries for other languages can be used in a similar fashion

To use this script, create a new file called `generate-secret.js` in the same directory as the key and add the following code:

```js
const jwt = require("jsonwebtoken");
const fs = require("fs");

const privateKey = fs.readFileSync("./authkey.p8");
const token = jwt.sign({}, privateKey, {
 algorithm: "ES256",
 expiresIn: "60 days",
 audience: "https://appleid.apple.com",
 issuer: "TEAM_ID",
 subject: "com.mycustomdomain.webapp",
 keyid: "KEY_ID"
});

console.log("The token is:", token);
```

> **Note:** You will need to replace `com.mycustomdomain.webapp` with the identifier for your Services ID and replace `TEAM_ID` with your Team ID, which can be found [here](https://developer.apple.com/account/#/membership). You'll also need to replace `KEY_ID` with the Key ID you noted earlier.

Run this script to generate your client secret:

```bash
node generate-secret.js
```

With this, you have almost everything you need to complete the custom social connection! Returning to your Auth0 dashboard, make sure your custom social connection fields look like this:

* **Name:** `Apple`, or any name you choose
* **Client ID:** your Services ID identifier, e.g., `com.mycustomdomain.webapp`
* **Client Secret:** the string generated in the previous step
* **Fetch User Profile Script:**

    ```js
    function (accessToken, ctx, cb) {
      const jwt = require('jsonwebtoken@7.1.9');
      const jwksClient = require('jwks-rsa@1.1.1');
    
      const client = jwksClient({
        jwksUri: 'https://appleid.apple.com/auth/keys',
        cache: true
      });
    
      const idToken = ctx.id_token;
      const decoded = jwt.decode(idToken, {complete: true});
      const {kid, alg} = decoded.header;

      client.getSigningKey(kid, (err, key) => {
        if (err) {
          console.log(err);
          return callback(err);
        }
        const signingKey = key.publicKey || key.rsaPublicKey;
    
        jwt.verify(idToken, signingKey, {
          issuer: 'https://appleid.apple.com',
          audience: 'com.mycustomdomain.webapp',
          algorithms: [alg]
        }, (err, profile) => {
          if (err) return cb(err);
          profile.id = profile.sub;
          cb(null, profile);
        });
      });
    }
    ```
* **Authorization URL:** `https://appleid.apple.com/auth/authorize`
* **Token URL:** `https://appleid.apple.com/auth/token`
* **Scope:** `email name`
* **Custom Headers:**
    
    ```json
    {
      "UserAgent": "Auth0",
      "Accepts": "application/json"
    }
    ```

Once you have everything filled out correctly, click **Create** and enable this connection for your application.

And that's it for set up! 

## Using Sign In with Apple

To try it out, make sure your application is running and give it a visit. When you visit your login page,  you should now see an option for Sign In with Apple:

![Login page](https://images.ctfassets.net/23aumh6u8s0i/4koCt6YbjXzQbGbt00affl/a0c196a8f93f3b7f6f4ea75e6adc01ab/login-page)

Click "Continue with Apple", then enter your Apple ID and password:

![Apple credentials](https://images.ctfassets.net/23aumh6u8s0i/7C7TdNTFutvWyWcdsdJsas/594d3a6de274f7f99c3f6827fea734bd/apple-credentials)

You will be asked to verify a new device. Click "Allow":

![Verify device](https://images.ctfassets.net/23aumh6u8s0i/ouXAZobxgZZKtkDR6NFtW/7b2d78d5242f42dd0586c1a73f29537c/verify-device)

Next you'll be given a verication code. Make a note of this code, click "Done", and then enter the code on the "Two-Factor Authentication" screen:

![2FA](https://images.ctfassets.net/23aumh6u8s0i/52IPsCq25vPdRzE9MpYuuO/fa6dd59fb20d9aafb8f81caa8ae02545/2FA)

When this is done, you'll have the option to edit your name and choose whether you'd like to share or hide your email. Make your choice, then click "Continue":

![Email preferences](https://images.ctfassets.net/23aumh6u8s0i/4wtIHL0LNQqhTd6SsKU5x4/1db29403d5c797a22693e1b290a7a787/email-preferences)

You are now signed in with Apple!

![Logged in](https://images.ctfassets.net/23aumh6u8s0i/7J3lSENs4GOIGkfaCe269P/497f957787a9de1e4a2db66987836897/logged-in)

## Coming Soon

We’re working hard to add Sign In with Apple as one of our core integrations, which will make supporting this option in your application as [easy as turning on a switch](https://auth0.com/learn/social-login/). Stay tuned!





Implement Sign In with Apple using Auth0 Extensibility

Learn about Sign In with Apple, the new identity provider announced at Apple WWDC 2019.

Sign In with Apple: Learn About the New Identity Provider

Everything you always wanted to know (but were afraid to ask)

OAuth2 Implicit Grant and SPA

ramiro

I am an internet guy who loves reading and asking questions—those are the two things that helped me the most as an autodidact 🤓. If I am not learning about the latest trends in digital marketing or listening to house music, you can probably find me watching a tennis tournament. And also, I manage Social Media at Auth0 ✌️

Manager, Social Media

Ramiro Nunez Dosio

Our 10 most-popular identity posts in 2018 ranging from auth standards to web authentication.



Time flies when you are having fun. It's December already and we are getting ready to wrap up this year. 2018 was a prolific year for the Auth0 blog: we published more than 200 posts (😱) where we tackled a diverse amount of topics: frontend and backend technologies, data breaches, GDPR, Cybersecurity, Company Culture, and of course, Identity.

We believe looking back is key to look ahead. That is why this week, we are going to take a look back at the best and most impactful posts we have published in 2018.

One article wouldn't be enough to review this amazing year, that's why we have decided to split this year in review into 3 parts: [Developer Posts](https://auth0.com/blog/10-most-popular-developer-posts-in-2018/), [Security Posts](https://auth0.com/blog/10-most-popular-security-posts-in-2018/), and Identity Posts.

Without much further ado, here's the roundup of our 10 most-popular Identity posts this year!

![Auth0's 10 Most-Popular Identity Posts](https://images.ctfassets.net/23aumh6u8s0i/2PZojrBsthRTB6sKxDI0nw/cf5db7303eafa89f7ef46b4bc5f05e81/identity-posts)

## Auth0's 10 Most-Popular Identity Posts in 2018

> The following posts are not listed in any particular order.

1. <a href="#an-overview-of-open-standards" target="_self">An Overview of Open Standards</a>
2. <a href="#3-iam-examples-to-support-digital-transformation" target="_self">3 IAM Examples to Support Digital Transformation</a>
3. <a href="#a-look-at-the-draft-for-jwt-best-current-practices" target="_self">A Look at The Draft for JWT Best Current Practices</a>
4. <a href="#introduction-to-web-authentication-the-new-w3c-spec" target="_self">Introduction to Web Authentication: The New W3C Spec</a>
5. <a href="#how-to-have-a-successful-idm-project" target="_self">How To Have a Successful IDM Project</a>
6. <a href="#how-to-have-a-successful-idm-project-part-2" target="_self">How To Have a Successful IDM Project (Part 2)</a>
7. <a href="#on-the-nature-of-oauth2s-scopes" target="_self">On The Nature of OAuth2’s Scopes</a>
8. <a href="#hashing-passwords-one-way-road-to-security" target="_self">Hashing Passwords: One-Way Road to Security</a>
9. <a href="#adding-salt-to-hashing-a-better-way-to-store-passwords" target="_self">Adding Salt to Hashing: A Better Way to Store Passwords</a>
10. <a href="#how-utilities-can-use-ciam-to-avoid-3-common-problems" target="_self">How Utilities Can Use CIAM to Avoid 3 Common Problems</a>

## <a name="an-overview-of-open-standards"></a>1. [An Overview of Open Standards](https://auth0.com/blog/an-overview-of-open-standards/)

In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="ClickImg" externalUrl="https://auth0.com/blog/an-overview-of-open-standards/" imgUrl="https://cdn.auth0.com/blog/10-most-popular-identity-posts-in-2018/open-certificationpng.png" altText="Open Certification" imgWidth="560" imgHeight="560"/>

## <a name="3-iam-examples-to-support-digital-transformation"></a>2. [3 IAM Examples to Support Digital Transformation](https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/)

From basic website authentication to implementing an OpenID Connect server and API authentication: This article covers 3 IAM examples to support your Digital Transformation.

<include src="ClickImg" externalUrl="https://auth0.com/blog/3-iam-examples-to-support-digital-transformation/" imgUrl="https://cdn.auth0.com/blog/iam-digital-transform/sso-data-model.png" altText="SSO Data Model" imgWidth="714" imgHeight="559"/>

## <a name="a-look-at-the-draft-for-jwt-best-current-practices"></a>3. [A Look at The Draft for JWT Best Current Practices](https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/)

In this post, we will take a look at the draft for the JWT Best Current Practices document. This document describes common pitfalls and attacks related to the use of JWTs, and how to implement mitigations against them. Read on!

<include src="ClickImg" externalUrl="https://auth0.com/blog/a-look-at-the-latest-draft-for-jwt-bcp/" imgUrl="https://cdn.auth0.com/blog/jwt-bcp/Substitution-Attack-Different-Recipient.png" altText="Different Recipient JWT Substitution Attack" imgWidth="590" imgHeight="492"/>

## <a name="introduction-to-web-authentication-the-new-w3c-spec"></a>4. [Introduction to Web Authentication: The New W3C Spec](https://auth0.com/blog/introduction-to-web-authentication/)

Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. Learn why Google, Paypal, Mozilla, and others back it up.

<include src="ClickImg" externalUrl="https://auth0.com/blog/introduction-to-web-authentication/" imgUrl="https://cdn.auth0.com/blog/webauthn/1-Web-Authentication-Entities.png" altText="Web Authentication Entities" imgWidth="617" imgHeight="409"/>

## <a name="how-to-have-a-successful-idm-project"></a>5. [How To Have a Successful IDM Project](https://auth0.com/blog/how-to-have-a-successful-idm-project/)

Learn how to create a realistic project plan to have a good Identity Management project deployment.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project/" imgUrl="https://cdn.auth0.com/blog/good-idm-project/enabling-mfa.png" altText="Eanbling Multi-factor Authentication (MFA) from Auth0" imgWidth="617" imgHeight="361"/>

## <a name="how-to-have-a-successful-idm-project-part-2"></a>6. [How To Have a Successful IDM Project (Part 2)](https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/)

Learn how to plan for failures and changes in your identity project.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-to-have-a-successful-idm-project-part-2/" imgUrl="https://cdn.auth0.com/blog/how-to-have-a-successful-idm-project-part-2/resetting-a-users-multi-factor-account-with-auth0.png" altText="Resetting a user's multi-factor account" imgWidth="617" imgHeight="439"/>

## <a name="on-the-nature-of-oauth2s-scopes"></a>7. [On The Nature of OAuth2’s Scopes](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/)

Auth0 Principal Architect and Identity expert Vittorio Bertocci on why using OAuth2 scopes in every authorization scenario is not a good idea.

<include src="ClickImg" externalUrl="https://auth0.com/blog/on-the-nature-of-oauth2-scopes/" imgUrl="https://cdn.auth0.com/blog/on-the-nature-of-oauth2-scopes/oauth2-scopes-mail-api.png" altText="OAuth2 Scopes Mail API exmaple" imgWidth="617" imgHeight="280"/>

## <a name="hashing-passwords-one-way-road-to-security"></a>8. [Hashing Passwords: One-Way Road to Security](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/)

A strong password storage strategy is critical to mitigating data breaches that put the reputation of any organization in danger. Hashing is the foundation of secure password storage.

<include src="ClickImg" externalUrl="https://auth0.com/blog/hashing-passwords-one-way-road-to-security/" imgUrl="https://cdn.auth0.com/blog/hashing-one-way-road-to-security/hash-flow.png" altText="Hashing algorithm flow example - one-way" imgWidth="617" imgHeight="340"/>

## <a name="adding-salt-to-hashing-a-better-way-to-store-passwords"></a>9. [Adding Salt to Hashing: A Better Way to Store Passwords](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/)

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and to mitigate password attacks like rainbow tables

<include src="ClickImg" externalUrl="https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/" imgUrl="https://cdn.auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/password-salt-example.png" altText="Example showing how using a salt with hashing produces unique hashes." imgWidth="617" imgHeight="277"/>

## <a name="how-utilities-can-use-ciam-to-avoid-3-common-problems"></a>10. [How Utilities Can Use CIAM to Avoid 3 Common Problems](https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/)

Customer identity and management technology helps utilities reshape how they interact with users, improve their services, and tighten security.

<include src="ClickImg" externalUrl="https://auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/" imgUrl="https://cdn.auth0.com/blog/how-utilities-can-use-ciam-to-avoid-3-common-problems/progressive-profiling-flow.png" altText="Utility customer progressive profiling flow" imgWidth="617" imgHeight="303"/>

## What's Next?

We are already preparing our content pipeline for 2019. Identity and digital transformation are key areas that will keep businesses evolving to tackle challenges around privacy, usability, growth, and sociopolitical policies. We are committed to keep our content relevant to these changes and offer effective solutions through our products and services.

We'd like to take this opportunity to thank all of our readers for their consistent support and feedback. Is there anything that you'd like us to cover in 2019? Any particular identity topic or trend? Please let us know in the comments below or through social media ([Twitter](https://twitter.com/auth0), [LinkedIn](https://www.linkedin.com/company/auth0)). As always, you can subscribe to our newsletter to receive a weekly digest of our blog content.

Happy Holiday Season!

<include src="asides/AboutAuth0" />


10 Most-Popular Identity Posts in 2018

olususi-oluyemi

Oluyemi is a tech enthusiast with a background in Telecommunication Engineering. He ventured into programming with a keen interest in solving day-to-day problems encountered by users. He has since directed his problem-solving skills towards building software for both the web and mobile platforms. As a full-stack software engineer with a passion for sharing knowledge, Oluyemi has published many technical articles and content on several blogs worldwide. As s tech-savvy person, his hobbies include trying out new programming languages and frameworks.

Software Engineer / Technical Content Creator

Olususi Oluyemi

Learn how to create modern and secure applications with two mainstream technologies: React and Symfony. Also, secure the frontend/backend of the app by adding authentication.

Developing Modern Apps with Symfony and React

332d7898dae6bc56031ac3507a0248ba

I'm a full-stack developer with a passion for technology and code. I love writing tutorials for developers to showcase a particular technology whilst building something useful at the same time. Right now  I can mostly be found developing for the front-end, playing around with Docker, or tinkering with Unreal Engine and electronics!

Developer Experience Engineer

Steve Hobbs

Learn how to build APIs with Scala and the Play Framework, and secure them using access tokens.

"oauth"