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

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).

### 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

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

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)?

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

Implementing OpenID Connect authentication in Java Web Applications with Okta Spring Boot Starter and Spring Security support for Authorization Code Flow with PKCE

Proof Key for Code Exchange (PKCE) in Web Applications with Spring Security

Should you use cookie-based or token-based authentication in ASP.NET Core Identity? Or should you use JWT and OpenID Connect?

.NET 8 has been released and many new exciting features are available to developers. In particular, this release brings [new options for authentication and authorization for ASP.NET Core Identity](https://auth0.com/blog/whats-new-dotnet8-authentication-authorization/). While these features have been long awaited, it seems that not everyone is happy with Microsoft's implementation choices, and there is some confusion among developers about the proper approach to use in their ASP.NET Core Identity-based applications. Let's try to shed some light on this not-so-simple topic.

## ASP.NET Core Identity: What’s New

One of the most criticized features of ASP.NET Core Identity until .NET 7 has been [its lack of *modern* authentication support for Single Page Applications](https://github.com/dotnet/aspnetcore/issues/42158). Whatever *modern* means, [ASP.NET Core Identity](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity) has provided support for cookie-based authentication since version 3.1. It has also provided a set of web pages that allow users to register, authenticate, recover passwords, etc.

However, the current trend in authentication for SPAs seems to be token-based rather than cookie-based, and ASP.NET Core Identity didn't support it. The only option provided with the built-in SPA templates was based on Identity Server, a third-party [OpenID Connect](https://openid.net/developers/how-connect-works/) server. This approach has been [deemed excessive for small projects](https://github.com/dotnet/aspnetcore/issues/42158#issuecomment-1153222403) by several developers, and in any case introduces a third-party dependency that not everyone may want.

To address this issue, .NET 8 introduces support for token-based authentication and a set of [Identity API endpoints](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization) that let developers do through the API what they could already do through the old-style web pages.

> To learn more about [the new authentication and authorization features introduced by .NET 8, read this article](https://auth0.com/blog/whats-new-dotnet8-authentication-authorization).

Awesome! So the problem is fixed and we all live happily ever after.🎉

In fact, things are not quite like that. Some developers are not entirely happy. There are those who expected a different implementation, and those who are now confused about the correct use of the new options. Let's try to bring some order to all this confusion.

> Disclaimer: This article is not a step-by-step tutorial on how to add ASP.NET Core Identity to your application. Its purpose is to discuss the authentication modes that it supports as of .NET 8.0.

## Cookie or Token-based Authentication?

Now ASP.NET Core Identity provides you with two authentication options: cookie-based and token-based. But what is the actual difference between the two approaches?

### Cookie-based authentication

Cookie-based authentication is the typical approach used by the traditional server-side rendered web page model. This is the model used by ASP.NET Core MVC and Razor Pages, to put it bluntly. In this type of authentication, a server-generated cookie proves successful user authentication and represents the user session.

> To learn more about [the relationship between cookies and sessions, read this article](https://dev.to/andychiare/sessions-tokens-and-rocknroll-4pdc).

Roughly, the cookie-based authentication flow is as follows:

1. The user authenticates through a web page.
2. The server generates a cookie and sends it to the browser with the response page.
3. The browser sends the cookie with each new page request.
4. If the server finds the cookie in the incoming request, it can use it to get the relevant information to make its authorization decisions.

The fun fact is that the cookie's back and forth is automatically managed by the browser. Provided that the server applies all [the security best practices](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#cookies) to protect its cookies, your application doesn't need to care about storing them and sending them back with each request.

### Token-based authentication

Token-based authentication doesn't rely on cookies to prove user authentication. It relies on a token, which is a unique string of characters that also represents the user's session.

> To learn more about [how tokens help build sessions, check out this article](https://dev.to/andychiare/sessions-tokens-and-rocknroll-4pdc).

Awesome! How does the token-based flow work? Here is a rough description:

1. The user authenticates via a client-side page that calls the login endpoint.
2. The server generates a token and sends it to the app in the login endpoint's response.
3. The app sends the token with each new HTTP request.
4. If the server finds the token in the incoming request, it can use it to get the relevant information to make its authorization decisions.

As you can see, this flow is basically the same as the cookie-based flow. The only difference is that this one mentions the token instead of the cookie. So what is the real difference between the two approaches?

<details>
  <summary>What does authentication mean in this context?</summary>

If you are an experienced developer, you should already know the difference between **authentication** and **authorization**. Very roughly, authentication verifies the identity of the user while authorization verifies what the user can do.

Cookie-based authentication and token-based authentication are somewhat ambiguous terms. In fact, in this context, the cookie and the token indicate that the user has been successfully authenticated. However, they are used to make authorization decisions. When the server receives a request from a client, it checks if a cookie or a token is included in it. If so, the cookie or the token allows the server to somehow retrieve information to determine whether or not the request can be fulfilled. This information may also include the user profile data, of course. The specific way used to retrieve this information does not really matter.

This means that there is no real user authentication when sending a request to the server. User authentication has already taken place at the beginning of the session.
</details>

### Cookies and tokens: a quick comparison

As you learned in the previous sections, cookie-based and token-based authentication are very similar. The main visible difference is the artifact they rely on to prove authentication and support session creation. However, there are significant differences. I will not go into a detailed comparison between cookies and tokens, but I can't help but mention at least the following:

- **Cookies** are *tied to a domain*, require *little storage*, and are *automatically managed by the browser*. However, without proper precautions, they are vulnerable to [CSRF](https://auth0.com/blog/cross-site-request-forgery-csrf/) and [XSS attacks](https://auth0.com/blog/cross-site-scripting-xss/), are *not suitable for multi-domain applications*, and have *scalability issues*.
- **Tokens** are *not tied to only web applications* and they *promote server scalability*. However, *their management and security is left to the developer*. Depending on the type of token, there may be an *invalidation problem*, i.e. a revoked token may still be used by the client, and a *data transfer overhead* if the token size becomes significant.

> It's worth noting that while cookies in general can lead to scalability issues when used as pointers to server-side data, this is not the case with the authentication cookie issued by ASP.NET Core Identity. By default, this cookie contains encrypted data that allows the server to retrieve the user's identity information without having to access a server-side store. However, you need to [properly configure your servers](https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview) in order to share the same encryption/decryption key.

That said, when should you use one type of authentication over the other?

### Which authentication type to use?

There's a common belief that cookie-based authentication should be used for traditional server-side page-rendered applications, while token-based authentication is for SPAs and native applications.

Actually, the ASP.NET Core Identity framework uses the cookie-based authentication approach for ASP.NET Core MVC and Razor Pages applications. With these types of applications, each request triggers a complete reload of the entire web page in the browser. In previous versions of .NET, if you wanted to leverage the ASP.NET Core Identity built-in authentication pages in your SPA, the user experience would be disrupted. Users would pass from the partial page reload experience typical of a SPA to a full page reload experience. This is one of the reasons behind the request of token-based authentication from many developers. They feel that having a token and a set of authentication APIs, such as the Identity API, allows them to build a consistent user experience for SPAs. In addition, this API can also be used by native applications, i.e., desktop and mobile applications, which were excluded by the traditional cookie-based approach.

This criterion may seem reasonable, but...

## Wait! Identity API Endpoints Have Cookies Too?

So, in general, you might think that cookie-based authentication is meant for traditional server-rendered applications, while token-based authentication is meant for SPAs and native applications.

However, if you dig into [the currently sparse documentation](https://devblogs.microsoft.com/dotnet/whats-new-with-identity-in-dotnet-8/#securing-blazor-webassembly-apps), you will find that you can call the authentication endpoint (`/login`) with the `useCookies=true` parameter. In other words, you can call the following endpoint: `/login?useCookies=true`. What does this mean? What scenario does it cover?

Well, despite many developers thinking that SPA should use token-based authentication, this is not always the case. Think about this for a moment:

- Why should you use tokens and manage the back-and-forth and their security when you can use cookies to take advantage of the built-in capabilities of browsers?
- What can you do with a token that you can't do with a cookie?
- In other words, do you really need a token in your specific scenario?

As a general rule, you should use the right tool for your specific needs. Over-designing or following common sense can lead to extra work and possible risks because you have to worry about token security.

If the client of your Web API application is a native client, you are forced to use token-based authentication. Supporting cookies in native applications would be impractical. However, you can use cookies in your SPA. Provided that your application lives in a single domain, you can use cookies and their automatic management by browsers. Why not?

If your application consists of a SPA and a Web API, and you authenticate users locally using ASP.NET Core Identity, you should use cookie-based authentication. Technically, your application is a first-party application, and even [OAuth best practices](https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html#section-6.1) recommend using this approach.

## Why Are These Tokens Not JWTs?

Another common misconception is that *token* means *JSON Web Token* (JWT). I've seen many developers react as shown in the following picture when they learn that the token issued by the Identity API is not in JWT format:

![Why not JWT?](https://images.ctfassets.net/23aumh6u8s0i/4CaZUMohAdvA2AiEDtfGjx/6585793bf36b74b70f29610f448ceb97/why-not-jwt.png)

Actually, that token has a proprietary format, although you can partially decode it. Read [this article](https://nestenius.se/2023/08/29/bearertoken-the-new-authentication-handler-in-net-8/) if you want to learn more about what's inside the access and refresh tokens issued by the Identity API.

Again, why do developers think the JWT format would have been better in this context? If your application is a first-party application in the authentication context, why do you need JWT?

The JWT format was invented to share information between two trusted parties. In the authentication and authorization context, a typical example of JWT adoption is when a third-party entity authenticates or authorizes a user. In this case, the third-party entity (the Identity provider or authorization server) issues a JWT containing the information related to the authentication or authorization result.

The need for a JWT arises from the fact that the third-party entity and your application are independent; they do not share a common data source.

Your application receives the result of the requested operation in the form of a JWT and it can verify that this information was actually issued by that entity by validating the token's signature. To be precise, only OpenID Connect defines a [JWT-based format for ID tokens](https://openid.net/specs/openid-connect-core-1_0.html#IDToken). OAuth 2.0 doesn't recommend [a specific format for access tokens](https://datatracker.ietf.org/doc/html/rfc6749#section-1.4), although [one is available](https://datatracker.ietf.org/doc/html/rfc9068).

> To learn more about [ID token and access token differences, see this article](https://auth0.com/blog/id-token-access-token-what-is-the-difference).

The point is, does your application really need the JWT format for access tokens? If so, your scenario may be different from what the Identity API was designed for. In a first-party scenario, your server should have all the information it needs to make authorization decisions.

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

## When Do You Need OpenID Connect and OAuth 2.0?

Developer reactions to the new Identity API make me think that they have been waiting for a built-in OpenID Connect and OAuth 2.0 implementation. They would probably expect Microsoft to have replaced Identity Server with its own OpenID Connect server. However, this may sound somewhat contradictory, since many have complained about the complexity of Identity Server in simple authentication scenarios.

Leaving aside speculation about what some developers expected, .NET 8 and its version of ASP.NET Core Identity is now here with its new authentication options. When should you use it in your applications and when do you need OpenID Connect and OAuth 2.0?

ASP.NET Core Identity can be the right solution if you need to build an application with basic authentication needs. Your users are authenticated locally, you don't expect much traffic and therefore don't plan to scale anytime soon, you don't have complex custom authentication needs. You can also integrate with external identity providers. I recommend using cookie-based authentication for web applications (including SPAs) and token-based authentication only for native apps.

OpenID Connect comes into play when your needs go beyond a simple authentication. You should look for a standards-compliant Identity provider if you need [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on) (SSO), for example. If you expose your API to third parties, you can leverage the benefits of a standard authorization approach such as OAuth 2.0. In these cases, ASP.NET Core Identity is not a good fit.

Check [this document](https://learn.microsoft.com/en-us/aspnet/core/security/how-to-choose-identity-solution?view=aspnetcore-8.0) for some guidance on when ASP.NET Core Identity is sufficient or when you need an OpenID Connect server.

## Some Caveats About Identity API Endpoints

The discussion so far is intended to help you make the right choices for authentication in your .NET applications based on your specific application scenario. This will help you avoid overdesign and make an informed choice about the right approach.

If you have decided to use the Identity API for your SPA and native application, there are still a few caveats that you still need to be aware of.

The Identity API is a great addition that allows you to leverage the user authentication and management under the hood, while you can customize your own UI. However, there is currently no way to make its endpoints unavailable. All Identity API endpoints are exposed. For example, anyone can call the `/register` endpoint to create a new user, regardless your application's business logic expects self-registered users or not. Presumably this will be fixed in the future, but as for .NET 8, it's like this.

A second concern is that you can't customize the Identity API endpoints. In most cases, you may not need customization, but what can you do if you need to customize the data required in the `/registration` endpoint? Or even add an unsupported authentication method, such as [WebAuthn](https://webauthn.me/introduction)?

Include these questions in your ASP.NET Core Identity evaluation.

<include src="SignupCTA" />

## Recap

In summary, .NET 8 brings exciting new features to ASP.NET Core Identity: token-based authentication and the Identity API.

However, this does not mean that they are the right approach for your specific scenario. Take some time to analyze what you need right now and in the near future. Don't follow the trend without carefully analyzing your needs and what ASP.NET Core Identity can offer you. You probably don't need token-based authentication for your SPA. Perhaps the simple token format for the Identity API is enough for your needs.

Anyway, if your analysis leads you to use OpenID Connect, don't forget that [Auth0 can help you](https://a0.to/blog_signup)! 😎


Cookies, Tokens, or JWTs? The ASP.NET Core Identity Dilemma

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

Use Jakarta EE 10 to build a secure Java web application using OpenID Connect and Auth0.

Use Jakarta EE 10 with OpenID Connect Authentication

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

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

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

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

Build an Ionic + Angular frontend for your Spring Boot backend, all using the power of JHipster! Secured by OpenID Connect.

Build Secure Ionic Apps with Angular and JHipster

This tutorial shows you how to add authentication to your Angular App with Auth0

AngularJS 1.0 was released in October 2010. At the time, it was considered one of the most revolutionary and popular web frameworks ever to see the light of day. Developers loved it, and created many apps with it. However, as a pioneer in the JS framework space, AngularJS had some growing pains and significant issues. The team went back to the drawing board for a major breaking release with Angular 2. It took two years to develop and influenced many devs to hop onto other frameworks in the meantime.

Today, five years after Angular 2 was released, we just call it “Angular” and its version numbers have far less meaning. Five years is a long time for a modern JS web framework to live and thrive. If you look at the number of Stack Overflow questions, you’ll see that users struggle with React far more than Angular.

![hotframeworks.com](https://images.ctfassets.net/23aumh6u8s0i/59q6jcF1y3liZ2s5dHjFZ1/ff4258bdeac2cad19506a693b21c7e46/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

I kid, I kid. 😅

I don’t think Stack Overflow tags indicate that developers have a hard time with the framework; I think they indicate a thriving community. The more people use technology, the more they submit questions for it.

[hotframeworks.com](https://hotframeworks.com/) lists a score that combines GitHub stars with Stack Overflow tags and says the top six web frameworks are as follows (at the time of this writing):

1. React
2. ASP.NET MVC
3. Angular
4. Ruby on Rails
5. AngularJS
6. Vue.js

Angular is still very popular among developers. If you’re developing an Angular app today, you probably need a way to authenticate your users. That’s where OpenID Connect (OIDC) can help you. OIDC is a layer on top of OAuth 2.0 that provides identity.

In this tutorial, I'll show you how to add OIDC authentication with Auth0 to a new Angular app in just a few steps.

### Prerequisites:

* A favorite text editor or IDE. I recommend [IntelliJ IDEA](https://www.jetbrains.com/idea/), but I know many JavaScript developers prefer [Visual Studio Code](https://code.visualstudio.com/).
* [Node.js](http://nodejs.org/) v14+ and npm installed.

If you would rather follow along by watching a video, check out the screencast below from [the OktaDev YouTube channel](https://youtu.be/YiR7XFgsD8w).

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

## Create an Angular App

First, you’ll need to create a new Angular app with routing enabled. Install the Angular CLI globally, then create an app.

```shell
npm i -g @angular/cli@13
ng new auth0-demo --routing
```

You’ll be prompted to select your favorite stylesheet format. The selection you make doesn’t matter for this example since we’re focused on functionality rather than updating visuals.

## Add Authentication with OpenID Connect

To add authentication with Auth0, you’ll first need a [free Auth0 account](https://a0.to/blog_signup). Install the [Auth0 CLI](https://github.com/auth0/auth0-cli#installation) and run `auth0 login` to register your account. Then, run `auth0 apps create`. Use the name `auth0-demo` and specify a description of your choosing. Select Single Page Web Application and use `http://localhost:4200/home` for the Callback URL. Specify `http://localhost:4200` for the rest of the URLs. We’re using 4200 as the port here because that’s the default for local Angular development.

![Auth0 Apps Create](https://images.ctfassets.net/23aumh6u8s0i/6treCQmKthgFUfWwzf3AfL/79c7378cb41c2b7fcdc603f7787b493e/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

You can also use the Auth0 Console to create an OIDC app:

* [Log in](https://auth0.com/auth/login) to Auth0 or [create an account](https://a0.to/blog_signup) if you don’t have one. Go to **Applications** > **Create Application**.
* Choose **Single Page Web Applications** as the application type and click **Create**.
* Click **Angular**, then the **Settings** tab.
* Add `http://localhost:4200/home` as an Allowed Callback URL and `http://localhost:4200` as a Logout URL.
* Specify `http://localhost:4200` as an Allowed Origin and click **Save Changes** at the bottom.

Once you have a new Angular app and Auth0 OIDC set up, you can use [OktaDev Schematics](https://github.com/oktadev/schematics#angular--auth0) to add OAuth 2.0 and OIDC support to your Angular app. Be sure to execute this command in the folder for the app itself (`auth0-demo`) adjacent to `package.json`.

```shell
ng add @oktadev/schematics --auth0
```

The Auth0 CLI will prompt you for an issuer URL and client ID, which were displayed when setting up the app in Auth0. If you used the CLI, it would have shown the issuer URL right above the client ID.

```shell
=== dev-0ua1y-go.us.auth0.com application created

  CLIENT ID            TJgZxGnlSkqUe6JfMFSipZcFsbpl6LS2
```

This process will perform the following steps for you:

1. Install the [Auth0 Angular SDK](https://github.com/auth0/auth0-angular).
2. Add `src/app/auth-routing.module.ts` with your OIDC configuration and initialization logic.
3. Configure an `AuthHttpInterceptor` that adds an `Authorization` header with an access token to outbound requests.
4. Create a `HomeComponent` and configure it with authentication logic.
5. Update unit tests for `AppComponent` and `HomeComponent` to mock Auth0.

To see all the changes it makes to your files, see [this pull request on GitHub](https://github.com/oktadev/auth0-angular-example/pull/1/files). If you’re interested in learning more about Schematics, I recommend reading my [Use Angular Schematics to Simplify Your Life](https://developer.okta.com/blog/2019/02/13/angular-schematics) tutorial.

### Test your Angular authentication flow

Run `ng serve` in your app, and you should see a login button at `http://localhost:4200/home`.

![Auth0 Login button](https://images.ctfassets.net/23aumh6u8s0i/50ajbMEhMjKTlo8FFIrhcc/34ab5bd3e71ef2098232c1fa17094f7a/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

Click the **Login** button and sign in with one of the configured users for your Auth0 application. Because this is just a demo, you probably haven’t done that - more likely, you should sign up as a new user.

![Auth0 Login form](https://images.ctfassets.net/23aumh6u8s0i/4k6lvyaFm08105rMKbngMK/04946fb269344caaa466e995895816ee/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

After login, you’ll be redirected back to your app, and you’ll see a **Logout** button displayed in the bottom left corner.

![Auth0 Logout button](https://images.ctfassets.net/23aumh6u8s0i/4wmWthcAoznrbP7iP9qQ6T/38b2188e91decdbdd2a3046a57410369/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

### Display the authenticated user’s name

To display the authenticated user’s name, you can use the `user$` observable on the `AuthService` instance.

Modify `src/app/home/home.component.html` to display a welcome message to the user.

```html
<div>
  <button *ngIf="(auth.isAuthenticated$ | async) === false" (click)="login()" id="login">Login</button>
  <div *ngIf="auth.user$ | async as user">
    <h2>Welcome, {{user?.name}}!</h2>
  </div>
  <button *ngIf="auth.isAuthenticated$ | async" (click)="logout()" id="logout">Logout</button>
</div>
```

Refresh your app, and you should see your name displayed.

![Display user's name](https://images.ctfassets.net/23aumh6u8s0i/40JjOQXUidYCgMIWgDYSdT/b012e9c1c44d0397f89145dc00521053/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly)

If everything works—congrats!

## Learn more about Angular and OpenID Connect

I hope you enjoyed this quick tutorial on using Auth0 and OIDC for authentication in your Angular apps. If you’re looking for a more detailed step-by-step tutorial, please read [The Complete Guide to Angular User Authentication with Auth0](https://auth0.com/blog/complete-guide-to-angular-user-authentication/).

You can find the source code for the example on GitHub in the [@oktadev/auth0-angular-example](https://github.com/oktadev/auth0-angular-example) repository.

To learn more about Angular and OIDC, check out the following blog posts:

* [What You Need to Know about Angular v13](https://developer.okta.com/blog/2021/11/10/angular-v13)
* [The Things to Keep in Mind about Auth](https://developer.okta.com/blog/2021/10/29/things-to-keep-in-mind-about-auth)
* [A Quick Guide to Angular and GraphQL](https://developer.okta.com/blog/2021/10/22/angular-graphql)

<br>
<img src="https://images.ctfassets.net/23aumh6u8s0i/2FKsfPuzkEluf4MALzOoLT/969e1b0d6b58723b2bf263a8799c5cd6/Uploaded_from_Add_OpenID_Connect_to_Angular_Apps_Quickly" alt="The Angular Mini-Book" width="392" height="512">
<p align="center"><i><a href="https://www.infoq.com/minibooks/angular-mini-book/">The Angular Mini-Book</a></i></p>
<p align="left"></p>

I [just published a mini-book book on Angular](https://raibledesigns.com/rd/entry/the_angular_mini_book_1) that might interest you too. It's called [The Angular Mini-Book](https://www.infoq.com/minibooks/angular-mini-book/) and is available as a free download from InfoQ. The book is written tutorial-style and shows you how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication. You'll also learn how to integrate Angular with Spring Boot (a popular REST API framework) and use security best practices like HTTPS and a content security policy.

If you liked this tutorial, chances are you'll like others we publish. Please follow [Auth0](https://twitter.com/auth0) and [OktaDev](https://twitter.com/oktadev) on Twitter to get notified when we publish new developer tutorials.

Add OpenID Connect to Angular Apps Quickly

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?

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

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

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Highly-rated identity specifications and trends podcast concludes season one; season two to launch in January 2021



**BELLEVUE, Wash. – Dec. 17, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that the [OpenID Foundation](https://openid.net/foundation/) will be the exclusive sponsor for season two of Auth0's flagship podcast ['Identity, Unlocked,'](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/025d70b9?utm_source=podcast&utm_medium=pr&utm_campaign=identity-unlocked) scheduled to release in January 2021. Auth0 and the OpenID Foundation will bring their shared goals around promoting awareness, understanding, and adoption of open identity standards to the podcast in an effort to make identity more accessible.

Hosted by Vittorio Bertocci, identity expert and principal architect at Auth0, 'Identity, Unlocked' features conversations with identity thought leaders and explores the latest specifications and trends from a developer's perspective, making identity more accessible to everyone. [Season one](https://auth0.com/blog/auth0-launches-identity-unlocked-the-identity-podcast-for-developers/) recently concluded and featured interviews with industry standards experts and identity thought leaders, including Brian Campbell, Dick Hardt, Pamela Dingle, and many others. 

Season two of 'Identity, Unlocked' will explore OpenID Connect specifications such as Financial-grade API (FAPI), Self-issued OpenID Connect (SIOP), and eKYC and Identity Assurance (IDA) to compliment the show's history of interviewing those directly involved in the creation of identity standards. In addition to the OpenID Connect specifications, 'Identity, Unlocked' will continue to explore various specifications and trends across the identity industry.

"Our hope is that the OpenID Foundation's sponsorship of the Auth0' Identity Unlocked' podcast will encourage further deep and diverse technical contributions to the open identity standards the Foundation has developed," said Don Thibeau, OpenID Foundation Executive Director. "This podcast will continue to educate and introduce a global community of contributors to working groups like the Financial-grade API (FAPI), eKYC-IDA, and others. The deep dive into these technologies on 'Identity Unlocked' is a priority for the OpenID Foundation and a unique resource for open standards development in 2021."

"Thank you to everyone involved in 'Identity, Unlocked' season one—we are grateful for the positive response we received during season one, and we look forward to collaborating on the second season in partnership with OpenID Foundation," said Martin Gontovnikas, SVP of Marketing and Growth at Auth0. "Open identity standards are of critical importance, and it is our goal to make identity more accessible to everyone, in an inclusive way."

To learn more about 'Identity, Unlocked,' visit [identityunlocked.com](http://identityunlocked.com/). To subscribe to the latest podcast updates and episodes, visit [Apple Podcasts](https://podcasts.apple.com/us/podcast/identity-unlocked/id1529010471) and [Spotify](https://open.spotify.com/show/1Y6XBZcVK45QijvV0o7RVs). 

## About Vittorio Bertocci

[Vittorio Bertocci](https://auth0.com/blog/authors/vittorio-bertocci/) is Principal Architect at Auth0 and applies his vast knowledge of the identity industry to Auth0 in all aspects of the company, including internal and external education, product innovation, and customer integration. Prior to Auth0, Bertocci spent 17 years at Microsoft, where he worked on the Azure Active Directory team and focused largely on improving the developer experience. As a published author of four identity books and a highly-trafficked blog: cloudidentity.com, his forward-thinking commentary has enabled him to speak at conferences, such as Identiverse, BUILD, PDC, TechEd, Cloud Identity Summit, and many other industry events around the world.

<include src="asides/AboutAuth0" />

### Media Contacts
Auth0 Global Communications <br />
[press@auth0.com](mailto:press@auth0.com) <br />
 
Matter for Auth0  <br />
[auth0@matternow.com](mailto:auth0@matternow.com)  <br />


OpenID Foundation to Sponsor Auth0's Identity, Unlocked Podcast

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

Learn how to add OpenID Connect authentication to your Express apps, using our just released express-OpenID-connect SDK



**TL;DR**: Today, Auth0 announces the release of [`express-openid-connect`](https://github.com/auth0/express-openid-connect), a new Node.js SDK that makes it super easy to add [OpenID Connect](https://auth0.com/docs/protocols/openid-connect-protocol) authentication to your Express apps. You can [install it using `npm`](https://www.npmjs.com/package/express-openid-connect) today.

Since Auth0 relies on open protocols to expose its features, you can use its services from any platform and app type, without requiring any proprietary SDK. Whenever a platform or a dev stack has a good, well-designed SDK, the [Auth0 Quickstarts](https://auth0.com/docs/quickstarts) simply use that &mdash; no need to reinvent the wheel!

When the targeted platform does not have a great experience available, we will often step in and create one. Historically, that’s what we have done for Node.js &mdash; a very special platform for us at Auth0, powering our very own authorization server, our extensibility model, and many of our samples.

About eight years ago, we provided an [Auth0 strategy for Passport.js](https://www.npmjs.com/package/passport-auth0), which has been downloaded more than 2M times and is still going strong. Despite its obvious success, however, our Passport strategy is starting to show its age. For example:

* It requires more code to initialize and use authentication features than is strictly necessary.
* It brings significant dependencies into your app, a burden that many developers might want to avoid.
* It is Auth0 specific, whereas Auth0’s web sign-on function can be easily achieved with pure OpenID Connect.

That’s why we decided to create a new Node.js SDK that is ultra-easy to use, nimble, and standard-based, providing a great experience to Node.js developers, not just when using Auth0, but with any provider that uses OpenID Connect.

## Adding Web Sign-On to a Node.js App Really Fast

Before we get into the library’s architecture, let me just give you a quick taste of what it feels like to use [`express-openid-connect`](https://github.com/auth0/express-openid-connect) to add web sign on to a Node.js web app.
 
Adding `express-openid-connect` to your project is straightforward:

``` bash  
$ npm init -f
$ npm install auth0/express-openid-connect express dotenv 
```

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://<YOURTENANT>.auth0.com
CLIENT_ID=<YOURCLIENTID>
BASE_URL=https://localhost
SECRET=<LONGRANDOMSTRING>
```

All the `<>` values need to be updated with the details of your tenant app, that you’ll find in the Auth0 Dashboard. In this example, we assume that your Allowed Callbacks URLs include [`https://localhost/callback`](https://localhost/callback) (note, the `SECRET` is not your client secret &mdash; any long random string will do).

A diminutive `server.js` could look like the following:

``` javascript  
const express = require('express');
const { auth } = require('express-openid-connect');
require('dotenv').config();
const app = express();
app.use(auth());
app.get('/', (req, res) => {
  res.send(`hello ${req.oidc.user.name}`);
});
app.set('trust proxy', true);
app.listen(3000, () => console.log('listening at http://localhost:3000'))
```

Note, this isn’t the absolute smallest app with web sign-in that you can write (I tweeted a [much smaller one](https://twitter.com/vibronet/status/1287776298920636421?s=20)), but it still gives an idea of how concise `express-openid-connect` code can be, while remaining perfectly readable. In a nutshell:

* Lines 1-3 pull in dependencies and load `.env`.
* Lines 4-5 initialize `express` and add `express-openid-connect` middleware in the pipeline. That will have the effect to protect every app route with OpenID Connect.
* Lines 6-8 define the behavior of the root route &mdash; showing the name of the authenticated user.
* Lines 9-10 start the app, enabling the use of a proxy.

I could have easily skipped the proxy part, but given that the [SameSite changes make HTTPS mandatory for `SameSite=none` cookies](https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/), it’s a good habit to start using HTTPS at development time anyway. See the ["HTTPS in Development" document](https://auth0.com/docs/libraries/secure-local-development) for more detailed instructions.

For our purposes, all you need to do is to install a reverse proxy like Caddy 2* (`$ brew install Caddy` or [https://caddyserver.com/docs/download](https://caddyserver.com/docs/download)) and launch it:

``` bash  
$ caddy reverse-proxy --from localhost:443 --to localhost:3000
```

All you need to do now is to launch your app with `node server.js` and navigate to [https://localhost](https://localhost/). You’ll see the familiar prompt and, once authenticated, the user greeting:

![authPrompt](https://images.ctfassets.net/23aumh6u8s0i/7EjGFggvxs3ZOCctng0XJA/3da0d378b994ad77700b9a642c0495e2/login_prompt)

That’s it! In barely one Word page, I gave you the complete instructions to build an authenticated web app from scratch, including explanations of what the code does and how to run it on HTTPS in `localhost`. Here’s a comparison with the code required by the Auth0 Passport.js strategy to achieve the same functionality:

![Passport Comparison](https://images.ctfassets.net/23aumh6u8s0i/1KVwAZ5Poh1FeUkLwNax4M/c34ea7a9de120d4acb0bd1acf8e33336/3-passportcomparison)

Looks great, but what’s really going on here? Let’s take a deeper look.

## The Architecture of `express-openid-connect`

In a nutshell: `express-openid-connect` is an application-level Express middleware, which implements the OpenID Connect protocol with the purpose of adding and managing authentication for your web application.

The middleware effectively wraps [`node-openid-client`](https://github.com/panva/node-openid-client), an [OpenID Connect certified](https://openid.net/certification/) client for Node.js maintained by our very own [Filip Skokan](https://auth0.com/blog/authors/filip-skokan/), which handles all the protocol concerns. As mentioned, you can use `express-openid-connect` with any OpenID Connect provider, not just Auth0. You’re welcome!

As a middleware, `express-openid-connect` is meant to implement a sign-in for a web application. That means that no matter what protocol flow is selected, the SDK will always want to end up with an `id_token` to validate and ultimately create a session for your web app.

Here’s a diagram describing what happens under the hood when an unauthenticated user attempts to access a protected app route, `/profile`, using the default settings demonstrated in the preceding section.

![login](https://images.ctfassets.net/23aumh6u8s0i/jQrfvs3dBaZDPn2FS2ojs/0d3458ea73357e7cf78f9213568ccfda/4-login)

As we’ve seen, you don’t need to grok all the fine details of that diagram to successfully use the SDK: but it’s a handy reference if you want to know how the standards are used and how the various components of the solution collaborate to achieve route protection and sign on. You can find this and other diagrams in the ["Architecture" section of the `express-openid-connect` documentation](https://github.com/auth0/express-openid-connect/blob/master/ARCHITECTURE.md).

The default OpenID Connect flow used by `express-openid-connect` is `implicit + form_post`, requesting `response_type=id_token` and `response_mode=form_post`. That’s the absolute simplest sign inflow to set up, as it doesn’t require client secrets (the secret you configured was for protecting the session cookie, no backend traffic, or registration required for it).

If, in addition to the `id_token`, you also want to obtain an access token to invoke protected API endpoints, the SDK allows you to choose the code or hybrid flow. All you need to do is to use the SDK config options to override the defaults.

If you want to go beyond the basics, `express-openid-connect` offers a very comprehensive [collection of configuration settings](https://auth0.github.io/express-openid-connect/) that allow you to control every aspect of how authentication occurs, including:

* Fine control over the session behavior (rolling, absolute, transient, or persistent, etc.),

* Fine control over authorization request characteristics (grants, whether to request access tokens for an external API together with the initial request, what scopes to request, etc.).

* Customization of the default routes used by the SDK for triggering authentication, sign out, etc

* ...and a lot more

As you’ve seen, the most common use case is super easy to implement. You initialize the middleware with the essential parameters, add it in the pipeline, and by default, everything is protected. That is to say, any attempt to access a route by an unauthenticated user will trigger the authentication dance.

If you don’t want blanket protection, you can elect to secure individual routes by setting `authRequired` to `false` and applying the `requiresAuth` middleware to individual routes.

Alternatively, you can initiate an authentication operation programmatically from anywhere via the SDK method `login`. If your authorization requirements are more complex, you can easily set up more sophisticated route protection logic. For example, you can configure a given route to be accessible only by users possessing specific claim types and values by using [`claimEquals`](https://auth0.github.io/express-openid-connect/globals.html#claimequals), [`claimInclude`](https://auth0.github.io/express-openid-connect/globals.html#claimincludes), or, for completely custom criteria, [`claimCheck`](https://auth0.github.io/express-openid-connect/globals.html#claimcheck).

The SDK comes with an essential [Express Quickstart](https://auth0.com/docs/quickstart/webapp/express), accompanied by a [sample](https://github.com/auth0-samples/auth0-express-webapp-sample) that shows how to accomplish more advanced tasks, such as obtaining access tokens for API or using and refreshing them when necessary.

## What’s Going to Happen to `passport-auth0`?

The answer is... nothing. Unless someone finds a security bug, that is. [`passport-auth0`](https://github.com/auth0/passport-auth0) is used and loved by many Auth0 customers &mdash; and remains fully supported. There’s no need to rush updates to your existing apps. We will keep fixing bugs and patch them. We plan to stop adding new features to `passport-auth0`, and the bar for the bugs we fix will be tuned accordingly. If you are about to start a new project, we recommend considering using `express-openid-connect`, as it will be our target for all innovation for web sign-in on the Node.js platform for the foreseeable future.

## What’s Next

There are many features we really want to add to `express-openid-connect` (hello, custom session persistence) that didn’t make it in time for this release. We’re already hard at work on those: if you have feedback, wish lists, pet peeves, now it’s the time to hit us up via the [Issues list](https://github.com/auth0/express-openid-connect/issues).

We are also planning to produce a similar SDK for Express APIs, giving Node.js API developers a way to enjoy the same ease of use and lightweight integration we achieved with `express-openid-connect`.

Happy coding!


Auth0’s express-OpenID-connect SDK: the Easiest Way to Do Authentication on Node.js

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

andrew-akers

I'm a product marketing manager who loves learning about technology, information security, and identity. My goal is to turn that knowledge into positive outcomes for our customers. Before Auth0, I was a product marketing manager at Cisco in the network security division. In my spare time, you can find me spending time with my family, reading, writing, and working on endless home improvement projects.

Product Marketing Manager

Andrew Akers

This release will make it simple to federate authentication to identity providers that support OIDC.



**TL; DR**: OpenID Connect (OIDC) support has been released as a beta Enterprise Connection in Auth0. This release will make it simple to federate authentication to identity providers that support OIDC.

<include src="TweetQuote" quoteText="#OIDC support has been released as a beta Enterprise Connection in Auth0!"/>

## What is OpenID Connect?

OIDC is an authentication protocol, based on the OAuth 2.0 family of specifications. While OAuth 2.0 is focused on resource access and sharing, OIDC is focused on user authentication.

For example, if you sign into an application using your Google account via OIDC, Google will authenticate you and return identity information about you and the authentication performed to the application. OIDC is designed to be easy to use for federation and most modern enterprise identity providers support it, including Microsoft, Google, and Salesforce. Learn more about OpenID in this [free OIDC Handbook - eBook.](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog)

## What Are We Releasing?

We released an OIDC Enterprise Connection as a beta feature for all customers with an Auth0 Developer Pro or Enterprise license. This connection will allow you to easily federate authentication to any OIDC-compliant identity providers. More specifically, any identity provider that implements [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) and supports the `id_token` response type and `form_post` response mode.

Configuration is simple. Here is an example:

<script src="https://fast.wistia.com/embed/medias/5y6uj9or72.jsonp" async></script><script src="https://fast.wistia.com/assets/external/E-v1.js" async></script><div class="wistia_responsive_padding" style="padding:69.06% 0 0 0;position:relative;"><div class="wistia_responsive_wrapper" style="height:100%;left:0;position:absolute;top:0;width:100%;"><div class="wistia_embed wistia_async_5y6uj9or72 videoFoam=true" style="height:100%;position:relative;width:100%"><div class="wistia_swatch" style="height:100%;left:0;opacity:0;overflow:hidden;position:absolute;top:0;transition:opacity 200ms;width:100%;"><img src="https://images.ctfassets.net/23aumh6u8s0i/2QedtR0E2gqslLKRIYJb6Z/ccaf8e20d913ba60162e11c019b7a526/swatch" style="filter:blur(5px);height:100%;object-fit:contain;width:100%;" alt="" aria-hidden="true" onload="this.parentNode.style.opacity=1;" /></div></div></div></div>
<br/>
<br/>

Auth0 uses the issuer URL to find the OpenID Provider Configuration Document, which should be located in the <Issuer URL>/.well-known/openid-configuration endpoint. In the example above, Auth0 is connecting to Azure Active Directory (Azure AD) using the OIDC connection.
  
Once it is saved and enabled, a button will appear in the login page. When clicked, the button redirects to the Azure AD login page:

![An image showing OIDC Enterprise Connection in action](https://images.ctfassets.net/23aumh6u8s0i/4SODmHkFrB51P57FB0OfEm/d83911e2d9668bec124b8e2f90216b89/oidc-enterprise-connection-in-action)

Additional settings can be configured, including:

-   Connection Display name

-   Custom logo on the login page

-   Domains to be used for Home Realm Discovery 

-   Scopes

## How Do I Get Started?

Because it is an Enterprise Connection, the OIDC connection requires an Auth0 Developer Pro or Enterprise license. You can configure the connection in the Auth0 Management Dashboard by clicking Connections > Enterprise > OpenID Connect. [For more information, check out the docs](https://auth0.com/docs/connections/enterprise/oidc) and [the OpenID Connect Handbook.](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog)

<include src="TweetQuote" quoteText="Easily federate authentication to any OIDC-compliant identity providers with Auth0's #OIDC Enterprise connection"/>

This is a beta feature. We welcome your feedback. [Please comment on this post in the Auth0 Community.](https://community.auth0.com/c/auth0-beta-programs/new-oidc-connection-beta)

<include src="asides/AboutAuth0" />


OpenID Connect Enterprise Connection Enters Beta

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

Learn how to support government-issued IDs (like SwissID) as Social Connections into your applications with Auth0.



**TL;DR:** In this article, you will learn how Auth0 can help you support government-issued IDs as social connections in your own applications with ease. For demonstration purposes, you will learn how Auth0 can help you support SwissID (a popular digital identity solution in Switzerland) in your applications. However, the process explained here will be quite similar for other similar government-issued IDs.

<include src="TweetQuote" quoteText="With @auth0, developers can easily support government-issued IDs in their applications."/>

## SwissID Introduction

[SwissID](https://swissid.ch) is the standardized digital identity initiative for use across Switzerland. This initiative is a joint venture of state-affiliated businesses, financial institutions, and health insurance companies (like [Swiss Post](https://www.post.ch/en) and [SBB](https://www.sbb.ch/en/)) that provide a third-party [Identity Provider](https://auth0.com/docs/identityproviders) service to application vendors. With SwissID, users retain exclusive ownership over their personal data making online transactions easier to process and, more importantly, more secure.

Usually, application vendors implementing support for SwissID would require a working knowledge of the [OAuth 2.0 protocol](https://auth0.com/docs/protocols/oauth2) and of the [OpenID Connect specification](https://auth0.com/docs/protocols/oidc). However, as [Auth0](https://auth0.com) now supports SwissID as a [Custom Social Connection](https://auth0.com/docs/connections/social/oauth2), developers can easily integrate this identity provider into their applications. Also, alongside with SwissID, by using Auth0 you can support a myriad of other Identity Provider services (e.g., Facebook, Google, Twitter, and LinkedIn) as well as add capabilities such as [Single Sign On](https://auth0.com/docs/sso/current) and [Multifactor Authentication](https://auth0.com/docs/multifactor-authentication).

<include src="TweetQuote" quoteText="Auth0 helps developers integrating the SwissID identity provider into their custom applications."/>

## Signing up to SwissID

As an application vendor (a.k.a. a [Relying Party](https://auth0.com/identity-glossary#r)), you will first need to sign-up to SwissID. This process starts by [contacting SwissID in order to become a Business Partner](https://www.swissid.ch/en/b2b-kontakt.html). After the sign up with SwissID, you will have to provide information about your redirection URI’s. In return, SwissID will provide you with a Client ID and a Client Secret. Keep handy this information as you will need both values while setting up SwissID within you Auth0 account.

## Signing up to Auth0

If you don't have an Auth0 account yet, <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 a free one right now</a>.

As part of [the free plan](https://auth0.com/pricing), you will get things like:
- 7,000 active users.
- Up to 2 [social identity providers](https://auth0.com/docs/identityproviders).

![Auth0 free plan](https://images.ctfassets.net/23aumh6u8s0i/4rbvCByWzeEgIBPDthLvI7/38606589e60236f021a3aab6d8dd0f26/auth0-free-plan)

While signing up to Auth0, you will have to define a _Tenant Domain_ (e.g., `your-company.auth0.com`) and you will have to choose a _Region_ (at the time of writing, three regions are available: US, Europe, and Australia). After filling in this form, you can complete your account creation, and Auth0 will redirect you to your dashboard.

![Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/7sbXQ9SWpmPS7HuKh9pGhE/427d1c43629461957d5c506e8e9e535d/auth0-dashboard)

## Configuring the Government-Issued ID Connection in Auth0

From your deployment, go to **Connections > Social** in the Auth0 Dashboard, scroll to the bottom, and click **Create Custom**.

Add a name for this connection (something similar to "SwissID-connection" would be descriptive enough), as well as your SwissID **Client ID** and **Client Secret**.

Next, define the **Fetch User Profile Script** as follows:

```javascript
function (accessToken, ctx, cb) {
  // call SwissID to obtain user profile
  request.post({
    url: 'https://login.int.swissid.ch:443/idp/oauth2/userinfo',
    headers: {
      'Authorization': 'Bearer ' + accessToken,
    },
  }, function (err, res, body) {
    if (err) return cb(err);
    if (res.statusCode !== 200) return cb(new Error(body));

    // validate token using the node-jsonwebtoken library
    jwt.verify(body, 'SWISS_ID_SECRET', {}, function(err, decoded) {
      if (err) return cb(err);

      cb(null, {
          user_id: decoded.sub,
          family_name: decoded.family_name,
          given_name: decoded.given_name,
          gender: decoded.gender,
          email: decoded.email,
          provider: 'SwissID',
      });
    });
  });
}
```

> **Note:** You will have to replace `SWISS_ID_SECRET` with your own SwissID Client Secret.

After implementing the script above, you will have to define three more properties before wrapping up:

1. **Authorization URL**: In this field, you will have to input this: `https://login.int.swissid.ch:443/idp/oauth2/authorize`.
2. **Token URL**: In this field, you will have to input this: `https://login.int.swissid.ch:443/idp/oauth2/access_token`.
3. **Scope**: In this field, you will have to input this: `openid profile email phone`.

With these changes in place, you can hit the **Create** button to persist the new settings.

> **Note:** The function declared in the script above is fully customizable and is used to obtain the various supported claims from SwissID. You can tweak this script to build the profile from different perspectives for a particular user (for example, you could ask only for its email address, or its email and its first name, etc.). If you need help building up your users' profile, you can check [the reference application provided by SwissID](https://login.int.swissid.ch/swissid-ref-app) to explore what claims are available. 

## Testing the SwissID Custom Social Connection in Auth0

After hitting **Create**, a new set of buttons will appear on the screen. One of them will be the **Try Connection** button. Pressing it will present you the SwissID login page and, once you submit your credentials successfully, a page similar to the following will be displayed by Auth0:

![Testing the SwissID Custom Social Connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/zXAlO7cD97AJncXb6qVjK/f2a397309923b5fad308d3f0a0a009d1/testing-the-social-connection-extension)

That's it! Your custom connection between Auth0 and SwissID is already configured. Now, you can use the **Applications** tab available on your custom connection to enable the applications you want to use with SwissID. For example, the screenshot below shows a configuration where only the _Some Awesome Product_ application has the SwissID custom connection active.

> **Note:** If you are experiencing problems with your SwissID Connection, please, ensure that the SwissID team have set the configuration to use client secret in the body of POST requests to their `access_token` endpoint.

![](https://images.ctfassets.net/23aumh6u8s0i/3TCY9Ms9UJZhufCakVZOc6/5b3990ec80c5cae7c0b07398103d2bbe/activating-the-custom-connection-to-different-apps)

<include src="TweetQuote" quoteText="With Auth0, developers can support SwissID login alongside with other features like multifactor authentication, single sign on, etc."/>

## Styling the SwissID Connection on the Auth0 Login Page

By default, [the Auth0 Login page](https://auth0.com/docs/hosted-pages/login) will automatically display all connections enabled for an application. For first-class connections like Facebook and Google, the login page will automatically display an appropriate icon for the connection. However, for custom connections (such as SwissID), only a default icon is displayed.

If needed, you can tailor the look and feel for any connection on either the login or the registration dialogs. This allows you to host a logo for SwissID on your own CDN, and then tell Auth0's login page to use this logo. For more information, check our documentation on [how to customize your login page](https://auth0.com/docs/hosted-pages/login#how-to-customize-your-login-page)

<include src="asides/AboutAuth0" />


Supporting Government-Issued IDs as Social Connections with Auth0

avatar

Jared has worked alongside founding teams to define and deliver products which are critical to Fortune 500 enterprises and small businesses, enjoyed by consumers, and depended on by developers. Along the way, he's helped grow multiple companies from a handful of people to hundreds of employees, financial stability, and successful acquisitions. Additionally, Jared is an active contributor to open source software. He is the lead developer of Passport.js, the popular authentication framework for Node.js. Downloaded over 2 million times per month, it powers authentication for innumerable applications on the Internet. He has a portfolio of over 300 repositories freely available on GitHub.

Jared Hanson

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



**TL;DR:** We recently [hosted a webinar](https://resources.auth0.com/webinars/3-iam-examples/) that covered modern identity management and what it takes to implement both Authentication and Authorization to support your Digital Transformation. In this article, we'll cover these implementations ranging from basic authentication, to an OpenID Connect server, and API authentication.


## Introduction
Identity and Access Management (IAM) encompasses the security protocols and processes that allow the correct users to access the correct content, at the correct times.  Cloud-based IAM providers, such as _Auth0_, have created simpler and more intuitive ways of managing user access, and they form an important part of **digital transformations.**

<include src="TweetQuote" quoteText="Identity and Access Management (IAM) is the security and process that allows the correct users to access the correct content, at the correct times."/>

Digital transformation, for those unaware, is not just a buzzword. It encapsulates the process of heavily utilizing modern, digital technologies to radically change businesses.

> Look beyond the hype and you'll find a daunting task at the heart of digital transformation. Rather than focusing on any single IT project, digital transformation describes a series of projects that, together, change every facet of an organization, from back office operations to customer interactions, often with the end goal of making these different processes intrinsically linked.

[http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation](http://www.itpro.co.uk/strategy/28047/what-is-digital-transformation)

As we go through this article, we will cover three _IAM_ use cases. Firstly, we will cover implementing authentication on a basic website. This is the situation most people will find themselves in and the most common use case of the three. Once we've covered basic website authentication, we will move onto standard federated logins.

The second scenario we will cover is _**Enterprise SSO**_. We shall create a fake example company named _Acme,_ whos enterprise customers demand a way of logging into Acme's various services without having to remember a range of username and passwords. By using OpenID Connect, we will show how they can allow their customers' employees to log in with corporate credentials.

Finally, we will cover API integration. When we want to allow our customers to integrate our service into their line-of-business applications in custom ways.


## A Basic Website
Something we're all familiar with is the basic user registration and login that we find on our favorite websites. To access various areas and features of most websites, we usually have to create an account with them. From a high level, all this consists of is a database containing our usernames/email addresses and a complex hash of our passwords (hopefully).  Throughout this article, we'll use an example data model in which crucially, the core Users table will never change the schema, only the data references will change. The basic data model looks like this:

![Basic Data Model](https://images.ctfassets.net/23aumh6u8s0i/74wMh29yR35x1gyeASUrmv/9e037c843a6ff03b59be3420a7945677/basic-data-model)

Our sample data model is that of a simple project management tool, in which Users own Projects. Very basic. Now, what we need is a way for our users to register their details for our application.

![Basic Registration](https://images.ctfassets.net/23aumh6u8s0i/3L7FmaYEjSOGrUdOexyRdw/9e8c66dd6e21383e06694f5db8490da6/basic-registration)

As you can see in the image, our app now contains a standard sign up for new users to register for our service. From a back end perspective, the form uses a `POST` action to submit the form data to our `/signup` resource. Our back end then writes this data to our chosen database and forwards the user onto the specified route upon successful completion. Once we have a user signup implemented, a user login is the next thing we need to address. The basic login flow for our simple web app looks like this:

![Basic Login](https://images.ctfassets.net/23aumh6u8s0i/1Ku7YSRGdgbf5xOoEpUnxQ/55c563b1aaa309b085de6fcfa8a72b6f/basic-login)

In our login flow, users submit their email address and password, which issues a `POST` request to our `/login` resource. Our application back end takes the credentials supplied, issues a database lookup and ensures the details are correct. If so, our app will issue a HTTP forward request onto the specified resource, containing a Session Cookie.

In the image above, you can see that the Session Cookie is set as a HTTP Header, and is actually the most important factor in this flow. The Cookie will contain tokenized information about our users perhaps including metadata such as the user's name and avatar, so as to reduce database hits going through our web app. Besides containing the user's metadata, the Session Cookie is (more importantly) also the authorization credential for all subsequent requests as the user browses our application.

With this implemented, our application now has a basic user authentication system set up. Being basic, there are many features that we haven't addressed here, but that would really need implementing. Password hashing, password complexity verification, password reset functionality, and multi-factor authentication to name a few. Luckily, by using a system such as [Auth0's Hosted Login](https://auth0.com/docs/hosted-pages/login), we save the worry of having to implement these, as they come as standard. Out of the box, Auth0 offer the features mentioned above plus many more. You can have a fully functional user management system setup in minutes.


## Single Sign On (SSO) for Enterprise
If you've used services such as Amazon Web Services, Slack, GitHub or Salesforce, you will notice that they all have a Single Sign On (SSO) implementation so that users can access those services with their corporate credentials. As we add SSO federated capabilities into our sample application, we do have one constraint in that (as mentioned above), we do not want to change the data table schema.

![SSO Data Model](https://images.ctfassets.net/23aumh6u8s0i/6M9ZrX0pYtMQlLySKJ7j0r/fd0e804720e293fda0d1c9c2f1026740/sso-data-model)

Our `Users` and `Projects` tables do not change, but the relationships evolve to include our external identity providers.

For our Federated SSO implementation, we're going to implement an _Identifier-first_ login prompt. Our application will only ask for an email address for the user:

![SSO Login Prompt](https://images.ctfassets.net/23aumh6u8s0i/5uaqLWmRI3n3Z0TKysWTcg/dfb0e87190ced85da967c708cb216f31/sso-login-prompt)

The point of this is to look up the SSO identity provider associated with this email address, which in this case is **_cotoso.com_**, so the user will be redirected there to log in.

![SSO Flow](https://images.ctfassets.net/23aumh6u8s0i/4ovSoo6JhxjhQnaDBYNRcv/b1a5209e2608147b29e1cfd70fe7b5cc/sso-flow)

As shown in the image above:  once the user _(sally@contoso.com)_ enters her email address, our application determines that _contoso.com_ is our Identity Provider and redirects her there. Sally then logs into her _contoso.com_ corporate account, and _contoso.com_ verifies it. She is then redirected back to our application with access granted.

As part of this OpenID Connect authentication response, the `code` returned in the OpenID Connect Auth Response above is exchanged for an `ID Token`. The `ID Token` is what conveys the identity information from _contoso.com_ to our application, and looks like this:

``` json
{
  "iss": "https://id.contoso.com",
  "sub": "2482899761001",
  "name": "Sally",
  "email": "sally@contoso.com"
}
```

As with all ID Tokens, there is an _Issuer_ and an _Identifier_.  The Issuer being `https://id.contoso.com`, and the _Identifier_ being the subject `"sub": "2482899761001"`. In the auth flow above, our application (acme.com) will now look at this ID Token, identify Sally, and forward her onto our Dashboard, setting a Session Cookie for future requests.

From a database point-of-view, this SSO flow will look like this:

![SSO Database Flow](https://images.ctfassets.net/23aumh6u8s0i/3l5n9ubTlVC3BL9zbbmZJe/7d8aeb7f309d3477d96a3313d9b47748/sso-database-flow)

Firstly, our application will perform a lookup for the identity provider _contoso.com_, and redirect Sally to that login. Once Sally has logged in on _contoso.com_ and has been redirected back to our application, one of two things will happen. If Sally has never registered with our application before, a User record will be created for her, with the information returned from _contoso.com_. This would replace the sign up step we implemented in the basic example above. Our application will then associate the external identity with the new user record for find operations on subsequent logins.

![SSO Final Step](https://images.ctfassets.net/23aumh6u8s0i/20d076SSRPax813EDFIfYO/3f23fac0b59109b8a9d04c8a68faeb46/sso-final-step)

Similar to our earlier basic example, upon successful login, a _Session Cookie_ is set to portray the information required for subsequent requests.

With the above, we now have Single Sign On implemented on our acme.com sample application. Worth noting here is that in this SSO implementation, we have chosen an identifier-first login prompt with no option for a password. In reality, we would need to implement a password option for users that have existing non-federated accounts. Beside this, we should also implement a SAML integration, and support for account linking an unlinking.

By choosing to use an IDaaS provider like _Auth0_, we can get all of these features, plus many more straight out of the box.  Using [Auth0 for SSO](https://auth0.com/single-sign-on) allows us configuration of any enterprise connection, including Active Directory, LDAP, ADFS, SAML, and more with just a few lines of code.


## API Authorization
For the final implementation example of this article, we're going to look at API Authorization. We need to implement API auth so that our customers can integrate our service into their applications in ways not offered as standard, and to allow them deeper integrations. Once again, let's take a look at our data model, now including API auth:

![API Auth Model](https://images.ctfassets.net/23aumh6u8s0i/4NRyLQsRvkuyFmq64xuNeN/d0b5238abf314ac3f4051da5db971a17/api-auth-model)

Although the model now looks slightly more complex, following our aforementioned constraint; our `Users` and `Projects` schemas have not been changed. The schemas for SSO providers have not changed either. What has changed are the tables on the left, which introduce support for other people getting access to _Acme's_ APIs. If you are familiar with Facebook sign-on or GitHub etc, the terms above are fairly typical. `Clients` are the applications a user may build/use to access APIs and services, `Resource Servers` are the APIs themselves, and the Authorization Grants `(AuthZ Grants)` track the permissions that have been granted between the users and the applications.

For our API Authorization example, we are going to imagine that our sample company (Acme.com) have a customer named _Fabrikam.com,_ who wish to allow their customers to pull a list of their `Projects` from the _Acme_ API to display on their own dashboard.

From a simple button on the _Fabrikam.com_ website, their customers will be redirected through an OAuth2 Authorization request to the _Acme_ website, returning an Auth code on successful submission. Using the OAuth2 auth flow of [Client Credentials Grant](https://auth0.com/docs/api-auth/tutorials/client-credentials), this Auth code will then be swapped for an **Access Token** and used in the web application's _Authorization Header_ using the `Bearer` protocol.

Let's take a look at how the API Auth flow works visually:

![API Auth Login](https://images.ctfassets.net/23aumh6u8s0i/49pbvFGduF9VwuFevWGf66/e5c9bc8dc3632dbb826ff32e02b5cb46/api-auth-login)

As you can see from the image above, the customer of _Fabrikam.com_ clicks on the 'Connect to Acme' button on their Dashboard.  This click then issues a GET request to the `/connect/acme` route, which from the back end initiates an OAuth2 request to the _Acme.com_ server. The _Fabrikam.com_ customer is then prompted to log in using their _Acme_ credentials. On success, the _Acme.com_ server issues the OAuth2 Authorization Response to the `callback_url` specified in the initial request. In a similar manner to the _OpenID Connect_ example above, this response contains a `code` that will be exchanged for an **Access Token:**

![API Auth Login Response](https://images.ctfassets.net/23aumh6u8s0i/36WBGudxJpP0g6U9RaRb32/0dfc5f2e368f90c40054592d672aabcb/api-auth-login-response)

Following the [Client Credentials Grant flow](https://auth0.com/docs/api-auth/tutorials/client-credentials), the _Fabrikam.com_ back end swaps the above code for the Access Token needed for subsequent API requests.  The Access Token returned will have the following appearance:

``` json
access_token = eYJ0eXAi0...

{
  "iss": "https://www.acme.com",
  "aud": "https://api.acme.com/v1/",
  "sub": "501",
  "scp": [ "read:projects" ]
}
```

This _Access Token_ is similar to the _ID Token_ shown in the previous example, but instead of just identifying the user, it is also responsible for allowing _Fabrikam_ to make API calls subsequent to this Authentication event happening. This Token contains _Acme_ as the issuer, the API route to be used, the `subject` referring to the user id of "502", and the request _permissions_ in the `scope`. With the _Access Token_ now available to _Fabrikam.com_, it is used with requests for the customer's `Projects` from the _Acme.com_ API.

![API Auth Authd Reqs](https://images.ctfassets.net/23aumh6u8s0i/59HhtjSyKjTQST9ItgwwoL/8e3d373768fb5cfcb94297f2395ff731/api-auth-authd-reqs)

As the image shows, _Fabrikam_ sends the encoded token in the `Authorization` Header of the request, using the `Bearer` protocol, in all subsequent API requests.  The _Acme.com_ API successfully returns the customer's `Projects` which are listed in the Dashboard, as shown. That brings to a close the OAuth2 Client Credentials grant for API Auth example. However, we can take this a step further still. What if we wanted to combine this API Auth with the Enterprise SSO implementation in our previous example?

There may arise a scenario in which  _Fabrikam.com_ want to integrate with _Acme's_ APIs, but a user at _Acme_ authenticates with corporate credentials for _Contoso.com_ (who is an enterprise customer) as within our previous example. The flow becomes a multi-step process, with the first request coming from _Fabrikam_ to _Acme_, then _Acme_ to _Contoso_, with the responses flowing back in the opposite direction, back to _Fabrikam._. The interesting point of this scenario is that _Acme_ is acting as both an Identity Provider (when providing API authorization), and a Relying Party (when it's consuming identity information). This pattern may sound complex, but it is a very common scenario. Most SaaS companies both provide services, as well as authenticating users from other companies, meaning they have to implement both sides of the protocol (client and provider). The following diagram shows this implementation layout:

![OAuth OpenID Combine](https://images.ctfassets.net/23aumh6u8s0i/6WZAjqTn3OMo2eRyuLgvCS/1d678ed2c67c51061ddb1dfbb8773e90/oauth-openid-combine)

<include src="TweetQuote" quoteText="OAuth 2.0 and OpenID Connect have the same protocols because OpenID Connect is just an extension of OAuth."/>

Happily, as you will have noticed throughout this article, OAuth 2.0 and OpenID Connect have the same protocols, because OpenID Connect is just an extension of OAuth. This saves us a lot of hassle on implementation. At this point, with Authentication becoming a more prominent feature, it might be worth setting up a single, centralized server to handle all of the Auth requests coming through our app _(Acme)_.

If we revisit our data model, we can see that all of the tables in our model, except for the `Projects` table, can be treated as a separate concern, and become our authentication server:

![API Auth Model Pattern](https://images.ctfassets.net/23aumh6u8s0i/6jcNbD9NpTsH1E5Z9JcNtL/fd08c21e843f5af8e3944886aa3047af/api-auth-model-pattern)

We can take advantage of this in our architecture by creating the aforementioned centralized Auth server on a subdomain such as `id.acme.com`, and piping all of our Authorization / Authentication requests through there. The applications authenticating and being granted authorization through this centralized server may be third-party applications, such as _Fabrikam.com_ or _Contoso.com_, but also internal applications such as `app.acme.com`. Setting up this single centralized server is a nice and clean way to solve a lot of Auth challenges, with a single protocol and a single implementation. The architecture for this server could look like the following:

![Centralized Auth Server](https://images.ctfassets.net/23aumh6u8s0i/2hj6ZSI6wVtHmguWHPlEHq/8180c2f0e4abff657db1f05cb9536ecb/centralised-auth-server)

So with this, we have a fully functional OAuth 2.0 server implementation. Whilst this implementation is entirely functional, there are a few extra features not included in this example, that you would want to implement in the real world. One of the biggest is a _Consent Prompt_ ensuring users have the options of granting the application access, such as the following:

![OAuth2.0 Consent Prompt](https://images.ctfassets.net/23aumh6u8s0i/71FwyIRzi8zepAO1e0g4fu/388e0dfbe33ab932a3467b5e7fc3b142/consent-screen)

Besides this, consent and token revocation is also a must-have feature that would need implementing. Lastly, token introspection and JWTs for stateless authorization are both desirable features one would ideally implement.

If you wanted a fully-featured OAuth 2.0 server with all of the functionality mentioned above, it is definitely worth checking out an IDaaS provider to save you all of the implementation hassles. [Auth0](https://auth0.com/docs/protocols/oauth2) offers out of the box, fully featured OAuth 2.0 implementations that take care of all of the architecture above, plus offer more features and functionality; and all implemented without having to build and manage it yourself.



<include src="asides/AboutAuth0" />


3 IAM Examples to Support Digital Transformation

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Bluetooth, a standards based organization, chooses Auth0 to implement standards based authentication via OpenID Connect and OAuth for improved security, access, and interoperability.



**BELLEVUE, WA** - [Bluetooth Special Interest Group](https://www.bluetooth.com/) (SIG), a standards based organization that oversees the development and licensing of Bluetooth technologies, has chosen Auth0 to implement standards based authentication throughout their organization. Thanks to Auth0, Bluetooth was able to implement OpenID Connect and OAuth throughout their organization in record time, meeting the needs of today and also laying the foundation for future expansion.

![Bluetooth Website](https://images.ctfassets.net/23aumh6u8s0i/5WAxWlxKMK57zildCrXUv/34eba0420e66aa592dcd657e76c42f2e/site)

Auth0 was chosen not solely for technological capability, but also for state-of-the-art security, top-notch documentation, excellent customer support, and a superior licensing model that was a right fit for Bluetooth. Auth0 allowed Bluetooth to keep their existing infrastructure in place, while adding the standards based authentication layer on top. This allowed the Bluetooth engineering team to quickly implement the solution across multiple disparate apps.

> “Being a standards based organization, it was important for Bluetooth SIG to implement a standards based identity solution for our platform.”
– Jeremy Syme, Director of Systems Engineering

Read the [case study](https://auth0.com/learn/bluetooth-case-study/) to learn more about why Auth0 was the right fit for Bluetooth.

<include src="asides/AboutAuth0" />


Bluetooth Chooses Auth0 to Implement Standards Based Authentication

Auth0 conforms to OpenID Connect protocol and allows clients to verify the identity of the end-users though a reliable implementation.



In May of last year, Auth0 officially gained certifications for *OP Basic* and *OP Config* profiles of the OpenID Connect spec. As of February this year, Auth0 has gained two new [OpenID Connect certifications: *OP Implicit* and *Hybrid OP*](http://oixnet.org/openid-certifications/auth0/). With these certifications we're thrilled to join the ranks of industry leaders such as Google, Microsoft, PayPal, and others who are embracing standards based authentication.

OpenID Connect, as a layer on top of the OAuth 2.0 authorization protocol, allows for decentralized authentication and improves user access to websites and apps.

Getting certified means ensuring that our implementation of the protocol meets the official specifications as outlined by [OpenID](http://openid.net/developers/specs/).

OpenID is a cornerstone of the modern, open web, and we're proud that our implementation has the official stamp of approval.

## What Is OpenID Connect?

OpenID Connect is an open identity standard. It acts as an authentication layer (proving who you are) on top of the OAuth 2.0 authorization standard (granting you access).

A user gets an OpenID account through an OpenID identity provider. The user uses that account to sign into any site (a relying party) that accepts OpenID authentication (for example, YouTube). This open-source framework, provided by the OpenID standard, lets the user, relying party and the identity provider “just work” together.

Instead of having to sign up on a website and keep track of your passwords, you only need to sign up once and use that login across various applications.

On a website, it might look something like this:

![example login sign in form](https://images.ctfassets.net/23aumh6u8s0i/3r8PILdrCrl8YjOMtcHsjs/11f9e4d97cacc97cc89c76814fc4e22b/sign-in-form)

A user is already logged into Facebook or Google (an identity provider) with a set of credentials. This set of credentials can then be used to log into another website or application, a relying party. This site or app will ask the user "Sign up with Facebook or Google?"

When a user clicks on Google or Facebook, they're authorizing that identity provider to back up their claim. Then the user is redirected to the website or application.

![example social provider authorization](https://images.ctfassets.net/23aumh6u8s0i/0n2zFjciHBXn1YqTOzv7X/4f683da5c99cc18e95fb6814db9b658a/social-provider-authorization)

This use of linked identities means you only have to manage a single username and password for websites.

With OpenID, users don't need traditional authentication tokens like a username and password. All they need is to be registered on a site with an OpenID identity provider. It's decentralized; any website can use OpenID as a way to log users in.

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

## Why is OpenID Connect Important?

Before OpenID, people built site-specific networks with their own signup and login systems. The idea that you could select your own identity provider for logging into a website and a common standard that would connect all these systems didn't exist. Some big players, like Facebook, had built their own solutions for SSO. But the decentralized OpenID model was so powerful and beneficial that even they eventually adopted it. Like VentureBeat's Eric Eldon [wrote](http://venturebeat.com/2009/04/14/single-sign-on-service-openid-getting-more-usage/) upon its release,

> *The point of OpenID, as all of these companies seem to accept, is that users don’t want to use just any one service to sign in everywhere. Instead, users should have the choice to log into any site using any other identity. Making it easier for people to log in anywhere just means more people will log in overall — and potentially become users of any of these companies.*

Think of OpenID as your driver's license for the entire internet.

Websites that use OpenID won't ask for your information constantly, making it faster and easier to sign up. Plus, you can associate information with your OpenID such as your name and email address, and decide how much websites get to know about you. So, websites that use OpenID won't bug you for the same information every single time you sign up.

Since you're uniquely identified over the internet, OpenID Connect is also a good way connect your accounts into a more unified persona. The moment you establish yourself as the individual who uses a specific OpenID, whenever someone sees you're using your OpenID online, they'll know it's you.

If your friend opens a website and sees someone with your OpenID has made a comment, they can be certain it was you, not someone with the same name coincidentally.

## Why Get OpenID Certification?

You've carried rounds and rounds of tests to check your OpenID specs. The results were great with strong participation. So what's the point of getting certified?

Certification ensures credibility. In your own testing, you can pick and choose what aspects of your OpenID implementation you want to test. Certification involves meeting a set of minimum criteria that are standard across the board, and your results (and the process you used to get there) are open for public oversight.

When you're done, you can prove that your [OpenID implementation](https://auth0.com/learn/how-auth0-uses-identity-industry-standards/) is conformant with the [official specs](http://openid.net/certification/) — not just for your customers and potential customers, but for yourself.

## Aside: Securing Applications with Auth0

Are you building a product and want to support OAuth and OpenID Connect? We at Auth0, can help help you with that while you keep focused on what matters the most to you, the special features of your product.

[Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication). [We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.


Auth0 is OpenID Connect Certified

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace

Auth0 SDKs make it really easy to add SSO to any app, on any platform. But sometimes, apps cannot be modified. What to do then? A very simple solution is to

Auth0 [SDKs](https://docs.auth0.com) make it really easy to add [Single Sign On (SSO)](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog) to any app, on any platform. But sometimes, apps cannot be modified. What to do then?

A very simple solution is to front any web content with a web server that itself is capable of negotiating authentication for users. One web server with the extensibility required for plugging-in any auth is Apache server.

In this post, we'll learn how to install and configure `mod_auth_openidc` to work with Apache and Auth0.



##How it works
Apache has [plugable authentication modules](http://httpd.apache.org/docs/current/mod/mod_auth_basic.html#authbasicprovider) that you can use to protect specific routes. One such module is [mod_auth_openidc](https://github.com/pingidentity/mod_auth_openidc) written by [Hans Zandbelt](http://hanszandbelt.wordpress.com/).

> __mod_auth_openidc__ is an authentication/authorization module for the Apache 2.x HTTP server that allows users to authenticate using an OpenID Connect enabled Identity Provider.

When a user first attempts to access protected content behind Apache, the module will first redirect the user to the configured OpenID Connect identity provider. After the user is authenticated, access is granted to the actual resource:

![image](https://images.ctfassets.net/23aumh6u8s0i/4Tz0lvc5MlWvs8ydbEj319/0d3b9e38b264ced1ed6a2f835ad18176/pub_w_811_amp_h_340)

Since Auth0 supports the OpenID Connect protocol (among [many others](https://docs.auth0.com/protocols)), it is straight forward to configure the module with it:

```
OIDCProviderIssuer https://contoso.auth0.com
OIDCProviderAuthorizationEndpoint https://contoso.auth0.com/authorize
OIDCProviderTokenEndpoint https://contoso.auth0.com/oauth/token
OIDCProviderTokenEndpointAuth client_secret_post
OIDCProviderUserInfoEndpoint https://contoso.auth0.com/userinfo

OIDCClientID 3g6d6c..........mXNxkAE
OIDCClientSecret _8sCbkTNhYk4..........8u3mdvRFWBx

OIDCScope "openid email profile"
OIDCRedirectURI https://your_apache_server/example/redirect_uri/
OIDCCryptoPassphrase <password>
OIDCCookiePath /example/

SSLEngine on
SSLCertificateFile /home/your_cert.crt
SSLCertificateKeyFile /home/your_key.key

<Location /example/>
   AuthType openid-connect
   Require valid-user
   LogLevel debug
</Location>
```

##How to configure it

First, you need to [register a new app](https://app.myauth0.com/#/applications/create) in Auth0. You will get a `clientId` and a `clientSecret`. These two go to the `OIDCClientID` and `OIDCClientSecret` params respectively. Then you need to setup SSL certs and define the protected locations (e.g. `/example` in the config file above).

Of course you will have to replace the Auth0 auth URLs with your actual account (__contoso__ is used in the example above).

Any of [Auth0 supported identity providers](https://docs.auth0.com/identityproviders) would work: __Active Directory__, __LDAP__, __ADFS__, __SAML-P__, __custom databases__ or any of the __30+ social providers__. Auth0 will bridge any protocol implemented by these identity systems with OpenID Connect.

It is also very easy to configure a _specific_ connection in Auth0 if you add the `connection` parameter to the `OIDCProviderAuthorizationEndpoint` parameter:

```
OIDCProviderAuthorizationEndpoint https://contoso.auth0.com/authorize?connection=linkedin
```

Users will be sent directly to LinkedIn for authentication in this case.

That's it!

[Want to learn more about Single Sign-On? Get The Definitive Guide on SSO (74-page free eBook) here.](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)

"openid"