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

We released a new version of the .NET SDK for desktop and mobile applications. Learn what’s new.

We're thrilled to announce the newest release of the [Auth0 OIDC Client for .NET](https://github.com/auth0/auth0-oidc-client-net), bringing enhanced support and improvements to your desktop and mobile applications. This update focuses on future-proofing your applications by adding support for **.NET 9**, ensuring you're ready for the latest advancements in the .NET ecosystem.

## Key Highlights

Here are the main improvements provided by this release:

* **.NET 9 Support:** This release officially adds support for .NET 9 across WPF, WinForms, iOS, Android, and MAUI platforms.
* **MAUI issue fix**. With this release, we work around a [well-known issue with WebAuthenticator support in Windows](https://github.com/microsoft/WindowsAppSDK/issues/441).
* **Latest Dependencies:** Under the hood, this release includes the latest version of [Auth0.OidcClient.Core (version 4.1.0)](https://www.nuget.org/packages/Auth0.OidcClient.Core/4.1.0), which includes various underlying improvements and fixes.

What this means for you:

* **Future-Proofing:** By adopting this version, you're ensuring your authentication logic remains compatible as you migrate to .NET 9.
* **Continued Compatibility:** This release maintains compatibility with previous .NET versions, allowing for a smooth transition.
* **Enhanced Stability:** Leveraging the updated core library contributes to a more stable and reliable authentication process within your applications.

## Get Started Today!

Updating your Auth0 OIDC Client for .NET is straightforward. You can find the latest packages on NuGet, based on your UI framework:

* [Auth0.OidcClient.WPF - ver. 4.3.0](https://www.nuget.org/packages/Auth0.OidcClient.WPF/4.3.0)
* [Auth0.OidcClient.WinForms - ver. 4.3.0](https://www.nuget.org/packages/Auth0.OidcClient.WinForms/4.3.0)
* [Auth0.OidcClient.iOS - ver. 4.3.0](https://www.nuget.org/packages/Auth0.OidcClient.iOS/4.3.0)
* [Auth0.OidcClient.Android - ver. 4.1.0](https://www.nuget.org/packages/Auth0.OidcClient.Android/4.1.0)
* [Auth0.OidcClient.AndroidX - ver. 4.3.0](https://www.nuget.org/packages/Auth0.OidcClient.AndroidX/4.3.0)
* [Auth0.OidcClient.MAUI - ver. 1.3.0](https://www.nuget.org/packages/Auth0.OidcClient.MAUI/1.3.0)
* [Auth0.OidcClient.UWP - ver. 4.2.0](https://www.nuget.org/packages/Auth0.OidcClient.UWP/4.2.0)

Simply update your project dependencies to the latest version to take advantage of these improvements.

We're committed to providing you with the best possible authentication experience. This release is a step towards ensuring your .NET applications are ready for the future. Stay tuned for more updates and features!

Learn More:

* [Auth0 OIDC Client for .NET Documentation](https://auth0.github.io/auth0-oidc-client-net/)
* [GitHub Repository](https://github.com/auth0/auth0-oidc-client-net)

Thank you for being a part of the Auth0 community!

Announcing a New Release of the Auth0 OIDC Client for .NET

A new version of the Auth0 Templates for .NET package has been released: discover the new powerful features.

In May, we [announced the release of Auth0 Templates for .NET](https://auth0.com/blog/introducing-auth0-templates-for-dotnet/), a NuGet package that allows .NET developers to scaffold a new project with Auth0 embedded. Today, we are announcing the release of a new powerful version of the package: [Auth0 Templates for .NET 2.1](https://www.nuget.org/packages/Auth0.Templates). 🎉

Go to your terminal window and install the new package by running the following command:

```bash
dotnet new install Auth0.Templates
```

> ⚠️ If you already have a previous version of the package installed on your machine, please uninstall it using the following command before installing the new package:
>
> ```bash
> dotnet new uninstall Auth0.Templates
> ```
>
> 

Let's explore what's new and how you can now create **a working application with Auth0 authentication in less than a minute!**

## Auth0 CLI integration

The most prominent feature introduced in this new release is the integration with the [Auth0 CLI](https://github.com/auth0/auth0-cli), the command line tool that allows you to manage your Auth0 tenants and your application registration from your terminal window.

> 📖 If you are new to the Auth0 CLI, take a look at [the Auth0 CLI Basics Lab](https://developer.auth0.com/resources/labs/tools/auth0-cli-basics) to learn how to use it.

If you have the Auth0 CLI installed on your machine and are already logged in to your Auth0 tenant, you can have your new application automatically registered. Let's do an example to better explain.

### Self-Registration in .NET CLI

Suppose you want to create a Blazor Server application with Auth0 authentication embedded. You can start by running the following command in a terminal window:

```bash
dotnet new auth0blazorserver -o MyBlazorServerApp
```

This command uses the `auth0blazorserver` template to create a Blazor Server application in the `MyBlazorServerApp` folder.

After launching the command, you will see a message similar to the following:

```bash
The template "Auth0 Blazor Server App" was created successfully.

Processing post-creation actions...

Template is configured to run the following action:
Actual command: register-with-auth0.cmd 
Do you want to run this action [Y(yes)|N(no)]?
```

With this message, the template engine asks if you want to register the newly created application with Auth0.

Once you confirm, the new Blazor application will be registered on your current Auth0 tenant. You will see the registration data onscreen for documentation purposes only, as you don't need to configure it manually. In fact, your new application will be automatically configured. All you need to do is run your Blazor application with `dotnet run`!

As you can see, using the integration with the Auth0 CLI allows you to have **an application up and running in less than a minute!**

Of course, you can still pass the configuration options on the command line in case you don't have the Auth0 CLI installed or if you have already registered the application with Auth0. See the [specific options for each template](https://github.com/auth0/auth0-dotnet-templates#usage) for more details.

### Auth0 registration in Visual Studio

If you are using the templates with Visual Studio, you can't leverage the self-registering feature. This is not a limitation of the template, but a restriction imposed by Visual Studio (see [this issue](https://github.com/dotnet/templating/issues/4575) for context).

However, you can run the registration action manually. So, assuming you want to create your Blazor Server application with Visual Studio, select the Auth0 Blazor Server App template as shown in the following picture:

![Auth0 Blazor Server template in Visual Studio](https://images.ctfassets.net/23aumh6u8s0i/4vIKOhrrozhmSDMkYPsEUr/5bd66766af25db726fb3aca5c4d731ab/auth0-blazorserver-app-vs.png)

Then, accept the default values proposed by the template configuration window and create the project.

After the project is created, go to the newly created application and run the following command:

```bash
./register-with-auth0.cmd
```

This command will automatically register your Blazor Server application with Auth0 and configure your application.

> Note: On MacOS you must enable the script to execute. Run the following command before launching the automatic registration:
>
> ```bash
> chmod +x register-with-auth0.cmd
> ```

## .NET 8 Support

The new release of Auth0 Templates for .NET supports .NET 8 by default for most templates. When you use the `dotnet new` command without specifying a framework version, you will get a .NET project with .NET 8 as the target framework. This is also the default .NET version when you are using Visual Studio, as shown below:

![Auth0 Template for ASP.NET Core MVC targeting .NET 8](https://images.ctfassets.net/23aumh6u8s0i/1mnYGKi2t006MED0sC2raQ/902bd9cb7b94be9e4b0d4c6c14b9d3ea/auth0-mvc-app-vs-options.png)

Blazor templates do not currently support .NET 8, but they still target .NET 7. The reason for this choice depends on the new .NET 8 Blazor model, which provides a more fluid approach between the Server and the WebAssembly hosting models. Currently, there are no official guidelines on how to integrate OpenID Connect with the new Blazor model. If you are interested in this topic, you can follow [this thread in the Auth0 Community forum](https://community.auth0.com/t/net-8-0-blazor/119691) to stay updated.

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

## Minimal API Template

The [Auth0 Templates for .NET package](https://www.nuget.org/packages/Auth0.Templates/) contains four templates since its first release:

- ASP.NET Core MVC
- ASP.NET Core Web API
- Blazor Server
- Blazor WebAssembly (ASP.NET Core hosted)

This new release adds a new template for [ASP.NET Core minimal API](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis). To use this template, add the `--minimal` option to the `dotnet new auth0webapi` command, as shown in the following example:

```bash
dotnet new auth0webapi -o MyWebAPI --minimal
```

This command creates a minimal API project in the `MyWebAPI` folder, and if you have the .NET CLI installed on your machine, it also registers it with Auth0.

In Visual Studio, you can simply select the *Use minimal API* checkbox as shown in the following picture:

![Options for the Auth0 ASP.NET Core Web API template in Visual Studio](https://images.ctfassets.net/23aumh6u8s0i/30Wl7yaOdnuWBhmdbRZa3v/259aa7ca9bb215da9fba8e62bfee8d87/auth0-webapi-app-vs-options.png)

## Looking Ahead

We hope that these new features will help .NET developers set up their new applications with Auth0 more easily than before. Our goal for the next release is to include a template for the missing Blazor model and add templates for other .NET application types.

Your feedback is valuable. If you experience a problem or have a request, please [open an issue](https://github.com/auth0/auth0-dotnet-templates/issues/new/choose) on the project's GitHub repository.

Remember that [Auth0 Templates for .NET](https://github.com/auth0/auth0-dotnet-templates) is an open source project, so your contribution is welcome! If you think you can help, check out [our contribution policy](https://github.com/auth0/auth0-dotnet-templates/tree/main#contributing) and get involved.



Auth0 Templates for .NET: A New Powerful Version Released

What's new in .NET 6? What are the main relevant features brought by the new version of the .NET platform? Let's take a quick look.

With the release of .NET 6, Microsoft consolidates its plan to create a unified platform to develop applications for any device and operating system. Together with this vision, .NET 6 brings many new features aiming to simplify development and gain performance. Let's take a quick look at the main points.

## Unified Platform Support
The vision of a [unified platform for the .NET world started with .NET 5](https://auth0.com/blog/dotnet-5-whats-new/). That release was meant to be the unified successor of [the various .NET flavors: .NET Framework, .NET Standard, .NET Core, Mono](https://auth0.com/blog/navigating-dotnet-maze/), etc. Beyond this goal, .NET 5 wanted to be a development platform to create any kind of application for any platform. However, at that time, an important piece was missing to complete the puzzle: a unified framework to create cross-platform UIs. Now, with [.NET MAUI](https://devblogs.microsoft.com/dotnet/announcing-net-maui-preview-10/), i.e., the **.NET Multi-platform App UI** framework, the puzzle is complete. Although at the time of writing [.NET MAUI is in preview](https://devblogs.microsoft.com/dotnet/announcing-net-maui-preview-10/), it is mature enough to be considered part of the .NET 6 release.

Now with .NET 6, you can really create the application you want and run it practically everywhere: from desktop to mobile, from the web to the cloud.

![.NET 6 unified platform](https://images.ctfassets.net/23aumh6u8s0i/GOa5gfL6LckpRRhqaBRJe/69341464075cbd46cf88fcbe36af4aa5/dotnet-unified-platform.png)

<p align="center">
[[*Source: Microsoft*](https://devblogs.microsoft.com/dotnet/announcing-net-6/)]
</p>

In particular, the new [.NET MAUI](https://github.com/dotnet/maui) framework allows you to build desktop and mobile native user interfaces with a single codebase.

![.NET MAUI overview](https://images.ctfassets.net/23aumh6u8s0i/4WkvXpMRwu7j5T82HiW04A/069649d85ea4e1def0831672b5fc8698/dotnet-maui-overview.png)

<p align="center">
[[*Source: Microsoft*](https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/)]
</p>

## Simplified Development
One of the main goals of the .NET 6 release is to provide developers with features that simplify their work. You can find support for simplified development throughout the platform, but three contexts are really exciting: new C# features, Hot Reload support, and minimal web APIs.

### C# 10 features
.NET 6 brings you [C# 10 with plenty of new features](https://devblogs.microsoft.com/dotnet/welcome-to-csharp-10/) that help you write code more easily. Let's take a quick look at a few of them.

#### Global and implicit usings

As a C# developer, you know how annoying it is to declare the same namespace in every file of your project. Consider, for example, the `System` namespace. Its use is very common, and I'm pretty sure you forget it all the time and let Visual Studio suggest it.

Now you can declare namespaces using a global `using`, as shown in the following example:

```csharp
global using System;
```

With this declaration, you don't need to insert the `using System;` declaration in all files anymore. You can declare a namespace through `global using` in any file, and it will be available in the entire project.

If you prefer (and I think it's a good practice), you can declare your namespaces in a file named `GlobalUsings.cs`.

You can also take advantage of implicit `using`s by configuring the `<ImplicitUsings>` element in your `.csproj` file, as shown below:

```xml
<PropertyGroup>
    
    <ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
```

This way, the compiler will automatically add the required `global using` directives based on the type of your project.

#### New namespace syntax

You know that the usual way to declare a namespace is as follows:

```csharp
namespace Geometry
{
  class Triangle 
  {
    // ...class members...
  }
}
```

Now you can use the file-scoped namespace syntax to get the same result:

```csharp
namespace Geometry

class Triangle 
{
  // ...class members...
}
```

With this approach, everything you define in the current file belongs to the declared namespace. By removing a nesting level, you make the code a bit cleaner. However, you can't create nested namespaces with this new syntax.

#### Natural types for lambda expressions

Consider the following assignment of a lambda expression to a variable:

```csharp
Func<string, int> parse = (string s) => int.Parse(s);
```

You need to declare the target type of the lambda expression, `Func<string, int>` in the example. Starting with C# 10, you can write the above code as follows:

```csharp
var parse = (string s) => int.Parse(s);
```

The compiler will try to infer the "natural" type of the lambda expression.

### Hot Reload
To improve the developer's productivity, .NET 6 extends [the Hot Reload feature](https://devblogs.microsoft.com/dotnet/announcing-net-6/#hot-reload) to Visual Studio and almost any type of project. It allows you to run an application in your development environment, make changes, and get the changes applied without stopping, rebuilding, and rerunning the application.

In previous .NET releases, this feature was available just for the .NET CLI via the `dotnet watch` command. Not without [some minor hiccups with the community](https://www.theverge.com/2021/10/22/22740701/microsoft-dotnet-hot-reload-removal-decision-open-source), you can now benefit from it in [Visual Studio 2022](https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/#improved-user-experience-in-visual-studio-2022) as well by simply clicking a button:

![Visual Studio 2022 Hot Reload button](https://images.ctfassets.net/23aumh6u8s0i/3wu09sA8C4IQ5uKfmGoITK/e13d618f3f497e72281665de780b472d/vs2022-hot-reload-button.png)

<p align="center">
[[*Source: Microsoft*](https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/)]
</p>

### Minimal web APIs
One astonishing feature introduced by .NET 6 to simplify your code is [minimal web APIs](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis). Along the lines of top-level statements, now you can build a fully working web API application with a few lines of code. Consider the following sample:

```csharp
//Program.cs
var app = WebApplication.CreateBuilder(args).Build();

app.MapGet("/", () => "Hello World!");
app.Run();
```

This is all the code you need to run a simple *Hello World!* web API.

If you have some experience building web APIs with ASP.NET Core, you know that you usually need a more articulate project. You need at least a `Program.cs` file with the setup code for the application, a `Startup.cs` file where you configure your API, and a controller class defining the API routes and implementing the endpoints.

That's a lot of simplification!

## Performance Improvements
In the last years, the .NET team put a lot of effort into improving the platform performance in compiling and execution time and reducing memory consumption. With .NET 6, you can appreciate these improvements in many parts of the framework. For example, the effort to [improve inner-loop performance](https://github.com/dotnet/core/issues/5510) in building .NET projects has given awesome results, as you can see from the following diagram:

![dotnet6-build-improvements](https://images.ctfassets.net/23aumh6u8s0i/2ZVS4o4DKc6OroBO0Lb76b/187a5cbf18d934d9a1cefae71f1535f5/dotnet6-build-improvements.png)

<p align="center">
[[*Source: Microsoft*](https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-2/)]
</p>

Other performance improvements include the IO subsystem. For example, the `FileStream` class [was almost completely rewritten](https://devblogs.microsoft.com/dotnet/file-io-improvements-in-dotnet-6/) with amazing results even with respect to .NET 5, as the following table summarizes for the writing operation:

![FileStream performance improvement](https://images.ctfassets.net/23aumh6u8s0i/6RgFjbKytdIQk6pHtEaHxT/1d524bb8a02e4688979d71f3151aef3f/filestream-performance-improvement.png)

<p align="center">
[[*Source: Microsoft*](https://devblogs.microsoft.com/dotnet/announcing-net-6/)]
</p>
You can check out [a detailed report on performance improvements in .NET 6](https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/) with related benchmarks for more information.

## Summary

This quick overview of .NET 6 shows that this is a consolidation release of the .NET platform. It aims to complete the unified platform vision started with .NET 5, improves the internals of the platform to provide the best performance, and starts a process of development simplification that probably will go further in future releases.

<include src="asides/DotNetCore" />

.NET 6 Highlights

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

Let's dive into the updates that Node.js version 14 gives us!



That's right! Node.js version 14 is here! 🎉

Whether you have upgraded your Node version already or are thinking about doing it soon, let's discuss some of the things that this new version gives us! We'll even chat about older versions and what to expect there in the coming months.

<AmpContent>
    <amp-twitter width="375"
      height="472"
      layout="responsive"
      data-tweetid="1252616090422775809">
    </amp-twitter>

</AmpContent>

<NonAmpContent>

  <blockquote class="twitter-tweet"><p lang="en" dir="ltr">Node.js v 14 is here! 🎉💚 <a href="https://t.co/iB7dK5uljY">https://t.co/iB7dK5uljY</a></p>&mdash; Node.js (@nodejs) <a href="https://twitter.com/nodejs/status/1252616090422775809?ref_src=twsrc%5Etfw">April 21, 2020</a></blockquote> 
  <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

</NonAmpContent>

## How to Upgrade

Want to upgrade your current Node.js version? Following the instructions [here](https://nodejs.org/en/download/current/) to download for any operating system: macOS, Windows, and Linux. We will find that Node.js 14.0.0 includes npm 6.14.4.

## What's New?

There are many things to look forward to with this major release. Some of the new features include:

1. The once experimental feature, Diagnostic Reporting, is now stable!
2. V8 has been upgraded to V8 8.1
3. Node Streams have been updated
4. Removal of Experimental Modules Warning

Let's walk through these!

To find the full list of changes, you can [visit this page](https://nodejs.org/en/blog/release/v14.0.0/). 

<include src="TweetQuote" quoteText="That's right! Node.js version 14 is here! 🎉"/>

### Diagnostic Reporting is now stable!

Diagnostic reporting generates a JSON-formatted file that can aid in diagnosing problems. When things go wrong in your app, like slow performance or memory leaks, it's helpful to have a full report on where issues are occurring. Even if our app were to crash, this report would have information on that as well. We can run this report in development, testing, or production.

Back when Node.js v12 was released, [diagnostic reporting](https://nodejs.org/api/report.html) was experimental. We now have it as a stable feature in this new version. 

To run the report, run the following in your command line:

```bash
node --report-uncaught-exception --report-on-signal \
--report-on-fatalerror app.js
```

Let's break down this command:

* `--report-uncaught-exception`: The report will generate on uncaught exceptions. We want to make sure all errors are caught and handled.
* `--report-on-signal`: This will allow for reports to be generated when a specific signal is sent to the Node.js process.
* `--report-on-fatalerror`: Reports all the fatal errors. It lets us know of all the errors that would cause our js applications to stop working.
* `app.js`: Where we are running the diagnostic report.

> There are many different variations to this command. Visit [this page](https://nodejs.org/api/report.html) for the official docs on diagnostic reporting in Node.js and other ways to use the command.

<include src="TweetQuote" quoteText="Diagnostic Reporting is now stable in Node.js v14!"/>

### V8 upgraded to v8.1

This Node.js v14.x release also comes with the newly upgraded [Javascript engine: v8.1](https://v8.dev/blog/v8-release-81)!

There are a handful of things that were added into this version; one that we'll cover here is the [nullish coalescing operator](https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_Coalescing_Operator).

The nullish coalescing operator looks like this: `??`. The operator returns the results of the expression to the right of the operator only when the expression to the left of it is `null` or `undefined`. Otherwise, the results from the left expression are returned. Let's see that in action:

```javascript
const newVersion = null ?? 'Does this work?';
console.log(newVersion);
// expected output: "Does this work?"

const nullishTest = 0 ?? 55;
console.log(nullishTest);
// expected output: 0
```

The value on the left-hand has to be `null` or `undefined` for the right-hand value to be ran. So in the second example, it was a `0` on the left; because that is not `null` or `undefined`, it returned with the `0` number.

This helps a lot with values that are returned `null` or `undefined` when we were not expecting them to do so. So if something happens in our app and it returns `null`, the operator moves on to maybe an error message or a default value (the value on the right-hand side of the operand) and gives the user something to see.

Some other things that are in v8.1 include:

* [Optional Chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)
* [Intl.DisplayNames](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DisplayNames)
* [Enables calendar and numberingSystem options for Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat)

### Streams

Streams can help with many things in Node, here are a few:

* Handling data
* Handling writing/reading files
* Network communication

Streams have not been recently added (they've been around for a while), but consistency has improved. [Some examples that were mentioned](https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e#4f1c) were:

* `http.OutgoingMessage` is similar to `stream.Writable`. To learn more about `stream.Writable`, visit [this docs page](https://nodejs.org/api/stream.html#stream_class_stream_writable).
* `net.Socket` behaves exactly like `stream.Duplex`. To learn more about `stream.Duplex`, visit [this docs page](https://nodejs.org/api/stream.html#stream_class_stream_duplex).

A [blog post by Michael Dawson and Bethany Griggs recommends](https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e#4f1c) that if your application relies heavily on streams, start testing now! This will help us get ready for the Node.js v14 LTS release in October 2020.

The full stream module official documentation can be found [here](https://nodejs.org/api/stream.html).

### Removal of Experimental Modules Warning

When running an ECMAScript Modules (ESM) in Node.js, we would get an "Experimental Warning". That warning has now been removed. That's it! It's still experimental, the warning has just been removed. 

![GitHub view of warning text being removed](https://images.ctfassets.net/23aumh6u8s0i/2gZ5cHBFGnWCndRMuCjrZQ/3c5129df9fd6b9394f8d69e4bcb7f064/experimental-modules-warning)
([Source](https://github.com/nodejs/node/commit/22b6997abae339202d77877368f50ae52b890c44))

ESM is JavaScript's standard module system. It helps with managing variables, organizing functions, and grouping things that would make sense in our code. To learn more about this feature, check out [the official documentation](https://nodejs.org/api/esm.html).

ESM is the best module format thanks to its simple syntax, async nature, and tree-shakeability.

## Experimental Additions

In this version update, we see a couple of experimental additions. Those include:

1. [Experimental Async Local Storage API](https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage)
2. [Experimental Web Assembly System Interface](https://nodejs.org/api/wasi.html)

Head on over to the [official Node.js v14 docs](https://nodejs.org/api/) to find out all the updates and experiments! 

## What About Older Versions?

Nervous about what is going to happen to your older versioning? Not ready to upgrade just yet? The older versions will lose their support soon, but we've got time! The LTS version release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months.

We can see the support and release line here:

![Current release schedule](https://images.ctfassets.net/23aumh6u8s0i/77cPUuzd0qRGBtZCPHrqSm/e99ec8aab7ac969895cd2b0f9d263ef3/release-timeline)
([Source](https://nodejs.org/en/about/releases/))

<include src="asides/Node" />

## Conclusion

This Node.js release is exciting, and after looking at some of the new updates, I'm super excited to try it! Let me know if you have updated your Node.js version and what you think of version 14. 

---


Node.js v14: What's New?

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

We have released new versions of JWT.io and the JWT Debugger extension, learn what's new.



We have released another round of updates for our [JWT.io](https://jwt.io/) website and the JWT Debugger extensions ([Chrome](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)). Among the new features are [HMAC](https://en.wikipedia.org/wiki/HMAC) secret length hints, common claim descriptions, simplified library updates for the website, a share button for the website, support for plain RSA public keys, and more token types can be passed in the URL! In this post, we will go over these new features.

<include src="TweetQuote" quoteText="A new round of updates for JWT.io and the JWT Debugger extensions have been released!"/>

---

## JWT.io and the JWT Debugger extension
[JSON Web Tokens (JWTs)](https://jwt.io/introduction/) are a convenient way to exchange claims between parties. The key features of JWTs are their simple format (Base64-encoded JSON) and the use of signatures and/or encryption. [JWT.io](https://jwt.io/) provides a convenient way to debug and inspect [JSON Web Tokens (JWTs)](https://auth0.com/e-books/jwt-handbook), along with an introduction to some of the key concepts behind them. It also provides a list of libraries and frameworks that can be used with them in many different programming languages.

The JWT Debugger extensions ([Chrome](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)) are the [Web Extension](https://browserext.github.io/browserext/) versions of JWT.io. The debugger has the same features as the website but can be used offline. It also provides additional features like automatic inspection of web storage and cookies to easily find and edit JWTs in websites!

Now, let's go over the new features of this release!

## New Features
### HMAC Secret Length Hints
As [we have seen on our blog before](https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/), the length of the HMAC secret is one of the fundamental properties to ensure it cannot be brute forced. For this reason, we have added two hints:

- The default secret for all HMAC token examples now hints at the minimum required length.

![Default secret for HS256 example](https://images.ctfassets.net/23aumh6u8s0i/7bsOiqkha9rbIRXBIaeVhm/ffafe28856d614488a591a39dcdf4cbc/1-hmac-hint-1)

- When typing, a tooltip appears if the secret is too short to be considered safe.

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/2-hmac-hint-2.mp4" controls autoplay loop></video>

Do note, however, that length is not the only thing that is important for secrets. They must also be hard to guess, or, in other words, completely random.

### Share Button
A `share button` to easily pass tokens in URL form has been requested many times, and indeed, it was already available in the extension. Now it is also available on the website!

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/3-share-button.mp4" controls autoplay loop></video>

### Easy Library Updates
Since its inception, adding a new library to the library list at JWT.io has been a cumbersome process. Several [Pug](https://pugjs.org/) and CSS files needed to be edited. Furthermore, editing an existing library had its problems too: to change features one had to remember class names, for example. We have finally modernized the process. Now libraries are located in the `views/website/libraries` folder. There, you will find a JSON file for each language or framework. Inside the JSON file you'll see something like this:

```json
{
  "name": "Node.js",
  "uniqueClass": "node",
  "image": "/img/2.svg",
  "bgColor": "rgb(138, 194, 68)",
  "libs": [
    {
      "minimumVersion": "4.2.2",
      "support": {
        "sign": true,
        "verify": true,
        "iss": false,
        "sub": false,
        "aud": true,
        "exp": true,
        "nbf": false,
        "iat": false,
        "jti": false,
        "hs256": true,
        "hs384": true,
        "hs512": true,
        "rs256": true,
        "rs384": true,
        "rs512": true,
        "es256": true,
        "es384": true,
        "es512": true
      },
      "authorUrl": "https://github.com/auth0",
      "authorName": "Auth0",
      "gitHubRepoPath": "auth0/node-jsonwebtoken",
      "repoUrl": "https://github.com/auth0/node-jsonwebtoken",
      "installCommandHtml": "npm install jsonwebtoken"
    }
  ]
}
```

Multiple libraries go in the `libs` array. Most of the JSON file is self-explanatory, but some values are optional. For full details, check out the [README](https://github.com/jsonwebtoken/jsonwebtoken.github.io/blob/master/README.md) file.

To add a language or framework, a new JSON file must be created. The name of the file should start with a number, followed by a name, and end with `.json`. No further changes are required (other than editing the contents of the file).

It really is that simple!

### JWT.io as OpenID Connect Callback
One of the uses that JWT.io originally supported, was to be set as the callback for OpenID Connect operations (you can do this from the Auth0 Dashboard). That way, after a successful login, developers could be sent automatically to JWT.io with the returned token in the editor. This was disabled a long time ago during refactors. But now, that feature is back!

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/4-jwt-io-callback.mp4" controls autoplay loop></video>

The following URL parameters are recognized: `access_token`, `id_token`, `token`, and `value`.

<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</a> to try this out!

### Common Claims Tooltips
In our previous update, we had enabled tooltips for dates in claims. This time, we have extended tooltips to also show a short description of what the claim means.

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/5-claims-tooltips.mp4" controls autoplay loop></video>

Of course, human-readable dates still work.

### Plain RSA Public Keys
Some RSA implementations work using the [old PEM-encoded RSA public key without the X.509 `SubjectPublicKeyInfo` header](https://stackoverflow.com/questions/18039401/how-can-i-transform-between-the-two-styles-of-public-key-format-one-begin-rsa) that is much more common nowadays. Unfortunately, old versions of JWT.io did not support these keys. But that's no longer the case! Plain RSA keys of yore are now supported, try it out!

<include src="TweetQuote" quoteText="The new round of features for JWT.io include: HMAC secret length hints, a share button, easy library updates, JWT.io as OIDC callback, common claim tooltips, and plain RSA pubkeys!"/>

## Other Changes
Of course, not every change in this release is related to new features. In this release, we have also:

- Merged **all PRs**.
- Added **6 new libraries** (thanks to external contributors!).
- Updates **12 libraries** (thanks again to external contributors!).
- Improved the [README file](https://github.com/jsonwebtoken/jsonwebtoken.github.io/blob/master/README.md).
- Implemented some **design changes**.
- Passed the **100 combined tests** mark!
- And fixed a good deal of bugs.

<include src="asides/Jwt" />

## What's Next
After all these changes, we will now let the codebase stabilize for a while. Of course, if you find any bugs, please report them in [the bug tracker](https://github.com/jsonwebtoken/jsonwebtoken.github.io/issues).

But that is not all! We are also thinking of more ways of improving JWT.io. Here are some of the ideas we are considering at the moment:

- Adding a button to clear the last saved token.
- Allowing the selection of different tokens passed in as URL parameters (`access_token` vs `id_token` for example).
- Support more algorithms, such as `ES512` or the [new EdDSA signatures](https://tools.ietf.org/html/rfc8037).
- Undock capability for the extensions (if possible).

What are your thoughts? Don't hesitate to tell us in the comments or by opening an enhancement request in the [bug-tracker](https://github.com/jsonwebtoken/jsonwebtoken.github.io/issues). Hack on!


Another Round of JWT.io and JWT Debugger Extension Updates



We have released a major update to our [JWT.io](https://jwt.io/) website and the [JWT Debugger](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) extension based on it. Among the new features, there are new signing algorithms, improved public-key handling, human-readable timestamps, and even [Firefox support](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger) for the extension! In this post, we will go over these new features.

<include src="TweetQuote" quoteText="JWT.io and the JWT Debugger extension have been updated with new features!"/>

---

## JWT.io and the JWT Debugger extension
[JSON Web Tokens (JWTs)](https://jwt.io/introduction/) are a convenient way to exchange claims between parties. The key features of JWTs are their simple format (Base64-encoded JSON) and the use of signatures and/or encryption. [JWT.io](https://jwt.io/) provides a convenient way to debug and inspect [JSON Web Tokens (JWTs)](https://auth0.com/e-books/jwt-handbook), along with an introduction to some of the key concepts behind them. It also provides a list of libraries and frameworks that can be used with them in many different programming languages.

The [JWT Debugger extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) is the [Web Extension](https://browserext.github.io/browserext/) version of JWT.io. The debugger has the same features as the website but can be used offline. It also provides additional features like automatic inspection of web storage and cookies to easily find and edit JWTs in websites!

New versions of JWT.io and the JWT Debugger extension have been released. Let's go over the changes.

## New Features
### New Signing Algorithms
For a long time, JWT.io and the JWT Debugger extension only supported the two most popular algorithms: HS256 and RS256. HS256 is an HMAC-based algorithm that relies on a shared secret between parties to produce and verify signatures. On the other hand, RS256 is an RSA-based algorithm, relying on public and private key pairs to sign and verify signatures. The advantages of RS256 are clear: signatures can only be produced by the private-key holder, while verification can be performed by anyone holding the public key. However, the complexity of the implementation for RS256 can make HS256 signatures better for certain use cases (embedded, small devices, etc.).

![New algorithms](https://images.ctfassets.net/23aumh6u8s0i/1NaGCSea11eRFPXlrqP2EO/daed2abf80e328068b91d25647d6f087/1-new-algs)

The new version of JWT.io and the extensions support many more algorithms:

#### HMAC
- HS384
- HS512

These are variants of HS256. HMAC signatures rely on a hash function to produce and verify the signature. In the case of HS256, the hash function is SHA-256. For the other two, the hash functions are SHA-384 and SHA-512. For certain use cases, SHA-512 exhibits better performance than the other two. Security wise, none of these hash functions has been broken.

#### RSA
- RS384
- RS512
- PS256
- PS384

Much like the HMAC counterparts, RSA signatures also rely on a hash function to produce and verify a signature. The same thing changes between RS256, RS384, and RS512.

PS256/384 use a different type of signature (RSA-PSS) that also relies on the RSA algorithm as the baseline. In particular, it uses an encoding method that relies on a random salt value. This produces probabilistic rather than deterministic signatures. It is considered stronger than RS256/384/512 signatures as long as the random salt is truly random. In case the salt is not truly random, it provides the same level of strength as the baseline RSA algorithm

#### ECDSA
- ES256
- ES384

These algorithms rely on the elliptic-curve digital signing algorithm (ECDSA) rather than RSA. The main advantage of ECDSA is that keys can be smaller for a similar level of cryptographic strength. A 256-bit ECDSA key provides a cryptographic strength similar to a 3248-bit RSA key. This makes ECDSA keys better for certain hardware limited devices.

> If you are interested in a detailed rundown of JWT signing algorithms, don't forget to check our [JWT Handbook](https://auth0.com/e-books/jwt-handbook). Chapter 7 goes over all signing algorithms in detail.

#### "none"
JWTs also support setting the `alg` claim to `none`. This means that the JWT is not signed. Unfortunately, this has resulted in [critical vulnerabilities in JSON Web Token libraries](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/). For this reason, JWT.io and the JWT Debugger extensions now consider `alg: "none"` tokens always _invalid_.

### Automatic Public-Key Download
Another interesting feature that has been added is automatic public key downloads. Public-key algorithms, such as RSA, RSA-PSS, and ECDSA, rely on public-keys to verify signatures. Public-keys, like their name implies, can be safely shared without compromising the security of the signature. For this reason, it is not uncommon for JWT public-keys to be available either embedded in the token itself, or in a public URL.

JWT.io and the JWT Debugger extensions now attempt to get public keys in different ways according to the claims embedded in the token.

If the token contains both the `iss` and `kid` claims, JWT.io will attempt to download the token from a specially crafted URL. For example:

```javascript
header: {
  kid: 1
},
payload: {
  iss: "https://username.auth0.com/"
}
```

In this case, JWT.io and the extensions will attempt to download the key with `kid = 1` from the special URL `https://username.auth0.com/.well-known/jwks.json`. This is a [common scheme used by Auth0](https://auth0.com/docs/jwks). In other words, all Auth0 JWTs can now be verified in JWT.io and the JWT Debugger extension by simply pasting the token!

<include src="TweetQuote" quoteText="With automatic key downloads, all Auth0 JWTs can now be verified in JWT.io and the JWT Debugger extension by simply pasting the token!"/>

Of course, since the JWK and JWS standards declare other common schemes for specifying keys, these are also supported: the `jwk`, `jku`, `x5c`, and `x5u` claims. These are used to either embed a key within the token (`jwk` and `x5c`) or to declare a URL to get the keys or certificates (`jku` and `x5u`). For example:

```javascript
header: {
  kid: 1,
  jku: "https://username.auth0.com/.well-known/jwks.json"
}
```

In this case, JWT.io and the extensions will attempt to download the key with `kid = 1` from the URL `https://username.auth0.com/.well-known/jwks.json` specified in the `jku` claim.

### Human Readable Timestamps
Several JWT claims are time-based. For instance, the `iat` claim specifies the exact time the JWT was issued at, the `exp` claim specifies the expiration time for the JWT, the `nbf` sets the time when the JWT becomes valid, etc. Unfortunately, these claims are based on the [Unix epoch](https://en.wikipedia.org/wiki/Unix_time): they specify the number of seconds elapsed since January 1st, 1970. Understanding these values by simply looking at them is hard. For this reason, now JWT.io and the JWT Debugger extensions display a tooltip when the mouse hovers over a supported time claim.

![Human readable timestamps](https://images.ctfassets.net/23aumh6u8s0i/KAGGuSxmdUdMO3YeLBJfh/a21a8482154c72bf97bb527ed7b670b0/2-timestamps)

The supported claims are: `exp`, `iat`, `nbf`, `auth_time`, and `updated_at`.

### Firefox Support
Yes! It's finally here. Ever since the first release of the JWT Debugger extension for Chrome we have received requests for a Firefox version. Now it's here and supports all the features of the Chrome extension. [Get it here](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)!

![JWT Debugger on Firefox](https://images.ctfassets.net/23aumh6u8s0i/3oxA0AoIwuIHbRGmi2gcqh/eb843e039c0aa895d02963ecd0eabb51/3-firefox)

## Streamlined Codebase
Although the new features are the cool part of the release, we have also done a ton of internal work on both JWT.io and the extensions. In particular:

- We have closed over 40 issues and merged over 15 pull requests (some with more libraries!).
- We have synchronized the codebases of JWT.io and the JWT Debugger extensions to always get the latest features out to you, regardless of what you use more.
- We have updated all internal dependencies to the latest versions. This has fixed many bugs here and there and also improved the experience on mobile platforms.
- We have performed a major refactor to improve code quality and latencies during page load. JWT.io is now faster than ever!
- We have added more tests to our test suite. Do check that these pass before submitting new PRs!
- Build scripts are now simpler. Want to contribute? Doing so is as simple as:

Steps:

1. [Checkout from Git](https://github.com/jsonwebtoken/jsonwebtoken.github.io/).
2. `npm install`
3. `grunt`

That's it! You will now find JWT.io available on [http://localhost:8000](http://localhost:8000) and ready for your changes. The extension is also built but you'll need to load it manually in your browser, see the Chrome or Firefox docs for help with this. The resulting code can always be found in the `dist` folder. Send your PRs!

<include src="asides/Jwt" />

## What's Next
Although we have just finished with these changes, there's still more in our pipeline!

- **Key-length tips:** we will show you tooltips when your shared secrets are not long enough.
- **Share button:** the extensions already support this, now it's coming to JWT.io!
- **Library submission process:** we get tons of PRs with new libraries, we want to formalize the process and setup tools so that you can easily review any steps that are required to add your library to JWT.io

We hope you enjoy all the new features and changes at [JWT.io](https://jwt.io/) and the JWT Debugger extensions. Please report any bugs at the [GitHub repository](https://github.com/jsonwebtoken/jsonwebtoken.github.io/) and don't forget to leave us your comments or requests here or in the issue tracker at GitHub. Cheers!



JWT.io and JWT Debugger Extension Updates

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

Sync the database schema up with your application with Flyway

Database Versioning with Flyway and Java

sandrino-di-mattia

Principal Architect

Sandrino Di Mattia

Introducing the new version of our Authorization Extension which adds support for roles and permissions



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---
## Background

Authentication has always been the core of Auth0. But once you know who your users are, you’ll probably also need to know what they can do. Therefore, after authenticating users, you’ll need to authorize them. There are so many different ways to do this, from complex products to home-grown solutions. Using our rules engine, you could also consume this information during the login process.

## Concepts

The Authorization Extension which you can now install using the Extensions tab in the dashboard, tries to provide customers with a generic approach to managing authorization using three top-level concepts:

 - Groups
 - Roles
 - Permissions

### Groups

Groups are collections of users. They are a common way to organize users in enterprise directories like Active Directory. A company might create a group for every department, such as HR, Finance, Accounting, and IT.

Users can be added to one or more groups. But groups can also be nested, with members of one group automatically added as members of another group.

![An example of the "Finance Group"](https://images.ctfassets.net/23aumh6u8s0i/4aLHeBTDYJPNw1d4N0NZp9/2006be77627c5145502aa4e03a190fb8/group)

The main reason for having groups is that it allows us to group people who have the same profile within the company. It is easier to assign roles and permissions to groups than it is to individual people, who can can get sick, go on vacation or leave the company.

### Permissions and Roles

While groups are bound to an organization and not an application, the same is not true for roles and permissions.

If you look at an application that you are building, you’ll notice that users can do many things within your application. Everything your users can do are actions, including opening a record, updating one, deleting one, reporting, and changing settings. A permission determines whether you are allowed to execute an action or not, such as:

- `read:users`
- `run:reports`
- `update:settings`

![Permissions are granual actions that you can execute within an application](https://images.ctfassets.net/23aumh6u8s0i/5AwgqESXywzDYhMjTIE1qc/d86f2afabe3bbf22beaad7b7ed4da0c3/permissions)

These permissions only make sense within the application. A `generate:invoice` permission might make a lot of sense in your accounting application but no sense at all in your planning tool. Therefore, permissions represent actions that you can execute as a user within an application, and roles are there to group these permissions into logical collections.

A timesheet application can have a **Timesheet User** role and a **Timesheet Manager** role. A user will have certain permissions, such as `read:timesheets` `update:timesheets`, and `create:timesheets`, while a manager will have additional permissions, such as `approve:timesheet` and `reject:timesheet`.

![Roles are used to organize your permissions](https://images.ctfassets.net/23aumh6u8s0i/19bQ09h64GAFTBMd118b2Y/ce19dbfb9141a2919632edfbafdd323f/role)

These roles can be assigned to specific users or to groups; if roles are assigned to a group, every user of that group will receive those roles (and permissions).

## Consuming this information in your applications

After setting up everything in the extension, your applications will need to consume this information. The extension offers three ways to do this:

 - Adding information to the **id_token**
 - Adding information to the user’s **app_metadata**
 - Getting the information from a **policy decision point** (PDP)

In the configuration section, you can configure the behavior of the extension. Any change you make here will deploy a rule to your Auth0 account, which will add the information to the token, the app_metadata, or both.

If you’re implementing RBAC, for example, you could just check the box to store the roles in the token. But if you need to understand which permissions a user has in a specific application later, you could make the following call to get the user’s authorization data in the context of an application:

```
POST https://sandrino-dev.us.webtask.io/api/users/ad|john@fabrikam.com/policy/9CDFQBunB9ZvYRCpFWJlzpH9tUwclGIO
```

This will return the groups, roles, and permissions for a user in the context of the current application:

```json
{
  "groups": [
    "Distribution",
    "Accounting"
  ],
  "permissions": [
    "read:own-receipts",
    "update:own-receipts",
    "update:delete-receipts",
    "read:own-reports",
    "update:own-reports",
    "delete:own-reports",
    "submit:own-reports",
    "read:receipts",
    "read:reports",
    "approve:reports",
    "reject:reports"
  ],
  "roles": [
    "Expense User",
    "Expense Manager"
  ]
}
```

## Feedback?

This extension was built using React, Redux, Hapi, and Webtask. When you install it, the entire application will run in the Webtask container of your Auth0 account.

The full source code is available at https://github.com/auth0/auth0-authorization-extension. Feel free to open a GitHub issue if you have any feedback. 

## What lies ahead

Our API authorization feature has been in public preview for some time now, and it will be interesting to use the authorization extension in that context. Depending on your use case, your permissions can be represented as **scopes** in your access token.

Here are some additional resources to get you started:

- [Official documentation](https://auth0.com/docs/extensions/authorization-extension)
- [Automatically provisioning groups, roles, and permissions](https://github.com/auth0-extensions/authz-extension-automation-sample)


Announcing the Auth0 Authorization v2 Extension!

6c0654e56c8c73ffee8f76fe03d18ccf?s=80 avatar

6c0654e56c8c73ffee8f76fe03d18ccf?s=80

Guest Author

Alex Sears

VueJS is coming out with a new version. Learn what's changed by building a simple application.

Create an App in VueJS 2

Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Learn how we deploy new versions of features while avoiding breaking changes through the use of a node.js library for feature changes.



**tl;dr**: We created a [node module](https://github.com/dschenkelman/feature-change) to run two versions of a feature at once (original and new), compare the results, and always return the original results. It is useful in deploying new versions of features without breaking changes.

-------------

At Auth0, we move fast — I mean _really_ fast. Last Friday alone (yes, Friday), we performed  14 deployments to production.

This is something I really like and a positive thing in general, as for example it allows us to do things like [fixing production bugs in short timeframes](https://twitter.com/trydis/status/642809967859380224). Shipping fast is great, but we can't do it recklessly, because stability and availability are core concerns for us. And I'm not just talking about our service, but also about the contracts we commit to in our APIs and SDKS. We never break compatibility, unless there's a security concern involved.

<include src="TweetQuote" quoteText="Shipping fast is great, but we can't do it recklessly. Stability and availability are core concerns for us."/>

To prevent issues, one option is to move slower. Another option is to start relying more on tools and automated tests to make sure that deployments do not introduce any breaking changes.

We settled on a hybrid approach. On the one hand, we host segregated production clusters with different release cadences. One of the clusters gets updated on every change we make, and the other one gets a batch update with a one day delay (approximately). On the other hand, we constantly improve the automated tests that run in our build server before each release, to include additional checks before new versions are deployed to production.

One tool we created is a node module named [feature-change](https://github.com/dschenkelman/feature-change). We got the idea from a blog post by [@holman](https://twitter.com/holman) explaining how GitHub [moves fast & breaks nothing](http://zachholman.com/talk/move-fast-break-nothing/). I think it is best to tell you how it works using a real life example.

# Example: Moving search from MongoDB to ElasticSearch
It all started with a new requirement from one of our customers:

> Is there a way to search for users by field XYZ?

There wasn't, so we went ahead and implemented search against our small MongoDB instance. And all was good.

After that, we had a request from another customer:

> Is there a way to search for users by field ABC?

Then, we had another request, so we decided to allow searching by any field, providing some sensible defaults for the common cases. For a while, this worked perfectly, but as our customer base (fortunately) grew, we realized MongoDB wasn't exactly built for this kind of thing.

For v2 of our API, we had learnt our lesson, so we did not allow searching against MongoDB. Instead, we relied on Elastic Search for this use case, which is working as expected so far.

However, some of our customers are still on v1 of our API. Some of their searches against MongoDB were really slow, affecting the database's stability. So, we decided to exactly replicate the v1 search functionality in ES to reduce the load on our database.

# Introducing feature-change
We know a LOT of our customers rely on search, so we didn't want to introduce any issues with this change. For that purpose, we decided to take advantage of the idempotency property of a search operation to deploy a temporary version to production that did all of the following:

* Perform the search against MongoDB
* Perform the search against ES
* Compare the results and write them to our logs if there was a difference
* Always return the MongoDB result

Using `feature-change`, it looked like this:

```js
var feature_change = require('feature-change');

var current_implementation = mongo_search;
var new_implementation = es_search;

feature_change(function(cb){
    current_implementation(current_opts, cb);
}, function(cb){
    new_implementation(es_opts, cb);
}, function(mongo_result, es_result){
    // invoked when there is a difference in the results (useful for logging)
}, function(err, result){
    // this is the original callback we were using for mongo
    // err and result always come from mongo_search
});
```

We ran this version in production for a couple of weeks and used our logging infrastructure (Kibana/ES) to log the differences. Kibana provides a very useful feature that allows you to create stack charts based on counts of a certain event. In the following chart, the blue part represents the relative percentage of differences compared to successful results. In other words, the blue bars show breaking changes, which we wanted to reduce.

![node module feature-changes](https://images.ctfassets.net/23aumh6u8s0i/5asBdv1p0v3aY26k7h5P2A/1652ea089e8017c2dd32dd0a3edf4c37/parallel-code-paths-1)

After fixing three different bugs we got rid of all the blue. We monitored the differences for a week to see if any new sources of errors appeared. When they didn't, we removed the code using `feature-change` and completely replaced MongoDB with ES in production.

# feature-change is Open Source
We have [open-sourced](https://github.com/dschenkelman/feature-change) `feature-change` so you can use it in your own Node.js applications. Feel free to open issues, send PRs, etc.


Applying GitHub's Parallel Code Paths using Node.js in Auth0

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

b93af62499ed0f76f280acb37913f15d

Hernan Zalazar

A few weeks back we released the first version of our native iOS SDK to help you add authentication to your app. We needed a Keychain library that supported

A few weeks back we released **the first version of our native [iOS SDK](https://github.com/auth0/auth0.ios)** to help you add authentication to your app.

We needed a **Keychain library** that supported the following features:

* **TouchID Support**: An option to make a private keychain value only available if the user entered his fingerprint
* **Accessibility options**: An option to state wether the keychain value could be got if the iPhone is Locked, Unlocked or in which state
* **Shared Group**: We needed Shared Group support so that 2 different apps could share keychain values

As there was no library that fulfilled our needs, **we decided to build [SimpleKeychain](https://github.com/auth0/SimpleKeychain)**.

Let’s see some of the different use cases that we’ve created and used.



## How do I store a value (e.g. JWT Token) in the Keychain?

```objc
NSString *jwt = //user's JWT token obtained after login
[[A0SimpleKeychain keychain] setString:jwt forKey:@"auth0-user-jwt"];
```

```swift
let jwt = //user's JWT token obtained after login
A0SimpleKeychain.keychain().setString(jwt, forKey:"auth0-user-jwt")
```

## How do I share a value (e.g. JWT token) between different apps?

When you have a family of apps that need to share the same user session, you can use iOS Keychain Sharing to store the token. That token must be stored under the same Access Group.

First in one of your apps save the JWT token:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then, you obtain the token in the other app:

```swift
let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup: "ABCDEFG.com.mydomain.mysharegroup")
let jwt = keychain.stringForKey("auth0-user-jwt")
```

## How I can handle the accessibility of the items saved in the keychain?

If you want to restrict when the item can be retrieved (For example only when the iPhone is unlocked, or if you want the entry to be included in any backup) you need to specify the item accessibility before saving:

```objc
A0SimpleKeychain *keychain = [A0SimpleKeychain  keychain];
keychain.defaultAccessibility = A0SimpleKeychainItemAccessibleWhenUnlockedThisDeviceOnly;
NSString *jwt = //user's JWT token obtained after login
[keychain setString:jwt forKey:@"auth0-user-jwt"];
```

## How can I trigger TouchID prompt before accessing the Keychain?

With the release of iOS 8, a new feature was added in order to tie a Keychain item to the user's passcode or their fingerprints .In order to use this feature, you need to store the value with accesibility `A0SimpleKeychainItemAccessibleWhenPasscodeSetThisDeviceOnly` and using iOS 8 Keychain Access Control:

```swift
let keychain = A0SimpleKeychain.keychain()
keychain.defaultAccesiblity = .WhenPasscodeSetThisDeviceOnly
keychain.useAccessControl = true
let jwt = //user's JWT token obtained after login
keychain.setString(jwt, forKey:"auth0-user-jwt")
```

Then whenever you query for that item a prompt will appear and the user will have to enter their fingerprint or passcode:

```swift
let message = NSLocalizedString("Please enter your passcode/fingerprint to login with awesome App!.", comment: "Prompt TouchID message")
let keychain = A0SimpleKeychain.keychain()
let jwt = keychain.stringForKey("auth0-user-jwt", promptMessage:message)
```

This is just a glimpse of all that you can accomplish with [SimpleKeychain](https://github.com/auth0/SimpleKeychain).

Add it to your **Swift or Objective C** project now with CocoaPods and start using it!:


```ruby
pod 'SimpleKeychain', '~> 0.1'
```

"version"