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

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

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

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

A brief overview of the top identity open standards used today.



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

<include src="TweetQuote" quoteText="An overview of the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML."/>

## What is an Open Standard?
Identity, and the infrastructure that goes behind making identity **secure**, **lightweight**, and **reliable**, can be a challenge, one that can take up a lot of your team’s time to get just right. One way to reduce the overhead is to utilize open standards, rather than reinventing the wheel.

Open standards are community and industry-driven specifications that can define roles for an app, whether that role is the user, the identity provider, or the service provider, and how those roles talk to each other. Standards also define how apps are able to communicate with each other and to service providers. This can all happen without compromising key details or code.

Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits. 

The formation of open standards has created a uniform way of expressing the fundamental keys of identity across the industry, while still allowing flexibility around the specific path of implementation.

<include src="TweetQuote" quoteText="Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits."/>

### Open Standards You May Know

Modern web development relies on a range of well-known open standards that you may already be familiar with. They cover many facets of web development, from **JSON** (JavaScript Object Notation), used to structure data in a readable format, to **HTML** (HyperText Markup Language), used for creating web pages, all the way to **SAML** (Security Assertion Markup Language),  which is used for enterprise identities as described below.

## Four Common Open Standards for Authentication and Authorization

### OAuth 2
OAuth 2 is the latest version of the OAuth protocol, allowing for **better authorization flow across many devices and applications**. Users can grant a third-party website limited access to their information on another website without exposing their credentials. 

OAuth 2 is one of the most widely used open standards for delegating access, one that you as a user probably see implemented often. For example, when you log in to a website that wants access to information from your Google account (i.e., contacts), you grant authorization via OAuth 2. You can find the official docs for [OAuth 2 here](https://tools.ietf.org/html/rfc6749) and view [Auth0's thorough overview of OAuth 2](https://auth0.com/blog/oauth2-the-complete-guide/).

### OIDC (OpenID Connect)
OpenID Connect is an extra identity layer built on top of OAuth 2 that specifies a process for checking a user’s identity by ensuring they are who they say they are.

> OIDC is able to retrieve the user’s basic profile information from the identity provider. 

For example, when a user visits a website and can log-in via Google or Facebook, that application will then go to Google or Facebook and get those user's credentials. The application then does not have to store the user's basic profile and can utilize Google or Facebook and their storage of the user's information to grant access and verify their identity.

OpenID Connect is _API-friendly_ and can be used across mobile applications, web-based applications, all JavaScript clients, and many other types of clients. OIDC also requires the use of JSON Web Tokens which we will get into next. You can find the official docs for [OpenID Connect here](https://openid.net/connect/).

### JWT (JSON Web Tokens) 
Sending information, such as user data, across many different applications can be done using **JSON Web Tokens**. JSON web tokens hash information into a long, encoded string of characters that can be broken into three parts:

* The header that declares the hashing algorithm and the token type. 
* The payload or data where you could have the name of the user or other relevant information like the token expiration time or the subject. 
* The verifying signature made up of the header, payload, and a secret all hashed together. 

The JWT can get long, but this open standard provides a straightforward way to transfer information. If you visit [jwt.io](https://jwt.io/), there is a tool there where you can put in any encoded JWT and it will decode it for you as follows:

**JWT - encoded:**

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

**JWT - decoded:**

Header:

```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

Payload:

```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```

Verify Signature:

```
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded
```

JWTs can be verified and trusted because they have a **digital signature**. That digital signature verifies that nothing was changed while the JWT was being passed. You can find more information on [JWTs here](https://auth0.com/learn/json-web-tokens/).

### SAML (Security Assertion Markup Language)
An XML-based open standard, SAML ensures that there is a secure communication of identities between organizations. This is a great tool for businesses when they want to communicate user authentication and authorization information to other organizations that their employee may need access to. Some benefits include:

* Increased security through a single point of authentication
* Improved user experience by utilizing a single sign-on access point.
* A centralized user access control allowing for a one-stop authentication point

SAML utilizes a _SSO (single sign-on) format_. Digitally signed XML documents are passed between the business and multiple third-party entities they have partnered up with. You can find [more information on SAML here](https://auth0.com/blog/how-saml-authentication-works/).

---

## Summary

As we have learned, the flexibility of open standards allows for the identity industry to be on the same page, reduce overhead, and create a uniform way of expressing the **fundamental keys of identity**. When everyone implements a standard way of doing things, then the _flow_ over different languages, projects, and teams can go as planned with authentication and authorization.

At Auth0 we use open standards so that we can connect our product to users and clients alike in a **standard and secure** way. Identity can be tricky, but here at Auth0 you can rest assured that your users are backed by industry-defined open standards. We use open standards to provide you with a secure solution that can be implemented in a matter of minutes. We have you covered, open standards and all.

Want to continue learning about these open standards? Visit the Auth0 docs for the above mentioned open standards: 

* [OAuth 2](https://auth0.com/docs/protocols/oauth2)
* [OpenID Connect](https://auth0.com/docs/protocols/oidc)
* [JWTs](https://auth0.com/docs/jwt)
* [SAML](https://auth0.com/docs/protocols/saml/saml-configuration)

<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 Auth0 account here</a>


An Overview of Open Standards

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

A practical tutorial showing how to setup and develop a modern Web application based on ASP.NET Core 2.0 and React.

Developing Web Apps with ASP.NET Core 2.0 and React - Part 3

Developing Web Apps with ASP.NET Core 2.0 and React - Part 2



**TL;DR:** In this series of posts, starting with this one, you will build a Web application based on ASP.NET Core 2.0 and React. To solve the identity management feature, you will integrate this stack with [Auth0](https://auth0.com/). In this first part of the series, you are going to use ASP.NET Core 2.0 to develop the APIs of your application. [The final code can be found in this GitHub repository](https://github.com/andychiare/netcore2-auth0).

<include src="TweetQuote" quoteText="Learn how easy it is to create a modern web application with ASP.NET Core 2.0 and React"/>

---

## Setting Up the ASP.NET Core Application

The application that you are going to implement will allow users to browse an online bookstore. Following [the API-First Development approach](https://dzone.com/articles/an-api-first-development-approach-1), you will start building your application by creating the ASP.NET Core 2.0 Web API. To do that, you have two alternatives: first, you can create your application from Visual Studio; second, you can create your application from the command line.

### Creating the Project with Visual Studio

If you are using Visual Studio, you can create the project by choosing *ASP.NET Core Web App* project template, as shown in the following picture:

![Creating an ASP.NET Core Web App with Visual Studio](https://images.ctfassets.net/23aumh6u8s0i/3VdEYdUZjg1dZ8CjKW7FFy/e6dacc131f59c2ab0459cb72a6addb6a/creating-project)

> If you don't have Visual Studio, [you can download it for free here](https://www.visualstudio.com/free-developer-offers/).

After selecting the *ASP.NET Core Web App* project template, you need to specify the type of ASP.NET application you want to build. In your case, you will select the *Web API* application type, as in the following picture:

![Creating ASP.NET Core 2 Web API](https://images.ctfassets.net/23aumh6u8s0i/fSpJBnx1JsWrguTiNfcyh/c5ccb832f295f9cd27184e7b8c0ff926/choosing-web-api)

Make sure you **do not** select any type of authentication, since you will integrate your application with [Auth0](https://auth0.com/).

### Creating the Project from the Command Line

If you prefer to use the command line, you can create your application by typing the following command:

```shell
dotnet new webapi -n API-Auth0
```

This will create an ASP.NET Web API directory, with your project inside, named `API-Auth0` in the current directory.

Whether you use Visual Studio or the command line, you will get the same result. That is, after following these steps, you will get a basic ASP.NET Core 2 Web API application.

### Creating the Books Controller on ASP.NET Core 2.0

Now that you have your project created, you can start refactoring it to provide the desired functionality. The first thing you will do is to remove the `ValuesController.cs` file under the `Controllers` directory. You won't need this controller in your application.

After removing it, you can create the `BooksController.cs` file, in this same directory, with the following code:

```csharp
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;

namespace APIAuth0.Controllers
{
    [Route("api/[controller]")]
    public class BooksController : Controller
    {
        [HttpGet]
        public IEnumerable<Book> Get()
        {
            var currentUser = HttpContext.User;
            var resultBookList = new Book[] {
                new Book { Author = "Ray Bradbury", Title = "Fahrenheit 451", AgeRestriction = false },
                new Book { Author = "Gabriel García Márquez", Title = "One Hundred years of Solitude", AgeRestriction = false },
                new Book { Author = "George Orwell", Title = "1984", AgeRestriction = false },
                new Book { Author = "Anais Nin", Title = "Delta of Venus", AgeRestriction = true }
            };

            return resultBookList;
        }

        public class Book
        {
            public string Author { get; set; }
            public string Title { get; set; }
            public bool AgeRestriction { get; set; }
        }
    }
}
```

Here, you have defined a Web API returning a list of books. For simplicity, you are storing the list of books in an array. In a real-world case, however, this list should be stored in a persistent database. The Web API's URL will be `/api/books` and any HTTP client can get the list of books by issuing a simple HTTP GET request:

```bash
# run the application in the background
dotnet run &

# issue a get request
curl -D - http://localhost:5000/api/books
```

Of course, you don't want that any client could access your bookstore without some proper authentication process. You want that only authorized clients could get the list of books managed by your application. That's where [Auth0](https://auth0.com/) can help you: it provides a set of identity solutions that integrate security into your application.

## Integrating ASP.NET Core 2.0 with Auth0

As the first step, you will need an Auth0 account. If don't have one yet, you can sign up for a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free account here</a>.

During the registration process, you will need to provide the *tenant domain name*, the service hosting region, and a few other details about your company and yourself. The domain name is quite important since it will determine the root part of the API endpoints exposed by [Auth0](https://auth0.com/) to your authorized clients. Once you provide a domain name, you cannot change it anymore. However, you can create as many tenants as needed. Once the registration phase is completed, [you can access your Auth0 dashboard](https://manage.auth0.com/).

### Creating an Auth0 API

As you are creating a backend API that enables users to browse an online bookstore, you will need to create an [Auth0 API](https://auth0.com/docs/apis) to represent your backend. To do that, head to [the APIs section of the Auth0 dashboard](https://manage.auth0.com/#/apis) and click on the *Create API* button. After that, the dashboard will ask you for three things:

- the *Name* of your API, you can set it to *Online Bookstore*;
- an *Identifier* for your API, you can set it to `https://onlinebookstore.mycompany.com`;
- and the *Signing Algorithm*, you can choose *RS256* in this field;

![Securing an online bookstore with Auth0](https://images.ctfassets.net/23aumh6u8s0i/3VAKT9b1bo3bmn6AH17tqu/279ae8cc498c576196d6d575d9ea6a33/creating-an-auth0-api)

When you complete this form, you can hit the *Create* button.

### Creating an Auth0 Application

Your goal is to control your API access by authorizing only trusted clients. To do that, you will also need an application configuration on Auth0. Usually, you would need to create a new application to represent your front-end app. The type of the front-end app would help you decide the type of the Auth0 Application to create. However, as in this first part you will not create the front-end yet, you can use the application that was automatically created for your Auth0 API.

If you chose *Online Bookstore* as the name of your API, then [you will see an application called *Online Bookstore (Test Application)* in the Application section of the Auth0 dashboard](https://manage.auth0.com/#/applications). Click on this application and head over to the *Settings* tab. In this tab, you will see three properties that you will need:

- the *Domain* of your Auth0 tenant;
- the *Client ID* key;
- and the *Client Secret* key;

You will use these values soon enough.

### Configuring Auth0 on ASP.NET Core Apps

After creating the Auth0 API, you will have to modify your application in order to hand the identity management over to [Auth0](https://auth0.com/). As a first step, you will need to add an Auth0 section in the `appsettings.json` configuration file, as shown below:

```json
{
  "Logging": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Warning"
      }
    },
    "Console": {
      "LogLevel": {
        "Default": "Warning"
      }
    }
  },
  "Auth0": {
    "Authority": "<YOUR_AUTH0_DOMAIN>",
    "Audience": "<YOUR_AUTH0_AUDIENCE>"
  }
}
```

You will have to replace both `<YOUR_AUTH0_DOMAIN>` and `<YOUR_AUTH0_AUDIENCE>` with the values that you have defined in the previous sections. For example, if you defined your tenant domain to `https://dotnet2-react.auth0.com` that's what you will use in the place of the `<YOUR_AUTH0_DOMAIN>` placeholder. In the place of the `<YOUR_AUTH0_AUDIENCE>` placeholder, you will use the value that you defined for the *Identifier* of your Auth0 API (e.g. `https://onlinebookstore.mycompany.com`).

Then, you will have to change the `ConfigureServices()` method in the `Startup.cs` file, as follows:

```csharp
using Microsoft.AspNetCore.Authentication.JwtBearer;

// ... other using statements
// ... namespace definition
// ... class definition
// ... etc

public void ConfigureServices(IServiceCollection services) {
	services.AddAuthentication(options =>
	{
		options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
		options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
	}).AddJwtBearer(options =>
	{
		options.Authority = Configuration["Auth0:Authority"];
		options.Audience = Configuration["Auth0:Audience"];
	});

	services.AddMvc();
}

// ... etc
```

As you can see, you have added the authentication service by specifying the [JWT](https://jwt.io/) bearer scheme and providing the authority and audience values taken from the `appsetting.json` configuration file.

After that, you will need to add an invocation to `app.UseAuthentication()` in the body of `Configure()` method, as follows:

```csharp
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
	if (env.IsDevelopment())
	{
		app.UseDeveloperExceptionPage();
	}

	app.UseAuthentication();

	app.UseMvc();
}
```

After enabling authentication support, you can block public access to your API by adding the `Authorize` attribute to the endpoint in the `BooksController.cs` file:

```csharp
[HttpGet, Authorize]
public IEnumerable<Book> Get()
{
	var currentUser = HttpContext.User;
	var resultBookList = new Book[] {
		new Book { Author = "Ray Bradbury", Title = "Fahrenheit 451", AgeRestriction = false },
		new Book { Author = "Gabriel García Márquez", Title = "One Hundred years of Solitude", AgeRestriction = false },
		new Book { Author = "George Orwell", Title = "1984", AgeRestriction = false },
		new Book { Author = "Anais Nin", Title = "Delta of Venus", AgeRestriction = true }
	};

	return resultBookList;
}
```

Now, if you try to access the `/api/books` endpoint, you will get a 401 HTTP status code (which means that you are not authorized). You can verify it by using any HTTP client, such as a browser, [curl](https://curl.haxx.se/), or [Postman](https://www.getpostman.com/).

```bash
# run the application in the background
dotnet run &

# issue a get request
curl -D - http://localhost:5000/api/books
```

The last command will generate a response like the following one:

```bash
# HTTP/1.1 401 Unauthorized
# Date: Wed, 24 Jan 2018 16:28:09 GMT
# Server: Kestrel
# Content-Length: 0
# WWW-Authenticate: Bearer
```

### Getting an Access Token

Now that you have secured your endpoints with Auth0, you will learn how to authenticate a machine to machine application to be able to get the list of books again. You can use any HTTP client, but in this section, you will see how to achieve that by using `curl`.

The first step is to get an authorization token from Auth0. You can do that by issuing a POST request to [the `/oauth/token` endpoint](https://auth0.com/docs/api/authentication#authorization-code) of your Auth0 domain, as follows:

```bash
AUTH0_CLIENT_ID=<YOUR_AUTH0_CLIENT_ID>
AUTH0_CLIENT_SECRET=<YOUR_AUTH0_CLIENT_SECRET>
AUTH0_AUDIENCE=<YOUR_AUTH0_AUDIENCE>
AUTH0_DOMAIN=<YOUR_AUTH0_DOMAIN>

curl -X POST -H 'content-type: application/json' -d '{
    "client_id": "'$AUTH0_CLIENT_ID'",
    "client_secret": "'$AUTH0_CLIENT_SECRET'",
    "audience": "'$AUTH0_AUDIENCE'",
    "grant_type":"client_credentials"
}' https://$AUTH0_DOMAIN/oauth/token
```

Note that you will have to replace `<YOUR_AUTH0_CLIENT_ID>`, `<YOUR_AUTH0_CLIENT_SECRET>`, `<YOUR_AUTH0_AUDIENCE>`, and `<YOUR_AUTH0_DOMAIN>` in the commands above with the values corresponding to the Auth0 API and Application that you have created before.

The response to this request will be something similar to the following:

```json
{
    "access_token": "eyJ0eXAiO...pJmNFPA",
    "expires_in": 86400,
    "token_type": "Bearer"
}
```

Now, you can use the `access_token` you have received from [Auth0](https://auth0.com/) to request the list of books, as follows:

```bash
ACCESS_TOKEN=eyJ0eXAiO...pJmNFPA

curl -H 'Authorization: Bearer '$ACCESS_TOKEN -D - http://localhost:5000/api/books
```

This request will generate the following response:

```bash
# HTTP/1.1 200 OK
# Date: Wed, 24 Jan 2018 17:35:26 GMT
# Content-Type: application/json; charset=utf-8
# Server: Kestrel
# Transfer-Encoding: chunked

# [{"author":"Ray Bradbury","title":"Fahrenheit 451","ageRestriction":false},{"author":"Gabriel García Márquez","title":"One Hundred years of Solitude","ageRestriction":false},{"author":"George Orwell","title":"1984","ageRestriction":false},{"author":"Anais Nin","title":"Delta of Venus","ageRestriction":true}]
```

<include src="TweetQuote" quoteText="Adding identity management to an ASP.NET Core 2.0 is really easy with Auth0."/>

### Creating Integration Tests as a Machine to Machine Applications

The test performed with `curl` in the previous section should only verify that the Auth0 configuration data and that the API implemented by our application work well together. This is a test performed on the fly that should not be persisted. In fact, the type of application that Auth0 automatically created was _Machine to Machine Application_. This type of application is intended for a server to server or unattended interaction. You **must never** store the *Client Secret* on the client side, since it will compromise the application security.

The implementation of the integration test may be a case where you can use the *Client Secret* since this information will not be exposed to the client but remains in the development environment.

Now, it's time to write an integration test that verifies that a request to obtain the book list without an access token fails:

```csharp
[Fact]
public async Task UnAuthorizedAccess()
{
    var response = await _client.GetAsync("/api/books");

    Assert.Equal(HttpStatusCode.Unauthorized, response.StatusCode);
}
```

This simple test verifies that such a request will receive a 401 Unauthorized HTTP status code. After that, you can verify that the configuration data you put in the `appsetting.json` file allows you to get a valid access token:

```csharp

[Fact]
public async Task TestGetToken()
{
    var auth0Client = new HttpClient();
    var bodyString = $@"{{""client_id"":""{_configuration["Auth0:ClientId"]}"", ""client_secret"":""{_configuration["Auth0:ClientSecret"]}"", ""audience"":""{_configuration["Auth0:Audience"]}"", ""grant_type"":""client_credentials""}}";
    var response = await auth0Client.PostAsync($"{_configuration["Auth0:Authority"]}oauth/token", new StringContent(bodyString, Encoding.UTF8, "application/json"));

    Assert.Equal(HttpStatusCode.OK, response.StatusCode);

    var responseString = await response.Content.ReadAsStringAsync();
    var responseJson = JObject.Parse(responseString);
    Assert.NotNull((string)responseJson["access_token"]);
    Assert.Equal("Bearer", (string)responseJson["token_type"]);
}

```

Here, you have replicated through the code the same request you made via `curl`. The `Assert` clauses just verify that a non-null token has been received and that the type of token is *Bearer*.

The last test ensures that a request with a valid access token will get the list of books returned by the API:

```csharp
[Fact]
public async Task GetBooks()
{
    var token = await GetToken();

    var requestMessage = new HttpRequestMessage(HttpMethod.Get, "/api/books");
    requestMessage.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
    var booksResponse = await _client.SendAsync(requestMessage);

    Assert.Equal(HttpStatusCode.OK, booksResponse.StatusCode);

    var bookResponseString = await booksResponse.Content.ReadAsStringAsync();
    var bookResponseJson = JArray.Parse(bookResponseString);
    Assert.Equal(4, bookResponseJson.Count);
}
```

This code uses a method called `GetToken()` that requests a valid token to [Auth0](https://auth0.com/) authentication endpoint:

```csharp

public async Task<string> GetToken()
{
    var auth0Client = new HttpClient();
    string token = "";
    var bodyString = $@"{{""client_id"":""{_configuration["Auth0:ClientId"]}"", ""client_secret"":""{_configuration["Auth0:ClientSecret"]}"", ""audience"":""{_configuration["Auth0:Audience"]}"", ""grant_type"":""client_credentials""}}";
    var response = await auth0Client.PostAsync($"{_configuration["Auth0:Authority"]}oauth/token", new StringContent(bodyString, Encoding.UTF8, "application/json"));

    if (response.IsSuccessStatusCode)
    {
        var responseString = await response.Content.ReadAsStringAsync();
        var responseJson = JObject.Parse(responseString);
        token = (string)responseJson["access_token"];

    }

    return token;
}

```

This test completes the validation of your ASP.NET Core 2.0 application with [Auth0](https://auth0.com/). If needed, you can download the full source code of the application from [GitHub](https://github.com/andychiare/netcore2-auth0).

## Summary

In this article, you have built an ASP.NET Core 2 Web API application and you have integrated it with Auth0 in order to expose the API only to trusted clients.

This is the first step in a series of articles that will show how to build a complete modern application. This application will be based on the ASP.NET Core API that you have just created and in a React Single Page Application. [In the next article](https://auth0.com/blog/developing-web-apps-with-asp-dot-net-core-2-dot-0-and-react-part-2/), you will build this Single Page Application to allow users to browse the bookstore. Stay tuned.


Developing Web Apps with ASP.NET Core 2.0 and React - Part 1

A practical tutorial showing how to use JSON Web Tokens in ASP.NET Core 2 applications.

Securing ASP.NET Core 2.0 Applications with JWTs

Learn how to handle authentication on ASP.NET Core applications

ASP.NET Core Authentication Tutorial

bb9128fac91692ad4f46a785d772dd39?s=200 avatar

bb9128fac91692ad4f46a785d772dd39?s=200

Data Scientist and Engineer, I love tinkering with data!

Head of Data

Pablo Seibelt

Learn how to leverage Auth0 to have Shiny Authentication for the open source version or another legacy website.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Some content in this post is outdated. Check our <a href="https://auth0.com/blog/adding-authentication-to-shiny-server/">updated guide</a>.</strong>
</div>


[Shiny Server](https://www.rstudio.com/products/shiny/shiny-server/)  is a great solution for BI/analytics reporting. It leverages all the power of the [R language](https://www.r-project.org/), which is the most popular open-source language for statistics, and it has a lot of useful functions for *Data Mining*, *Machine Learning*, *Reporting*, etc.

<include src="TweetQuote" quoteText="Shiny Server is a great solution for BI/analytics reporting."/>

The open-source version of Shiny Server features no Authentication, and if it's open on Internet, it leaves your data exposed. In that case, you likely won't want everyone on the Internet to be able to see your internal analytics, so you'll need to install and configure the authentication yourself.

One of the easiest ways to add authentication to Shiny and, by extension, any unsecured web application, is to use Apache with Auth0 through the **auth_openidc** module.

This is also useful if you have a legacy web app with a username and password everyone shares or if you are hosting a server with static files you want to share.

![Diagram of the Shiny Authentication scheme](https://images.ctfassets.net/23aumh6u8s0i/1X0EfCJlUSk3CSdyrX73W5/be36fbf08b114b587aa265ebc73987a9/pub_w_959_h_638)

So, let's get started with the steps.

## Installing and Configuring Shiny

First, follow the instructions to [install and configure Shiny Server](https://www.rstudio.com/products/shiny/download-server/).

When you have installed and configured Shiny and you're sure it works, modify your config file so it only serves to 127.0.0.1 (the local machine). This ensures that we don't accidentally expose the open server to the entire Internet.

```
[...]
server {
  listen 3838 127.0.0.1;
[...]
```

## Installing Apache and the OpenID Connect Module

We will use Apache as a gateway to our app using [Auth0's tutorial](https://auth0.com/docs/server-platforms/apache). This will enable Apache to serve as a gatekeeper—a reverse proxy that only serves after authentication.

If you don't already have apache2 installed, install it according to your platform and ensure that you have two modules: mod_proxy and mod_auth_openidc.

mod_proxy is pretty standard. It comes with most apache2 installs, but it is often disabled. To enable it, execute the following with root:

```
a2enmod proxy_http
```

mod_auth_openidc is provided in Debian as libapache2-mod-auth-openidc. Binary packages are available at [the releases page](https://github.com/pingidentity/mod_auth_openidc/releases), or you can always [build it from source](https://github.com/pingidentity/mod_auth_openidc/blob/master/INSTALL). When it is installed, enable it with this command:

```
a2enmod auth_openidc
```

## Configure an Auth0 Account

If you don't already have an Auth0 Account, <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">create one here</a> and set up the type of connections you want to allow. The default settings allow anyone to sign up, but you can set up a better scheme. For example, if you use Google Apps, you can just connect that and [allow only those from your domain to access the server](https://manage.auth0.com/#/connections/enterprise). Alternatively, you can use [rules](https://manage.auth0.com/#/rules) to decide which users are allowed access.

You can [browse the docs](https://auth0.com/docs) or [ask for help](https://support.auth0.com) setting up the best scheme for your scenario.

## Configure Apache to Serve Shiny with Auth0

Make sure Shiny is running in the background while Apache tries to serve it. You can ensure that it's always on by [running it as a Daemon](https://rstudio.github.io/shiny-server/latest/#stopping-and-starting).

You will need to follow the steps in [the Apache tutorial](https://auth0.com/docs/server-platforms/apache). Note: when you are logged in to Auth0, the tutorial includes your own variables in the configuration to make it easier for you.

Create a configuration file for your website using the configuration from the tutorial as a starting point. Replace everything from OIDCProviderIssuer to Location with the code in the tutorial.

You will need to personalize your OIDCRedirectURI. I recommend using https://<your_apache_server>/auth. Of course, replace <your_apache_server> with the public address that will be used for your server.

You also need to generate or write some random string on <passwordToEncryptTheSessionInformationOnTheCookie>

You should at least have a [self-signed SSL certificate](https://devcenter.heroku.com/articles/ssl-certificate-self) to test and a real one to deploy.

It should look something like this:

```
<VirtualHost *:443>
  ProxyPass / http://localhost:3838/
  ProxyPassReverse / http://localhost:3838/
  ProxyPreserveHost On

  OIDCProviderIssuer https://<your-tenant>.auth0.com
  OIDCProviderAuthorizationEndpoint https://<your-tenant>.auth0.com/authorize
  OIDCProviderTokenEndpoint https://<your-tenant>.auth0.com/oauth/token
  OIDCProviderTokenEndpointAuth client_secret_post
  OIDCProviderUserInfoEndpoint https://<your-tenant>.auth0.com/userinfo

  OIDCClientID <YourClientID>
  OIDCClientSecret <YourClientSecret>

  OIDCScope "openid profile"
  OIDCRedirectURI https://<your-website>/auth
  OIDCCryptoPassphrase <passwordToEncryptTheSessionInformationOnTheCookie>
  OIDCCookiePath /

  SSLEngine on
  SSLCertificateFile /path/to/server.crt
  SSLCertificateKeyFile /path/to/server.key

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

</VirtualHost>
```

You can save it somewhere like ``/etc/apache/sites-available/001-shiny` and then link it to make it active:

```
ln -s /etc/apache/sites-available/001-shiny /etc/apache/sites-enabled/001-shiny
```

As the tutorial states, Auth0's `clientSecret` is by default Base64 encoded, which isn't compatible with this Apache plugin out of the box. We're going to change that in the near future, but in the meantime, you need to call an API to make sure the clientSecret isn't Base64 encoded for your account.

Get an access token by clicking "Try Me!" on the [docs page](https://auth0.com/docs/api/v1#!#post--oauth-token) and execute the code shown in step 3 of the tutorial to change `ACCESS_TOKEN` to the access token you just received.

## Boom.

Now you have a Shiny Server that is secured with Auth0, which you can use to serve reports only to employees of your organization using username and password authentication or [one of the many identity providers supported](https://auth0.com/docs/identityproviders).

This same configuration works well for other cases. For example, suppose you have an old legacy web application for which everyone uses the same password. That scenario is not very safe, is it? You can give it an additional security layer with the above approach without modifying your site.

## Gotchas

Shiny uses websockets for a lot of things. While we haven't explored tunneling, it is theoretically possible with **proxy_wstunnel**. For most users, this will work fine because if the library fails with websockets, it will automatically fall back to XHR.


Adding Authentication to Shiny Open Source Edition

0cd73f2f2f39709bd03646e9225cc3d3?s=200 avatar

0cd73f2f2f39709bd03646e9225cc3d3?s=200

I’m an engineer with a passion for building frictionless products. I’ve built effective teams and have grown them into successful engineering organizations. I like to forge a culture.

CTO and Co-founder

Matias Woloski

Json Web Tokens (JWT) gets a logo, new website and more

In 2013 when we started building Auth0 we had to decide which standard we wanted our platform to be built on. Back then there was [WS-Fed](https://en.wikipedia.org/wiki/WS-Federation) and [SAML2](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). I was very familiar with both, having worked on many projects with Microsoft technologies. My main issue with these standards was that they were too complex: too many knobs and levers, interop issues and above all, a lack of libraries.



On the other extreme we had OAuth2 which was rapidly being adopted because of its simplicity. It was also being used by Facebook, Google and many others. There were already libraries written in many languages, making it even more appealing.

However, [OAuth2](https://tools.ietf.org/html/rfc6749) was/is an __authorization__ protocol, not one specific for __authentication__ [[1](http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html)] [[2](http://homakov.blogspot.com.ar/2012/08/oauth2-one-accesstoken-to-rule-them-all.html)].

[OpenID Connect](http://openid.net/specs/openid-connect-core-1_0.html) was being drafted as a very thin layer on top of OAuth2 to overcome exactly that issue. With the introduction of [JSON Web Tokens](https://tools.ietf.org/html/rfc7519) there was now a simple way of verifying user identity and audience (the consumer of these tokens).

Back then it was on [draft-06](https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06), and I decided to join the Working Group.

## Why is JWT so popular?

![](https://images.ctfassets.net/23aumh6u8s0i/6eRP0BpQt8Hf1qY6WHNRGk/34336bf2f0d2af90d7d920b9c0ed84c7/jwt-google-trend)

I think there are many reasons why JWT is being widely adopted:

* It embraces JSON which is already heavily adopted across many stacks.
* It is simple to use and simple to implement (hence more libraries and fewer interop issues).
* It supports symmetric and asymmetric crypto which solves the majority of use cases.

## Numbers speak for themselves

About 2 years since the first draft this simple, yet useful standard expanded:

![](https://images.ctfassets.net/23aumh6u8s0i/1PUSHZTPdUqD2jvVlkN47L/9f2f1b3696ac54aae970f444e9751a0d/banner-jwt)

* [972 GitHub repos](https://github.com/search?q=jwt) related to JWT.
* [2600+ StackOverflow](http://stackoverflow.com/search?q=jwt) threads.
* 400K page views on [jwt.io](http://jwt.io).
* [50K Google](https://www.google.com.ar/search?q="json+web+token") results.

If you use Android, AWS, Microsoft Azure, Salesforce, or Google then chances are that you are already using JWT.

<include src="TweetQuote" quoteText="If you use AWS, Microsoft Azure, Salesforce, or Google then chances are that you are already using JWT."/>

We very much believe in this standard so we wanted to keep making contributions to foster its adoption. We are happy to share the **new logo**, the **new website**, **badges**, and other things. :)


## New Logo

The central component of the branding is a logo symbol representing an individual JSON Web Token. The circular icon was designed to suggest a coin while avoiding being mistaken for a digital currency symbol.

Here are some initial sketches and colors:

![](https://images.ctfassets.net/23aumh6u8s0i/4XQlyCKEVRjmXqvPOwSj5q/3af5e76fc7292dfd4e7b437d282a9eaf/jwt_02)
![](https://images.ctfassets.net/23aumh6u8s0i/2idVA183X17v3CfGC0uOmB/35b22395ff6ee0bbd090f81a57cd08c1/jwt_04)

We decided to use the starburst shape representing the crypto protection of a JSON Web Token. Multicolored spokes radiate from the centralized hub representing the various claims within a payload.
Here is the final symbol:

![](https://images.ctfassets.net/23aumh6u8s0i/6sw33rq7EM8nCi5Gov3RCD/6b1d1cf37d688b3e81d2445da694e938/jwt_01)

JSON Web Token has been abbreviated to the initials JWT and custom lettering was developed.

![](https://images.ctfassets.net/23aumh6u8s0i/6w5TnOcVKczBfjTvk5zpWU/96dd7ee784a2171e263bc71a15f9b343/jwt_03)
![](https://images.ctfassets.net/23aumh6u8s0i/16VIM0ExdiVtMpEVamzZzG/a0b6699a966257d51fa001ab55ddf5b4/jwt_05)

## New Site

We redesigned [jwt.io](http://jwt.io), incorporating the new branding. The debugger is still the central piece. We added support for RS256 in addition to HS256.

<img src="https://images.ctfassets.net/23aumh6u8s0i/5ng8giWbaI8NDj6ze9gLje/912d6a18286b995b182592eafda32760/jwt-1" class="expand"/>

In the libraries section, we improved the readability by color coding each library and using the proper logos for each. In addition to that, we added the number of stars from the GitHub repository.

<img src="https://images.ctfassets.net/23aumh6u8s0i/58Jbwy39S0YKyg9rDsICdv/d619bf661636457130fa4a31c948d68b/jwt-2" class="expand"/>

## Badges and Others

If your API supports JSON Web Tokens, feel free to add this badge

![](https://images.ctfassets.net/23aumh6u8s0i/jZkOsCfAXX0zSbq0Ae82v/77da371796a706d6b96b7cda06c6cde5/jwt-compatible)

If there is some functionality on your site that uses and exposes JSON Web Tokens, you can use the following button to open the JWT on jwt.io.

[![](https://images.ctfassets.net/23aumh6u8s0i/38tcsWr8NpjrGjCwMWQLZ7/b786abbaf88c090d025319eb3a91a087/jwt-view)](http://jwt.io/#id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ)

The token is sent through the hash like this: `http://jwt.io/#id_token=eyJhbGciOi....`

Finally, we designed some cool JWT t-shirts that you can order from [swag.auth0.com](http://swag.auth0.com).


## Acknowledgements

Special thanks to [Ty Wilkins](http://tywilkins.com/) for crafting the logo and lettering, [Ricky Rauch](http://twitter.com/rickyrauch) and [team](http://dribbble.com/auth0) for the awesome looking website, [Alberto Pose](http://twitter.com/thepose) who created the initial jwt.io version and curates the community contributions, [Guillermo Rauch](http://twitter.com/rauchg) for his constant advice, [Mike Jones](http://self-issued.info) for introducing me into the working group and all of you who [contributed to jwt.io](https://github.com/jsonwebtoken/jsonwebtoken.github.io/graphs/contributors) through GitHub.

**JWT all the things!**

<include src="asides/Jwt" />

"openid-connect"