Nelson Matias

As a Group Product Manager at Auth0, I focus on delivering innovative solutions that enhance security and user experience for both businesses and developers. With hands-on experience as a Developer, Consultant, and Solution Architect, along with years of working in Technical Account Management, I’m passionate about solving complex problems and shaping the future of identity management.
Outside of work, I often watch football, listen to music, or spend quality time with my kids.

Group Product Manager

Continuous Session Protection empowers customers to meet a wide range of session and refresh token security needs, including custom lifetimes and revocation capabilities. Let’s dive deeper into how these features can enhance your security strategy.

Continuous Session Protection Now Available for Enterprise Customers

peterfernandez_360

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

Principal Developer Advocate

Peter Fernandez

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

Using a Refresh Token in an iOS Swift App

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.

Andrea Chiarelli

Learn the best practices for securing ID, access, and refresh tokens in your .NET MAUI applications and keeping a consistent user experience.

Managing Tokens in .NET MAUI

Samuel Frank

Sam Frank is Auth0's Sr. Product Manager for new initiatives. He works within the Auth0 Lab to commercialize the team's new ideas so they're available for builders everywhere. As a former platform product manager and startup product lead, he knows the challenges that developers face when creating new apps and he leverages those experiences to focus our teams efforts delivering the next generation of identity tools.

Senior Product Manager

The Customer Identity Cloud platform can now reference NFTs as profile data and as a means to grant access.

The [Auth0 Lab team](http://labs.auth0.com/) has released a pair of [Marketplace integrations](https://auth0.com/marketplace) bringing more [Web3 capabilities](https://marketplace.auth0.com/categories/web3) to the Okta Customer Identity Cloud ecosystem. As the Web3 ecosystem matures, we’re finding that on-chain data, like NFTs (non-fungible tokens), can be used in the identity ecosystem. 

[Our integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) is a simple NFT fetch [Action](https://auth0.com/docs/customize/actions) that retrieves a list of NFTs the user owns. With them, you can make all sorts of IAM-based decisions. If you’re interested in the Auth0 Lab team’s continued Web3 research, come join the conversation on [Twitter](https://twitter.com/Auth0Lab) and [Discord](https://discord.gg/xkbkz9rZcD).

## NFTs in Identity and Access Management (IAM)

By now, you’ve probably heard of NFTs. If not, here [is a helpful explainer](https://www.nytimes.com/interactive/2022/03/18/technology/nft-guide.html). At their core, NFTs are digitally transferable tokens. Tokens have a long history in identity and access management. They are the keystone of authorization in many apps, primarily through the issuance of [JSON web tokens](https://jwt.io/). 

NFTs could be a big extension to token-based IAM. NFTs are flexible, secure, and easily transferable by their nature of using blockchain consensus algorithms to establish ownership and transference. Like with cryptocurrencies, only a specific private key in a wallet can prove ownership. They can help organizations manage capacity problems because you can limit the number of NFTs you mint. This scarcity helps manage supply while still allowing for a robust secondary market. This makes them ideal for ticketed events and venues, like stadiums, trains, and other physically limited spaces.

One of the biggest barriers to mainstream NFT adoption is the usability hurdle of working with blockchains. With our latest integrations, Auth0 Lab seeks to make it easy. Developers can query a user’s NFTs and incorporate them as identity data in their applications, even controlling access based on a user’s ownership of an NFT. We’re excited to see how developers use these new tools when implementing web3 functionality into their applications.

## Token Gating

[Token Gating](https://tokenizedhq.com/token-gating/) is the practice of managing access to resources based on a user’s Web3 NFTs. Notable examples include [‘members only’ communities](https://rarible.com/blog/9-membership-nfts/) of NFT collectors. This exclusivity extends to video games like [Alien Worlds](https://alienworlds.io/), the [largest web3 game](https://www.statista.com/statistics/1266486/blockchain-games-user-number/) at the end of 2022. NFTs are central to the game and unlock certain content, or game locations are only accessible with specific NFTs. [TravelX](https://travelx.io/) is working on another use case around airline tickets.

Token gating is interesting because of the openness of the attestation. Instead of IAM data being stored on a proprietary server, it’s on a public blockchain for anyone to use and see. We’re just witnessing the first experiments in how that data is used. 

## EVM Compatible, Open Source Coming Soon

The current integration works on all [Ethereum virtual machine (EVM) compatible](https://gocrypto.com/en/what-are-evm-compatible-blockchains/) blockchains. This means you’ll have access to NFTs available on some of the largest NFT marketplaces like [OpenSea](https://opensea.io/). You’ll be able to pull from [Ethereum](https://ethereum.org/en/), [Polygon](https://polygon.technology/), [Avalanche](https://www.avax.network/), [Binance Smart Chain](https://www.bnbchain.org/en), and others. EVM blockchains are the oldest programmable blockchains, and the ecosystem is well supported.

The Auth0 Lab team is working on open-source the code so it can be modified and moved to other blockchain platforms. That process takes some time, so keep an eye out by following us on [Twitter](https://twitter.com/Auth0Lab) or heading to our [GitHub organization](https://github.com/auth0-lab) and give it a follow.

## Unlocking NFTs for Your Application

### How it Works

The Auth0 Lab [fetch-nfts integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) works by relying on a few other pieces of infrastructure.

1. It utilizes the [Sign in with Ethereum integration](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) that SpruceID released in the Auth0 Marketplace in 2022. This allows the integration to grab a public blockchain address for the user, which is critical to querying an NFT smart contract to know if they own an NFT. If a user logs in with a method other than Sign in with Ethereum, NFTs won’t be fetched.
2. During [setup and configuration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install), specify a list of NFT contracts that you’d like the [Auth0 Actions](https://auth0.com/actions) code to query. You’ll also need to specify an API key for [The Graph](https://thegraph.com/en/), a service that queries blockchain data.
3. With a public key in hand, and a list of NFT contracts to search, the Actions code calls out to The Graph’s APIs to query the necessary NFT contracts. It returns a list of caip-22 asset references that your Action adds to the [ID token](https://auth0.com/docs/secure/tokens/id-tokens) as claims.
4. From there, you can utilize the data in your application to make any decision, like token gating access, that you feel necessary!

### Installation

Check out our [installation](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install) guide to get started!

## What’s Next?

The Auth0 Lab team is actively exploring the best ways to enable developers to build applications that rely on Web3 identity constructs and help bridge the Web2 and Web3 worlds. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you’re interested in speaking with the team, join our [Discord](https://discord.gg/xkbkz9rZcD) and start a thread.

The [Auth0 Marketplace](https://marketplace.auth0.com/) is looking for Web3 partners to build new extensions onto Auth0. Visit [https://auth0.com/integrate](https://auth0.com/integrate) to learn more.

Web3 NFTs for Identity and Access Control, Now Available on Marketplace

Learn why and how to use refresh tokens in ASP.NET Core applications.

Use Refresh Tokens in ASP.NET Core Apps

Peter-Wheeler-author

Peter leads marketing, community, and customer engagements at Auth0.org. 
With a visceral passion for effective and sustainable Corporate Social Responsibility, Peter develops non-performative programs and engagements for social impact organizations globally. He believes all organizations deserve the opportunity to use technology as a force for good and provide solutions and support to help heroes save the world. Peter prides himself on being a polymath, entrepreneur, innovator, founder, proud failpreneur, strategic marketer, process improver, and sales enabler driving positive impact. Say hi on <a href="https://www.linkedin.com/in/jpeterwheeler/">LinkedIn</a>.



Senior Marketing Manager, Social Impact

Peter Wheeler

Reflections on Product Impact and improving our Self Service process

This entry is a celebration of the launch of our new workflow for Social Impact Organization customers who want our Self Service products.

But the topic I want to cover is a little more universal and a little more important for the team here – providing the best care we can for those who care for others.

**TL;DR:** This being a long post about shortening a process is not a joke lost on me. If you want to experience the new validation process without reading this, visit https://auth0.org/get-started.

## Our Destination Is Product Impact

This past November, I was delighted to make the announcement that we were extending our cost-savings offer for nonprofits and social impact organizations to also include 50% off on Self Service plans.

This was not a small undertaking. We had multiple platforms to access: to verify the organization’s eligibility, adjust their pricing, document, and ensure the account launched properly. 

We, of course, iterated and improved regularly – something that Auth0 is known for. What we also did is take our instantaneous Self Service onboarding process and create a time to live of up to one month, averaging 22 days - something we don’t want to be known for.

## What Was a Beautiful Customer Journey?

We launched with a process that takes up to a month, and with so many steps, we needed to publish a guide explaining how to get the offer. But we launched.

Making sure social impact organizations could get the product discounted is important to us – but we sacrificed speed and simplicity to get our launch. 

It’s easy to excuse. In an enterprise environment, diligence is life. There are features and pricing tiers and stakeholders to involve. Talking to someone - sales, an engineer, support - that’s part of the process. Our customers receive white-glove treatment, and it’s perfectly fine to introduce that to a select group of our Self Service customers.

As a marketer, an entrepreneur, and a customer, it wasn’t OK. A lot of what I love about Auth0 self-service is that it is product led. We have free plans for everyone. It’s totally DIY, and we provide documentation and plugins, and support to keep it that way. I should be able to add authentication to my project while I tinker at 2 am – or whenever I have time, not wait on a multitude of processes.

## Getting Back on the Right Path

Because I wanted to, and because we had so many steps, I have spent my time here personally onboarding every self-service social impact customer that came to Auth0. I have met some amazing people who work for inspiring organizations. We’ve shared and continue to share these stories through case studies and posts about these organizations, like [NCBI](https://auth0.com/blog/social-impact-innovations-national-council-for-the-blind-ireland/) and [Every.org](https://auth0.com/resources/whitepapers/case-study-everydotorg). 

Even though I love it, this method is not sustainable as we grow. So many customers, so few working hours.

Beyond what they’re working on, our very patient and very open social impact customers clued me into their frustrations with our onboarding and other elements of the process that made their experience different and less than the process for-profit customers enjoy.

## A New Companion for the Journey

To make sure we’re giving the cost savings to organizations that fall within our eligibility criteria, that don’t take part in hate speech, that is who they say there are - we rely on third-party agencies. These agencies are known as “validators.” When I entered this space, I learned validation platforms operate reactively - meaning a nonprofit or charity can already be a member or indexed by the system - making approval easy, and if they weren’t already in the system, applying would initiate a process to get them verified and validated. This takes time, and even in the case of “easy, already in the system,” validation was still a manual process for us, the customer, and the verification organization. 

I started exploring the corporate social impact ecosystem, and another companion on our journey, Mitch Stein ([CEO of pond](https://www.joinpond.com/), a great marketplace, and a different upcoming post), let me know of a set of entrepreneurs pivoting their social impact app into a validations-and-beyond company, [Percent](https://poweredbypercent.com/).

I met with team Percent, and their platform used a proactively filled database - pre-validating organizations at a rapid pace to eradicate future wait time. They were also able to check a box that I thought couldn’t be - they were able to add automation to the process to get customers to the “next steps” while keeping it all Auth0 - eliminating the need for a separate guide.

Less than one month of integration, building, and testing later (thank you, Flor and the ever-so-patient Auth0 Marketing Engineering Team) - we’re live!

## Welcome to Our Emerald City

So here we are. We are launching again. An updated version and an updated process. A better customer experience for the nonprofit organizations we cherish.

If you’re a nonprofit that is listed with [TechSoup](https://app.ngok.techsoup.org/Default.aspx?vendorAppId=07ae4c97-f7a0-4c2e-bd1a-9480e0d971bd) - feel free to continue to validate [here](https://app.ngok.techsoup.org/Default.aspx?vendorAppId=07ae4c97-f7a0-4c2e-bd1a-9480e0d971bd). 

If you’re one of the nonprofit organizations that may not be with TechSoup, visit [https://auth0.org/get-started](https://auth0.org/get-started) and enjoy our new validation system powered by [Percent](https://wearepercent.com/).

If you read this far, that’s where we’re at on our product impact journey as we continue to explore and improve our customer journey. Thank you for following along, and never hesitate to reach out.

Peter

Product Impact Update - Rapid Self Service TTL

Majid Hajian

I am a Google Developer Expert and Media Developer Expert and a passionate software developer with years of developing and architecting complex web and mobile applications. my passions are Flutter, PWA, and performance. I love sharing my knowledge with the community by writing and speaking, contributing to open source, and organizing meetups and events.

Google Developer Expert

In this tutorial, you’ll learn how to enhance your Flutter apps by enabling authentication, supporting federated identity providers, adding authorization by introducing roles and permissions, all leveraging Auth0.

In the exercise from the previous section, you added Auth0 authentication to an existing Flutter app. This added a username/password authentication flow to the app. You also gave the app the ability to request and submit refresh tokens, which enhance the user experience by not requiring the user to authenticate every time they use the app.

This section will expand on the app by examining some useful Auth0 features:

* Refresh token rotation
* Social logins
* Managing your Auth0 account

> **Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.**


## Add Refresh Token Rotation

When the app makes an authentication request to Auth0’s authentication server, it includes the `offline_access` scope. This causes the authentication server to issue a refresh token, which the app can use to re-authenticate without requiring the user to log in again. The app stores this token in the device’s secure storage.

While this enhances the app’s user experience, it also introduces risk. The refresh token is long-lived, and the app could use it as a “lifetime pass” to endlessly request new access tokens and keep the user logged in forever.

I highly recommend taking advantage of *Refresh Token Rotation* and *Automatic Reuse Detection* to help mitigate this risk. With these features enabled, each refresh token can be used only once. When the app exchanges its refresh token for a new access token, the authentication server also returns a new refresh token and invalidates the old one. 

Let’s enable these features!

🛠 Navigate to the **Applications** section of your Auth0 dashboard, select the **MJ Coffee** application, and then select its **Settings** tab. Scroll down the page to the **Refresh Token Rotation** section and turn on the **Rotation** and **Absolute Expiration** options:

![Turn on the “Rotation” and “Absolute Expiration” options.](https://images.ctfassets.net/23aumh6u8s0i/6EizPZZnkGjxoAOle1Q8eL/e06c99f4a49413572736bbf0f470436c/rotation_and_absolute_expiration.png)

It is recommended that you issue a refresh token that expires after a preset lifetime. The refresh token’s lifetime can be extended each time one is used to get a new access token or access token/refresh token pair.

There are two options for token lifetimes, and they can be set independently of each other:

- **Absolute Lifetime:** Enabling **Absolute Expiration** sets a specified *absolute lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens during this lifetime. Once the token’s age goes past its lifetime, the user will need to re-authenticate in order to get a new access token. If **Absolute Expiration** is disabled, the refresh token has an indefinite absolute lifetime.
- **Inactivity Lifetime:** Enabling **Inactivity Expiration** specified *inactivity lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens if the user is active in the application during this lifetime. If the user is inactive in the application for a period longer than the inactivity lifetime, they will need to re-authenticate in order to get a new access token.

🛠 Scroll to the bottom of the page and click the **Save Changes** button:

![The “Save Changes” button. The user is directed to click it.](https://images.ctfassets.net/23aumh6u8s0i/7KsLW4adJ6PNIPAI12al4g/f2c0e8abf6d7377595cfb7df11493e67/save_changes.png)


## Social Logins

These days, it's pretty common to have login methods beyond the standard username/password combination. These include logging in with social media account, which will significantly enhance your users’ experiences.

Implementing these additional login methods and adding them to your authorization server is time-consuming and will come with many considerations and risks. 

Luckily, Auth0 provides lots of integration with well-known third parties’ authentication systems, and even allows you to write your custom connections. Let's add connections to both Google’s and Apple’s authentication systems.


### Create a Google/Gmail social connection

🛠 In the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/61w1eXrbY7bGOpNo6ODbaU/da810c63bacd28cabf71e6dee4baa349/create_social_connection.png)

You will be taken to the **New Social Connection** page, which has a list of social login providers that integrate with Auth0. 

🛠 Select **Google**:

![Selecting Google from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/2YdUxIkwmCTcc9QFlo584q/22f7fd0bf4bc1c93c4ebc555e21009f8/select_google.png)

You will now be on the  **New Google / Gmail Social Connection** page, which tells you what kind of user information is accessed by Google social login.

🛠 Click **Continue**:

![Initial page for creating a new Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/2SQwtF0vqtXJucnGbE3DNS/baf5bd9d7103a6ecbd59b879bbe2aaf4/click_continue.png)

A new page with a number of fields will appear; this is the connection’s **Settings** tab. 

As long as you’re working in a development environment, you only need to fill the **Name** field (which provides a name for this connection) and leave all the other fields empty. You can always use the default value in the **Name** field:

![New Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/7Jzsn4ryILOOdACN2urlSo/fdaa205ef09352c0b9aba0acbd592977/new_google_gmail_social_connection.png)

However, production apps require you to provide a **Client ID** and **Client Secret** ([doc](https://auth0.com/docs/connections/social/google)) and specify the **Allowed Mobile Client IDs**. These topics will be covered in another video or article.

🛠 Create the Google/Gmail connection by scrolling to the bottom of the page and clicking **Create**:

![Creating the Google/Gmail connection](https://images.ctfassets.net/23aumh6u8s0i/4S8AJUaj4xehVwVxhNDt5X/69eb88b8bec557d310d0e9d678fe9b7e/click_create.png)

This will create the connection, and you’ll be taken to its **Applications** tab. You’ll see a list of your applications, which will allow you to enable the Google/Gmail connection for any of them. Enable the connection for the *MJ Coffee* application:

![The Google/OAuth2 applications tab](https://images.ctfassets.net/23aumh6u8s0i/681u1RRcha4ABJJ5GRZivy/c7eea90ca4e19ec5ab3b333caa47e5ba/google-oauth2_applications_tab.png)

You may also set more permissions that the end-user will need to approve during authorization. These permissions depend on your application and what you want to do on behalf of the user. The *MJ Coffee* app doesn’t need any extra permissions beyond the basic and extended profile.

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/13CvLX8tQUTuqU6jpZ6K94/a0eaac13b8fc83fc11b3ca3f6651ebd9/google_permissions.png)

🛠 Make sure you sync user profile attributes at each login and hit the **Save** button.


### Create an Apple ID social connection

🛠 Once again in the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/1sohaZxDHuq8X8ZvT5nhvE/d2b7a7e2647708327f8fc6971ddb43a9/create_connection.png)

🛠 This time, select **Apple**:

![Selecting Apple from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/3JAgbtDSNOsfYrjxkE1wCI/e51d80f7418706c29cd6e9dc06b93719/select_apple.png)

You will now be on the  **New Apple Social Connection** page, which tells you what kind of user information is accessed by Apple social login.

🛠 Click **Continue**:

![Continue](https://images.ctfassets.net/23aumh6u8s0i/3zt2ntLwoHwp6bldLmOOsD/8db3e7f5c057d5782c7202b748013420/click_connect_-_apple.png)

As long as you’re working in a development environment, you can leave the **Client ID** and **Client Secret Signing Key** fields empty. You *will* need proper keys for those fields when the app goes to production; [this document covers that topic in more detail](https://auth0.com/docs/connections/apple-siwa/set-up-apple).

The **Apple Team ID** and **Key ID** values are required:

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/2qNvT5zkxB1TY06ywkH5Re/7c46fa1399743de9e7bb05d1d804fab0/apple_dev.png)

* To get your Apple Team ID, you need an Apple Developer Account.
* To get a Key ID for your app, you need to register that app using your Apple Developer Account. 

🛠 Sign in to your Apple Developer Account, and go to the **Membership** page and make a note of your Team ID.

🛠 If you have a registered app, you can skip the following steps and jump to the list of tasks for creating a service ID. Otherwise, follow the steps below:

- In the Apple Developer Portal, go to **Certificates, IDs, & Profiles > Identifiers** and click the blue “plus” icon next to **Identifiers** to create a new App ID.
- Choose **App IDs** as the identifier type and click **Continue**.
- Provide a description and a Bundle ID in reverse-domain name format (e.g.: `com.mydomain.mjcoffee`).
- Scroll down and check **Sign In with Apple**.
- Click **Continue**, and then click **Register**.

🛠 Once the app is registered, it’s time to create a service ID:

- Return to the **Certificates, IDs, & Profiles** section, and click the blue “plus” icon next to **Identifiers**.
- Choose **Service IDs** and select **Continue**. Fill in the description and identifier (e.g.: `com.mydomain.mjcoffee`).
- After checking **Sign In with Apple**, select **Configure**, and define your Web Domain (e.g.: `com.mydomain.mjcoffee`) and your "Return URL". Ensure that your Return URL is your Auth0 domain and that it follows this format: `https://YOUR_AUTH0_DOMAIN/login/callback`.

![Return URL apple sign in](https://images.ctfassets.net/23aumh6u8s0i/5Wetff0Tutv55UXsYz0gKq/ab19cd3e48604aea314410d22d194982/callback_apple.png)

🛠 Finally: save, continue and then register the service.


#### Set up your Client Secret Signing Key

🛠 Follow these steps:

- Go to **Keys**, which is located in the **Certificates, Identifiers, & Profiles** section of your Apple developer dashboard.
- Select the blue “plus” icon to add a new key.
- Enter a **Key Name** and check the **Sign In with Apple** option.
- Select **Configure** to make sure the **Choose a Primary App ID** field is filled with the correct App ID.
- Select **Save, Continue**, and then **Register**.
- On the page to which you're redirected after registering, make a note of the Key ID. Then download the key; it will have a `.p8` filename extension.

🛠 Go back to your Apple social connection settings and paste the Key ID. Ensure the proper attributes are selected (Name, Email) and sync user profile at each login is enabled. Hit **Save**.


## Enable Social Connections

🛠 Once you have created all your social connections and set them up correctly, go back to your applications. Go to the **Connections** tab and enable your newly-made social connections:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/59SCRbiX055qDcmTSNwPVl/fa175f974ceb43515893f24f7747d549/app_social_connections.png)

As you can see, adding and removing social connections for your apps is now as simple and flicking a switch.

On the Flutter side, I have good news: you don’t need to implement anything there! 

Restart the app, log out, then try to log in. You’ll see this:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/4b6BIaeZ8EHcN1a3MYVOrF/91c9039cf0d56051c99397d1a7524a3e/social_buttons_flutter.png)

That's it! The login screen will now display social login buttons, and their login flows will be ready to use.


## Branding 

While it’s fine to use the default branding in development, you want the login page to be customized to your “look and feel” once the app’s in production.

Auth0 allows you to customize your login page through a number of options. You can change the look and feel of the login page by adding colors and logos, and you can customize the user notification part of the process as well: email templates, text messages, and so on. It’s all in the **Branding** section of the Auth0 dashboard:

![Auth0 branding](https://images.ctfassets.net/23aumh6u8s0i/7oq6VzFQ3nSUcStZTXvjQu/38d1e272f3bef751d9feaca704d580dc/branding.png)


### Add Roles

You may want to provide certain functionalities to the user based on their roles. This is easy with proper authorization server such as Auth0, which facilitates adding roles and specifying what users in each role are allowed to do. 

In the MJ Coffee app, there are three different roles:

- **Admin:** These are administrators, and they will have access to all the app’s functionality with full permissions.
- **Customer:** This is the default role for registered or logged-in users. They are limited to the app’s customer-facing features. You will automatically assign this role to all users upon registration or login, and you will learn how to do so later on in this tutorial.
- **Employee:** These are coffee shop employees. They can access the community screen to answer customer requests in the support chat, as well as other employee-facing features.

![Auth0 roles](https://images.ctfassets.net/23aumh6u8s0i/7nVdiU86TPCF1tLXrBg6ID/54a078bfe7d2382a6776c26adfc5cba4/roles.png)

You can add more roles to the app as the need arises.


## User Management in Auth0

Auth0 provides the infrastructure to store users and their information on its cloud database.

For the *MJ Coffee* app, Auth0’s cloud database is sufficient. One of Auth0’s goals is to reduce the cost of extra infrastructure maintenance and cost.

You can access users by selecting **User Management** in the left column menu of the Auth0 dashboard. The **Users** page allows you to create new users and manage your existing ones by changing their details, adding permissions and roles, or revoking their access.

![Auth0 users](https://images.ctfassets.net/23aumh6u8s0i/3O0JDGBqXHmPfrKaEavP2D/260c804cf50a308e696ecd9a446ab4a9/users.png)

When you open a user, you’ll see that Auth0 provides in-depth details about that user, including basic account data, metadata, their devices, and their history, which might be pretty helpful for debugging the application or investigating a particular user’s access activity, permissions, and roles.

![Auth0 user roles](https://images.ctfassets.net/23aumh6u8s0i/JcGTMspZ9hKtu9RAi4Oq9/257a692aa9a65cd12e96f645b56aafd1/user_roles.png)

Each user account stores some basic information about the user: name, email address, the date and time when the account was created, and so on. 

Additional information can be attached to a user by adding to these metadata stores:  their user metadata, which is a key-value structure for storing information about the user. You can also store information in the user_metadata or manipulating `app_metadata`, which helps to provide more information to the Flutter application while receiving user details.


## Moving Forward

In the next section of this tutorial, you will learn how to add real-time chat to the app.


Flutter Authentication and Authorization with Auth0, Part 2: Refresh Tokens, Social Logins, and More

Chitra Dharmarajan

A motivated CyberSecurity professional with a specialization in IIOT, Cloud Application & Infrastructure Security, Web Application Security, Product Security, and Solutions Architecture. An innovative technical leader, who has efficiently managed cross-geographical teams to successfully deliver Secure Development Lifecycle, Incident Management, Penetration Testing, Product Development & Release Management initiatives. Excels in translating strategic objectives into actionable plans and solving complex problems while delivering high-quality business results. 

Senior Director, Product Security

A quick look at the refreshed OWASP Top 10 to celebrate Cybersecurity Awareness Month

A Tour Through the OWASP Top 10

37590801?s=460&v=4

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

Software Engineer

Dan Arias

Sam4-square

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

Sam Bellen

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

What Are Refresh Tokens and How to Use Them Securely

T025590N6-UA74EV4TB-edf9e73df2fc-512 avatar

T025590N6-UA74EV4TB-edf9e73df2fc-512

I’m a product designer based in Portland, OR. I specialize in breaking down big messy problems and coming up with elegant solutions.

Product Designer

Stacy Taylor

Read how we’re updating our language to be more inclusive.

Words matter. The words and phrases we use reflect our values and attitudes towards those around us. As language is constantly evolving, words and phrases that were commonplace in the past may strike us as deeply offensive today. It’s important that we reflect on the terms we use and consider how they may be harming others or how and how they might be perceived in the future. 

After injustices in our society were so glaringly emphasized in the summer of 2020, several tech companies, including [Github](https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/), [Google](https://9to5google.com/2020/06/12/google-android-chrome-blacklist-blocklist-more-inclusive/), [Twitter](https://twitter.com/negroprogrammer/status/1278728952522043393), and [Intercom](https://www.intercom.com/blog/updating-our-terminology/), began removing terms with racist roots, like “master,” “slave,” “whitelist,” and “blacklist.” 

At Auth0, we wanted to go further and re-examine our use of other, more nuanced terms, such as gendered and patriarchal, as well as ableist, ageist, and violent language.

We began this investigation in 2019, and over the past several months, teams across Auth0 have been working to remove problematic terminology from our codebase, documentation, and internal and external communications. 

### We Give a Shit

Critics of these efforts are quick to claim that this shift is just one more example of virtue signaling or political correctness run amok. But while we understand these small changes are not going to solve systemic racism, that doesn’t mean the effort is wasted. Everyone deserves a seat at the table in the technology world, and inclusive language is one small step towards making that a reality.

### Putting a Plan in Place

Our first step was to identify the terms we wanted to replace—there were obvious ones, like “whitelist,” “blacklist,” “master,” “slave,” “white hat,” and “black hat.” But we also wanted to address ableist terms, like “dummy value,” “crazy,” and “sanity check,” as well as gendered terms, like “man-in-the-middle attack” and “man hours.”

We began by creating an #inclusive-language Slack channel to discuss and debate different words and suggested alternatives. Based on those conversations combined with an analysis of other companies’ changes, we arrived at an initial list of terms and replacements. We replaced master and slave with main and secondary, whitelist and blacklist became allowlist and denylist, and white hat and black hat hackers are now ethical and malicious hackers. Grandfathered became a legacy, and brown-bag lunches are now called lunch and learns. We replaced man hours with person-hours and man-in-the-middle attacks with bucket brigade attacks. Sanity check and dummy value were replaced by the less ableist terms confidence check and placeholder value. 

### One Team, One Score

Next, we put together an inventory of all places where those terms were being used in our product, marketing, and other communications. After that, we identified and contacted the primary stakeholder for each area, such as the head of documentation, marketing team, individual product managers, and engineering leads.

Despite having their own roadmaps and quarterly commitments to worry about, everyone was incredibly receptive and eager to tackle this project. We provided the inventory and the timeline, but it was up to each individual team to make the changes. Most teams were able to fit the work into upcoming sprints, and we tracked all of the tickets on a centralized page to keep everybody accountable.

### Keeping the Momentum Going

While the initial push to remove specific terms from our product and communications was a good start, we also wanted to empower individuals to keep moving forward. To do so, we put together a set of principles and guidelines:

#### Impact matters more than intent

If a term perpetuates harm, it should be replaced regardless of the intent behind it.

While it is useful to consider the etymology of a term to determine whether it has biased roots, it’s important to remember that language is constantly evolving, and dictionary definitions are not how people use language in real life. Just because a term’s roots aren’t explicitly racist doesn’t mean the term itself doesn’t cause harm.

#### Use direct language

Writing should be clear and concise.

Avoiding idioms and metaphors removes value judgments, eliminates obfuscation, reduces the chance of accidentally using a term with problematic roots, makes localization easier, and improves readability.

#### Be the change you wish to see

We have the opportunity and responsibility to lead change in our industry.

We believe that inclusive language can show how we are inclusive for all users. We encourage other companies to follow our lead.


Auth0’s principles, guidelines, replacement terms, and additional resources are available to all employees. The `#inclusive-language` Slack channel continues to be a safe space for employees to engage in dialogue about biased language. These resources are also being added to our onboarding program so that new employees understand our commitment to inclusive language right from the start.  

### N + 1 > N

At Auth0, we believe that consistent, iterative improvement leads to incredible results. We recognize that addressing our use of biased language is an ongoing process rather than a one-and-done effort. With our guidelines and principles in place, all employees are empowered to address biased language as they find it. We all have an obligation to be intentional with our language and consider how all words we use have the potential to reflect our values and beliefs.

<include src="asides/AboutAuth0" />

Our Language Reflects Our Values

eugenio-pace-new-avatar

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

CEO and Co-Founder

Eugenio Pace

Auth0’s CEO on renewal and being prepared to take on a new year



_A gem cannot be polished without friction, nor a man perfected without trials._ - Seneca

There is no denying that 2020 presented a seemingly endless barrage of challenges that were fraught with frustration, stress, and hardship for so many. While adapting to the “new normal” (definitely one of the most widely-used phrases of the year), many of us at Auth0 were flanked by homeschooling kids, caring for family members, and/or just trying to adhere to the rigors of quarantined life. And very sadly, some faced untimely and terrible losses. 
 
This constant friction, while incredibly stressful, presented us with many opportunities to learn and grow. No one was fully prepared for what 2020 threw at us, but the obstacles we had to overcome made us stronger as individuals, managers, and as a company. Our society also learned, arguably the hard way, about new possibilities and new opportunities.
 
I am so proud of how we adapted and supported each other, how we supported our customers through their own struggles and ambitions, whether they were ready or not, and our dedication to making a larger, longer-term impact. I have tremendous hope for the year ahead and beyond and would be remiss in not recognizing key milestones from 2020, which are instrumental in how we approach this new year. 
 
### Auth0 Grew in Many Ways

Despite the economic climate of 2020, we are very grateful for our continued growth, which really underscores identity management as a critical technology for digital transformation initiatives. We anticipate these transformation efforts will continue to accelerate in 2021, and thanks to the support of our investors with a [$120M round of funding](https://auth0.com/blog/auth0-announces-120m-seriesf-funding/), we are even more poised to support all current and future customers around the world. 
 
Of course, this growth would not have been possible without the tireless work of the entire 800+ person Auth0 team, 213 of whom joined us in 2020. It is the dedication and commitment to excellence of every single employee that will help propel the company even further this year.  
 
In 2021, we will continue to focus on growing our business in existing markets and expanding our presence in new markets. We will continue to be a resource for millions of developers worldwide who have supported us throughout the years, welcome all new developers, and educate the industry on how our identity management solution is different and ready for tomorrow’s requirements.
 
### Auth0 Supported its Team

Speaking of employees, our “**One Team. One Score**” and “**Give a Shit**” company values could not have been more apparent than in 2020. We were lucky to have been 60% remote prior to the pandemic, which made it much easier to transition to a fully 100% remote workforce. Beyond that, we supported each other in ways that make me proud to be CEO&mdash;whether simply covering for each other, offering more flexible working schedules, or designating the U.S. Thanksgiving week as a company holiday for rest and recovery. 
 
We rose to the challenge and acted as one team. We supported our leaders and employees through the stresses of balancing work and caregiving, and in place of the annual in-person offsite (a heralded Auth0 tradition), our incredible People team organized and managed a two-week long virtual extravaganza of collaboration, learning, external speakers, and fun experiences for the entire company. 
 
In 2021, we will continue to invest in every team member. We will give all employees the resources, flexibility, tools, and support needed to be successful at Auth0, so we can collectively serve our customers in the best ways possible. 
 
### Auth0 Supported its Customers

Auth0’s customers cover the globe and are representative of every industry, all reliant on Auth0 to improve the security and seamlessness of logging into their services. We sit at the front door to millions of consumer experiences every day and are grateful to be part of their digital journeys. A customer like [BioReference Laboratories](https://auth0.com/case-studies/bioreference/), in particular, used Auth0 to scale to accommodate a 25x increase of users who needed a secure and easy way to monitor their COVID-19 test results. This is significant for obvious reasons. This example, along with [customer success stories](https://auth0.com/customers/) from Jersey Mike’s, Siemens, Signify, Babylon Health, Toast, Blackboard, Dunelm, and THE ICONIC, is just a sampling of how diverse and far-reaching identity management is and the impact it makes in everyday life. 
 
We were also very excited to launch [Auth0 Marketplace](https://marketplace.auth0.com/) in 2020, a trusted partner integrations catalog that enables customers to extend our platform for multiple identity and access management needs. Auth0 Marketplace will be an integral hub for customers as their identity needs become more complex. 
 
In 2021, we will continue to work on being a highly trusted partner to our customers. We will welcome new customers of all sizes, from all industries. We will listen to our customers’ needs, continue to improve our platform functionality, be a valuable technology expert, and help provide our customers’ end-users with a secure and seamless digital experience. 
 
### Auth0 Gave Back

We have always prioritized giving back as a primary pillar of Auth0 but took it to another level in 2020 with the launch of [Auth0.org](https://auth0.com/social-impact), a social impact program committed to secure, inclusive access for all. We helped fund Auth0.org by joining the [Pledge 1%](https://pledge1percent.org/) initiative and committing to contribute 1% of the company’s equity over the next 10 years to help pursue philanthropic initiatives. Balancing [profit and purpose](https://www.forbes.com/sites/forbestechcouncil/people/eugeniopace/?sh=4fdad9284ef1) is something that I am especially passionate about. [Auth0 for Startups](https://auth0.com/startups) and [Tech for Black Founders](https://www.notion.so/TechforBlackFounders-ced8852e37514bcaac6a82bec9dc8087#56971fa0ea894a29bc47f67c6ec69fcf) are other programs we launched to pay it forward and use technology for good. 
 
In 2021, we will go deeper with Auth0.org and identify organizations that we want to partner with. We will continue to volunteer our time, resources and commit to being a force for positive change. 
 
### Auth0 Looks Ahead

While 2020 has officially ended, tomorrow we will wake up in the same world and encounter seemingly the same challenges. There will be no “back to normal” because “normal” evolves continuously, even without a global pandemic. 
 
But tomorrow, we will also wake up with the same super-power endowed to us. The super-power to adapt, learn, build, create, and improve everything around us. The super-power to turn ideas and thoughts that only exist in our imagination into action and reality. The power to change ourselves and our lenses on the world around us. We have the privilege of being front-row witnesses of this super-power in action every day as we build Auth0.
 
We have lofty goals for another successful year of high growth and will continue to focus on investing in our team, technology, operations, customer base, and global reach. (Stay tuned for more details on new office openings...) I have the highest level of confidence in my leadership team and staff and will continue to rely greatly on the counsel of Auth0’s amazing Board of Directors, into which we recently [welcomed three SaaS superstars](https://auth0.com/blog/auth0-adds-three-key-saas-leaders-to-its-board-of-directors/): Sue Barsamian, Sameer Dholakia, and Simon Parmett. 
 
For these opportunities, and for a promise of a new year that we can create for ourselves, I am grateful and renewed with the will to continue this journey, however challenging it might be. 
 
2020 presented us with relentless friction and was a year we had to work even harder for every milestone and achievement. But it is from these challenges that our greatest gems emerged, and I am looking forward to a brilliant year ahead.


A Reflection on Auth0’s 2020 and Hope for a Brilliant 2021

randy_nasson

Director of Product Management for Customer Identity Cloud (formerly Auth0) in our Identity and Access Management (IAM) domain. I joined Auth0 in 2018 and assembled a world-class IAM product team dedicated to delivering customer value and enabling developers to quickly implement secure, robust, and seamless identity solutions. In addition to my current work with CIC, I regularly work with our Auth0 Lab team on greenfield initiatives and with our Strategic and Technical Partner teams on opportunities to drive revenue.

Director, Product Management (IAM)

Randy Nasson

Delight users while providing a secure CIAM solution for accessing applications and services



## Summary

* Refresh tokens [can be effectively used for maintaining a seamless user experience](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) in browser-based apps without suffering the limitations imposed by ITP2
* Configuring absolute lifetimes for refresh tokens helps reduce the risk of using RTs in single-page applications
* Inactivity lifetime enables refresh token lifetimes to be extended as long as the end-user interacts with the client within the configured period, resulting in less end-user friction
* **Auth0 now provides both absolute and inactivity lifetimes for refresh tokens, along with more secure refresh token defaults, as of December 16, 2020**
<br /><br />

## Balancing Security and User Experience

Most businesses want to afford a friction-free experience for end-users when using their applications. Requiring people to manually enter credentials every time they visit a commerce site or open an app can yield frustration and hurt the business bottom line. A common request in business-to-consumer (B2C) industries is to only require users to log in once and then to never require them to log in again unless they are explicitly logged out, either by choice or necessity.

The practice of using long-lived [refresh tokens](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) paired with short-lived Access Tokens is a common solution to delivering an uninterrupted experience, particularly in native mobile apps. With additional security capabilities such as [Refresh Token Rotation](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) and [Automatic Reuse Detection](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/#Automatic-Reuse-Detection), refresh tokens can safely be used in Single Page Applications (SPAs) to afford continuous access on the web.

![Refresh Token](https://images.ctfassets.net/23aumh6u8s0i/6lBzS4ElN5ZEULvNM50Hvi/1a84f912b03d26661286ec71b4016f71/01-image-refresh-token)

## Refresh Token Expiration

However, a refresh token is considered a powerful artifact in identity management. If a refresh token is leaked or stolen, it could be used to acquire a new Access Token. As such, the [OAuth 2.0 Best Current Practices (BCP)](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.12.2) states that refresh tokens **should** expire if the application (client) is inactive for too long, particularly when used in Public Clients (a client that cannot secure its own credentials, such as a native mobile app). This means that refresh tokens should expire at some point in time, but that expiration can be based on activity and not merely an arbitrary point in the future.

When the refresh token expires, it can no longer be used to get a new Access Token. The user will be required to re-authenticate the next time they use the application. More importantly, an attacker’s window for using a leaked token is limited. 

But, what about the business desire for only wanting the end-user to log in once and not again thereafter? For SPAs, this can still be afforded within the OAuth 2.0 BCP guidance provided that the end-user’s activity in the application remains consistent.

Let’s consider an example: A media company publishes content on a regular basis that is only available to authenticated subscribers. In addition, the company sells subscriptions and related goods (books, print media, access to premium video content, etc.) using stored payment methods associated with the account. 

In this scenario, the website is a SPA with Auth0 as the authorization server, and refresh tokens are used to overcome the session limitations incurred by ITP2 or similar privacy mechanisms. Because there is sensitive information in the account, maintaining an indefinite application session is not ideal.

Leveraging absolute lifetimes, end-users can be required to log in again after a predetermined period of time. But that experience is not optimal for the business or the end-user. Requiring re-authentication creates friction between the user and the content or purchases. What if the user could remain logged in as long as they were active in the application on a regular basis, for example, once every two weeks?

## Introducing Inactivity Lifetime

Unlike absolute lifetime, which expires a refresh token after a fixed period, inactivity lifetime extends the expiration period each time the client uses a refresh token to get a new access token. Using the example above, this effectively preserves the seamless user experience as long as there is an activity within the inactivity lifetime.

![Introducing Inactivity Lifetime](https://images.ctfassets.net/23aumh6u8s0i/6vutURQweArCulYsO5eBvL/f54e0ef9f358058bde3b185c474ab814/04-at-expiration-1-day-flow)

As of today, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. This enables you to configure refresh token lifetimes based on your own app usage data, for example, by evaluating your application log data to determine how often users return to your app so that people who use applications regularly can have that period extended as long as usage remains consistent. 

Auth0 makes it easy to configure refresh token lifetimes using the [Auth0 Management API](https://auth0.com/docs/api/management/v2#!/Clients/post_clients), our [Deploy CLI](https://auth0.com/docs/extensions/deploy-cli-tool), or the Auth0 Dashboard.

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/4P5VvuP2z41wvUoBDlRzvH/840a1ebbbf639eb0827ad62b4ab645c2/05-refresh-token-expiration)

Inactivity lifetime can be used in all supported refresh token flows and in conjunction with Refresh Token Rotation.

## Using Inactivity and Absolute Lifetimes Together

Both inactivity and absolute lifetimes can be configured on a per-application basis, enabling you to craft experiences to suit the expected usage of your applications.

Setting absolute lifetimes for refresh tokens ensures that refresh tokens cannot be used to retrieve a new access token after the specified period. For example, if you set the absolute lifetime to 30 days, the refresh token issued to the application can be used for up to 30 days from its issuance to retrieve a new access token. If you are leveraging Refresh Token Rotation, the absolute lifetime [applies to the entire token family](https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation#automatic-reuse-detection). After the lifetime expires, the user will be required to re-authenticate.

You can also use a combination of absolute and inactivity lifetimes to afford an uninterrupted user experience for much longer durations, provided that the user remains active within the inactivity lifetime. For example, you can set the absolute lifetime to 365 days and the inactivity lifetime to 14 days. This would allow a user who was active in your application at least once every two weeks to continuously stay logged in until the absolute lifetime expires.

You can also use an inactivity lifetime _without_ an absolute lifetime in a similar manner to achieve the effect of never having to log in again as long as the user remains active within the inactivity lifetime (and the user never explicitly logs out).

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/1og3ppkzZWZlMEXh1NNqLM/c2f2998f7509d6568fd87ca40622fdcf/06-refresh-token-expiration-2)

## Guidance & Defaults

As part of Auth0’s continued commitment to securing applications and protected resources, we’ve updated default refresh token settings for new applications as follows.

### Confidential Clients

Confidential clients, such as machine-to-machine applications or traditional web applications that can securely store client credentials and can, therefore, prove that requests are coming from the client and not an illegitimate actor. As such, when refresh tokens are enabled, for confidential clients, default settings are optimized for convenience as follows: 

![Confidential Clients](https://images.ctfassets.net/23aumh6u8s0i/3ZABGcvqKpo7NIanSD1v4e/c83ca317f6483ccae212a9ac2db827fb/07-confidential-clients)

### Public Clients (Native Apps)

Because Public Clients, such as native mobile applications, cannot securely store client credentials and are susceptible to other attack vectors when refresh tokens are enabled for public clients, the default settings are optimized for security, as follows: 

![Public Clients](https://images.ctfassets.net/23aumh6u8s0i/5sUFHqXRJ1OQZnb4MvMOMu/62b5e02b574bbe4c1b74cfee434d628e/08-public-clients)

### SPAs

Until recently, refresh tokens were not recommended for use with SPAs because browsers are more vulnerable to token leakage than native applications. Leveraging Refresh Token Rotation, the risk of using refresh tokens in SPAs is lowered. Nevertheless, Auth0 recommends that SPAs use refresh tokens with Absolute lifetimes specified and sets the following defaults when refresh tokens are enabled for SPAs:

![SPAs](https://images.ctfassets.net/23aumh6u8s0i/1S9d6u2w8dgSZ4D3cEpwIa/b0d00b921376cf6ec28bb86ac5f95145/09-spas)

## Let’s Get Started

As of December 16, 2020, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. You can read more about refresh token expiration, absolute lifetimes, and inactivity lifetimes and how to configure them for use in your applications in the [Auth0 documentation](https://auth0.com/docs/tokens/refresh-tokens/configure-refresh-token-expiration). We hope that you find this new capability helpful for balancing user experience with added security.

Secure the applications that you care about. But do it in a way that delights the people who use them.


Achieving a Seamless User Experience with Refresh Token Inactivity Lifetimes

vincenzo-chianese

Vincenzo Chianese is an Italian Software Developer focused on Web APIs and User Interfaces. He has been working for the last years in API companies such as Apiary, Oracle, LunchBadger, Stoplight. Currently, he is working for Microsoft to help move Microsoft Graph forward and authored some open-source tools in the market (Prism, Express Gateway).

API Architect

Vincenzo Chianese

Learn how to refactor a complex TypeScript function by breaking it into a composition of simpler ones.

Refactoring by Breaking Functions Apart: a TypeScript Experiment

How Auth0 helps you securely maintain user sessions and engagement in the era of ITP


## TL;DR

 * The ability to maintain seamless experiences for end-users in Single Page Applications (SPAs) is often business-critical and can have an enormous impact on revenue.
 * New browser privacy controls adversely impact the user experience in SPAs by preventing access to third-party cookies, which are used for silent authentication.
 * Auth0 now offers an alternative--Refresh Token Rotation--that provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.

## The Business Imperative

Maintaining an uninterrupted user experience without the need to continually log in is critical for continued engagement, conversion rates, and sustained revenue. If an end-user returns to your site and they are automatically authenticated, they are much more likely to make purchases because they can be shown relevant promotions, see items they may have left in their cart, and have one less barrier on the way to a successful checkout. According to a [2018 report from Accenture](https://www.accenture.com/t20171031T052156Z__w__/us-en/_acnmedia/PDF-34/Accenture-Pulse-Check-Dive-Key-Findings-Personalized-Experiences.pdf), 91% of consumers are more likely to shop with brands who **recognize, remember**, and provide relevant offers and recommendations.

This is especially important on mobile websites and in mobile applications, where having to re-enter credentials can be a nuisance and result in abandoned carts or users opting to access the content later (when they have time to remember/enter their credentials) rather than being able to do so at the moment. Anyone who’s made an impulse purchase on their phone after seeing something cool or remembering at the last minute that a loved one’s birthday is next week can attest to how nice it is to not have to provide username and password credentials in the throws of inspiration (or panic).

## OAuth2 and Securing SPA Access to APIs

Single Page Applications (SPAs) are everywhere, driven by the business needs for richer user experiences and exposed APIs for use by other services. Unfortunately, providing secure authentication in SPAs has a number of challenges based on your application’s use case. 

The former guidance of using the Implicit Grant to provide access tokens (ATs) to SPAs is fairly straightforward but carries with it several security risks that each require explicit mitigations you must account for. If you want a more detailed exposition on the challenges of using the Implicit Flow in SPAs, please read [this excellent treatise](https://auth0.com/blog/oauth2-implicit-grant-and-spa/) by the incomparable [Vittorio Bertocci](https://www.linkedin.com/in/vittoriobertocci).

Auth0’s guidance to date is to use the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](https://auth0.com/docs/flows/concepts/auth-code-pkce) in SPAs. This is a much more secure solution than the Implicit Flow, and when used in conjunction with [silent authentication](https://auth0.com/docs/api-auth/tutorials/silent-authentication), it ensures that SPAs can silently renew access tokens without interrupting the user experience.

This technique uses a hidden iframe to request a code from Auth0, leveraging the Auth0 session cookie to prove the user is authenticated, subsequently enabling the SPA to then exchange that code for a new AT without prompting the end-user. 

However, recent browser enhancements threaten the uninterrupted user experience businesses rely on. Browsers are building more capabilities to safeguard user privacy, including [Safari blocking access to all third-party cookies](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) and [Chrome’s commitment](https://techcrunch.com/2020/01/14/google-wants-to-phase-out-support-for-third-party-cookies-in-chrome-within-two-years/) to do so within two years. 

Beyond the marketing and tracking implications of these changes, which many people applaud, there are unfortunate impacts on how SPAs leverage OAuth to access resources. These advancements, unfortunately, mean that the technique of preserving an uninterrupted user experience via Code Flow with PKCE in conjunction with silent authentication are no longer feasible because the hidden iframe can no longer access the Auth0 session cookie.

## What About Refresh Tokens? 

Beyond silent authentication, another technique for getting new access tokens is to use Refresh Tokens (RTs), which are typically long-lived and are used to request new ATs after the shorter-lived ATs expire.  [Refresh Tokens](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) are an elegant solution that is often used in native applications on mobile devices in conjunction with short-lived ATs to provide seamless UX without having to issue long-lived ATs. 

![Refresh Tokens]( https://images.ctfassets.net/23aumh6u8s0i/10MGE8a5mYfQ5B6vJQX7MW/4be95e14a614b51ab88c477a382fe710/01_RTs_ATs)
(Like our fancy icons?
[Learn more about Auth0’s free Identicons](https://auth0.com/blog/introducing-auth0-identicons-identity-icons/)!)

This is why you can access streaming video services on your smart TV without signing in after you complete the initial Device Authorization; RTs are getting new ATs for you all the time. 

Unfortunately, long-lived RTs are not suitable for SPAs because there is no persistent storage mechanism in a browser that can assure access by the intended application only. As there are vulnerabilities that can be exploited to obtain these high-value artifacts and grant malicious actors access to protected resources, using refresh tokens in SPAs has been strongly discouraged. 

So... Privacy technology is impeding the Code Flow with PKCE & silent authentication. Refresh tokens can’t securely be persisted in browsers for long periods of time. What can we do?

## Introducing Refresh Token Rotation

As previously mentioned, using RTs in SPAs was considered insecure because they typically have long lifetimes (hence, their use in retrieving new short-lived ATs) and browser storage is susceptible to token theft. However, there are acceptable mitigations outlined in the most recent [OAuth2 BCP for browser-based applications](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05) stipulating that refresh tokens may be used provided that they adhere to [specific recommendations](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05#section-8), including having a maximum lifetime and requiring rotation to protect against malicious re-use.

_"The best practices doc states that another acceptable mechanism for protecting refresh tokens for use in public clients (not just browsers) is **refresh token rotation**, a feature that invalidates a refresh token and issues a new one whenever it is used to refresh an access token. Security-wise, that's a great feature."_

Reference: [https://auth0.com/blog/oauth2-implicit-grant-and-spa/](https://auth0.com/blog/oauth2-implicit-grant-and-spa/)

Auth0 is proud to announce that as of today, **Refresh Token Rotation with Reuse Detection** is available for all customers. With Refresh Token Rotation enabled, every time a client exchanges an RT to get a new AT, a new RT is also returned and the preceding RT is invalidated. This means you don’t need to worry about having a long-lived RT that, if compromised, could provide illegitimate access to resources. As RTs are continually exchanged and invalidated, the threat surface area is greatly reduced.

Auth0 makes it easy to get started with Refresh Token Rotation. You can enable it via API call or using the Auth0 Dashboard with just a few clicks.

![Refresh Token Rotation with Reuse Detection]( https://images.ctfassets.net/23aumh6u8s0i/5QNg54N5PHCx1Wkp40uI7D/e31f25ef32c16c04f256b773be2508c8/02_rotating-tokens)

RTR is supported for any application using the following flows:

 * OAuth2 Authorization Code Flow
 * OAuth2 Authorization Code Flow with Proof Key for Code Exchange (PKCE)
 * OAuth2 Device Authorization Grant (Device Flow)
 * Resource Owner Password Grant (ROPG)

The following diagram illustrates how Refresh Token Rotation is used in conjunction with the Authorization Code Flow with PKCE, but the general principle of getting a new refresh token with each exchange applies to all supported flows.

![RTR Sequence Diagram](https://images.ctfassets.net/23aumh6u8s0i/31zrZnDZ9lQVNE4Xsu0J2w/b7d7686b3764798eff19ce134229ae8b/03_RTR_Sequence_Diagram)

## Automatic Reuse Detection

When a client needs a new AT, it sends the RT with the request to Auth0 to get a new RT/AT pair. As soon as the new RT/AT pair is issued by Auth0, the RT used in the request is invalidated. This helps safeguard your application from replay attacks resulting from compromised RTs.

Without enforcing sender-constraint using techniques like mTLS or Proof of Possession that require the client to prove it is the same one originally authorized, which are not yet widely adopted, it’s impossible for the Authorization Server (AS) to know which actor is legitimate or malicious in the event of a replay attack. Therefore, it’s important that when a previously-used RT (already invalidated) is sent to the AS that the most recently issued RT is immediately invalidated as well, preventing any RTs in the same token family--all RTs descending from the original RT issued for the client--from being used to get new ATs.

Let’s consider the following scenario: 

1. Legitimate Client has RT1, and RT1 is leaked to or stolen by Malicious Client. 
2. Legitimate Client uses RT1 to get a new RT/AT pair.
3. Auth0 returns RT2/AT2.
4. Malicious Client then attempts to use RT1 to get an access token. Auth0 recognizes that RT1 is being reused, and immediately invalidates the RT family, including RT2 because the reappearance of RT1 is indicative of token leakage. It is important that RT2 is also invalidated to prevent any subsequent damage, such as the attacker gaining access to that token.
5. Auth0 returns an Access Denied response to Malicious Client.
6. AT2 Expires and Legitimate Client attempts to use RT2 to request a new RT/AT pair. 
7. Auth0 returns an Access Denied response to Legitimate Client. Re-authentication is required.


![RTR Token Family](https://images.ctfassets.net/23aumh6u8s0i/4sQHivXQ1DSIYiySY7LfBx/69640b448b38980cb8433341e4fe646a/04_RTR_Token_Family)

This protection mechanism works regardless of whether the legitimate client or the malicious client is able to exchange RT1 for a new RT/AT pair before the other. As soon as reuse is detected, all subsequent requests will be denied until the user re-authenticates. And when reuse is detected, Auth0 captures this event in logs to provide visibility for security reviews/audits. This can be especially useful in conjunction with Auth0’s new log streaming capabilities.

This means that you can safely use RTs to mitigate the adverse effects of browser privacy tools and provide continuous access to end-users without disrupting the user experience.

## A Little Leeway Sometimes Helps

To ensure that re-use detection doesn’t adversely affect users that suffer intermittent network performance, we’ve also included a **configurable reuse interval** to account for scenarios where the tokens issued from Auth0 are not received before the client application retries using the original refresh token. This is especially important in cases where users may be on slower cellular connections or congested networks.

For example, a client application has a refresh/access token pair (RT1 & AT1). AT1 is short-lived and expires. The client needs to use RT1 to get a new AT. The client sends RT1 to Auth0, but experiences a network error before getting a response from Auth0, and never receives AT2 or RT2. So the client retries a few seconds later using RT1 again (the only RT it currently has in its possession). Without a sufficient reuse interval configured, Auth0 would recognize the retry as a reuse attempt, invalidate the entire RT family, and require a re-authentication. 

By configuring a reuse interval, you can account for known network issues based on your use-cases, such as scenarios where the client is accessed on a mobile device with spotty connectivity. Should you choose to configure a reuse interval, the safest practice is to use the shortest amount of time to afford protection from replay attacks.

## SDK Support

The following SDKs are updated to include support for Refresh Token Rotation:

 * [Auth0 SPA SDK (1.7.0)](https://auth0.com/docs/libraries/auth0-spa-js)
 * [Auth0 Swift (iOS) SDK (1.23.0)](https://auth0.com/docs/libraries/auth0-swift)
 * [Auth0 Android SDK (1.23.0)](https://auth0.com/docs/libraries/auth0-android)

The Auth0 SPA SDK previously did not support refresh tokens of any kind, until today. Now, you can enable the use of rotating RTs and successfully mitigate the effects of browser privacy tools when performing silent authentication. 

One additional security feature that has been included is the ability for the SDK to leverage web workers to make requests to the token endpoint and store new RTs. This makes it much harder for malicious actors to retrieve refresh tokens straight out of the in-memory store.

In addition, we now enable the developer to opt-in to storing tokens in either local storage or browser memory, the default being the latter.

You can read more about all of the new features in the [SDK documentation](https://auth0.com/docs/libraries).

## Let’s Get Started

As of April 15, 2020, Refresh Token Rotation is available for all Auth0 customers. You can read more about Refresh Token Rotation and how to configure it for use in your applications in the [Auth0 documentation](https://auth0.com/docs/tokens/concepts/refresh-token-rotation). We hope that you find this new capability helpful for sustaining user sessions and maintaining engagement in this era of heightened user privacy tools.

Stay healthy. Stay safe. And secure your SPAs!

<include src="asides/AboutAuth0" />


Securing Single Page Applications with Refresh Token Rotation

1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Former Auth0 Employee

Prosper Otemuyiwa

Learn about the new features in React 16.3. New Lifecycles, Context, Strict Mode, createRef, and forwardRef




[ReactJS 16 shipped with a lot of new features](https://auth0.com/blog/whats-new-in-react16). Since then, even more features have been introduced to the library.

_React 16.3_ ships with a few major changes that I'll like to highlight in this article. Let's dive in!


## StrictMode Component

JavaScript developers are very familiar with the `strict` keyword. This keyword keeps you in check while developing your apps and raises an alarm during development to let you know about potential problems in your codebase.

_React 16.3_ ships with a `StrictMode` component that highlights potential problems in your ReactJS codebase.

This component runs a check in development mode to determine if there are issues with the descendant components such as using an unsafe lifecycle method, legacy ref API, etc.

```js
import React from 'react';

function WokeAlarm() {
  return (
    <div>
      <Header />
      <React.StrictMode>
        <div>
          <SetAlarm />
          <RingAlarm />
        </div>
      </React.StrictMode>
      <Footer />
    </div>
  );
}
```

## New Lifecycle Methods

_React 16.3_ ships with new lifecycle methods such as `getDerivedStateFromProps`, and `getSnapshotBeforeUpdate`.

The current lifecycle methods `componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate` will be deprecated in a future ReactJS 16.x release because they have been known to be problematic and behave in unintended ways. These methods will continue to be available for use in the next major release, _React 17_.

* **getDerivedStateFromProps** can be used instead of `componentWillReceiveProps`.
* **componentDidMount** can be used instead of **componentWillMount**.
* **componentDidUpdate** can be used instead of **componentWillUpdate**.

The new `getDerivedStateFromProps` method is static and will be called on the initial mounting of the component and also when the component is re-rendered.

<include src="TweetQuote" quoteText="The new getDerivedStateFromProps method is static and will be called on the initial mounting of the component."/>

```js
class Speaker extends Component {
  static getDerivedStateFromProps() {
    if (nextProps.value !== prevState.value) {
      return ({ value: nextProps.value });
    }
  }
}
```

The new `getSnapshotBeforeUpdate` method is called before any DOM mutations happen. It's great to perform any sort of calculations needed for your component here and then pass it to `componentDidUpdate` as the third argument like so:

<include src="TweetQuote" quoteText="The new getSnapshotBeforeUpdate method is called before any DOM mutations happen."/>

```js
...
getSnapShotBeforeUpdate(prevProps, prevState) {
  return prevProps.list.length < this.props.list.length ? this.listRef.scrollHeight : null;
}

componentDidUpdate(prevProps, prevState, snapshot) {
  if (snapshot !== null) {
    const listRef = this.listRef;
    listRef.scrollTop += listRef.scrollHeight - snapshot;
  }
}
...
```

## forwardRef

**Refs** provide a way to access ReactJS elements or DOM nodes created in the render method. They are great for getting values from input elements, working with third-party DOM libraries, et al. However, there were some challenges with **refs** regarding component encapsulation.

`forwardRef` automatically passes a `ref` received by a parent component to its children. It's great for reusable components in component libraries. As the name implies, the component is forwarding the `ref` to its child.

Check out the example below:

```js
import React, { Component } from 'react';

const LoginButton = React.forwardRef((props, ref) => (
  <button ref={ref} class="Login"> {props.children} </button>
));


class Display extends Component {
  myRef = React.createRef();

  componentDidMount() {
    this.myRef.current.focus();
  }

  render() {
    return (
      <div className="container">
        <LoginButton ref={this.myRef}> Get In! </LoginButton>
      </div>
    )
  }
}
```

The use of `forwardRef` is more valuable in Higher Order Components. The [ReactJS blog](https://reactjs.org/docs/forwarding-refs.html) has the perfect example of this scenario.

## createRef

Previously, ReactJS developers had two ways of using refs: You either made use of the callback API or the legacy string ref API.

With _React 16.3_, you can make use of the `createRef` API for managing refs without any negative implications. It's simpler and developer friendly too. Check out the example below:

_without createRef API_

```js
class SpeakerComponent extends React.Component {
  constructor(props) {
    super(props);
  }

  render() {
    return <input type="text" ref={(input) => {
      this.inputRef = input;
    }} />;
  }
}
```

_with createRef API_

```js
class SpeakerComponent extends React.Component {
  constructor(props) {
    super(props);

    this.inputRef = React.createRef();
  }

  render() {
    return <input type="text" ref={this.inputRef} />;
  }

  componentDidMount() {
    this.inputRef.current.focus();
  }
}
```

## Context API

The `Context` API has been available for a while but in experimental mode. _React 16.3_ ships with an ergonomic Context API that supports static type checking and deep updates. This API solves the challenge most developers experience which is the complexity of passing data from child to parent and back and make them quickly reach out for [Redux](https://redux.js.org).

Check out this example below:

```js
import React, { Component } from 'react';

const Dog = (props) => (
  <div>
    <Animal name={props.name} />
  </div>
);

}
class Animal extends Component {
  render() {
    return (
      <div>
        <p> Hey, I'm a {this.props.name} </p>
      </div>
    )
  }
}


class App extends Component {
  state = {
    name: 'Casanova',
    food: 'bone',
  }

  render() {
    return (
      <div>
        <Dog name={this.state.name} />
      </div>
    )
  }
}

export default App;
```

This is a simple example, but the way we pass data from component to component with the use of props is not developer friendly and could get out of hand very quickly! At this point, most developers quickly reach out for a data store or state management library to manage this process efficiently. However, the new Context API in _React 16.3_ can be used to eliminate this challenge.

With this new API, we'll need a **Provider** and a **Consumer**. The data will live in the **Provider** while the **Consumer** represents where the data needs to be accessed.

```js
import React, { Component } from 'react';

// create a new context
const MyContext = React.createContext();

// create a provider component
class MyProvider extents Component {
  state = {
    name: 'Casanova',
    food: 'bone'
  }

  render() {
    return (
      
      <MyContext.Provider value={{ state: this.state }}>
        { this.props.children }
      </MyContext.Provider>
      
    )
  }
}

const Dog = (props) => (
  <div>
    <Animal />
  </div>
);

class Animal extends Component {
  render() {
    return (
      <div>
        <MyContext.Consumer>
          {(context) => (
            <React.Fragment>
              <h3> Food: { context.state.food } </h3>
              <h3> Name: { context.state.name } </h3>
            </React.Fragment>
          )}
        </MyContext.Consumer>
      </div>
    )
  }
}

class App extends Component {
  render() {
    return (
      <MyProvider>
        <div>
          <Dog />
        </div>
      </MyProvider>
    )
  }
}

export default App;
```

In the code above, there is a provider, `<MyProvider />`, that houses the state and renders a Context provider.

The Context provider provides the ability to render children components as evident in the `<App />` component. We simply called the consumer, `<MyContext.Consumer />`, in the Animal component to render the data we needed. This is more organized, and avoids the case of _props drilling hell_!

<include src="asides/React" />

## Conclusion

_React 16_ has been on a roller-coaster. And it's amazing how ReactJS is becoming more of a way of life than a library, in my opinion.

Have you upgraded to _React 16.3_ yet? What are your thoughts? Let me know in the comments section! 😊


React 16.3: What’s New?

9d2e715baab928f5bedb837bfcb70b2b

Guest Author

Gabor Soos

Learn how to test HTTP services in Angular. We will start by writing tests for requests and finish by refactoring them to a cleaner format.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2 book" for Free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When we write a web application, most of the time it has a backend.
The most straightforward way to communicate with the backend is with HTTP requests.
These requests are crucial for the application, so we need to test them.
More importantly, these tests need to be isolated from the outside world.
In this article I will show you how to test your requests properly and elegantly.

This article is the second part of a series in which
I share my experiences testing different building blocks of an Angular application.
It relies heavily on Dependency Injection based testing and
it is recommended that you read [the first part](https://auth0.com/blog/angular-2-testing-in-depth-services/)
if you are not familiar with the concepts.

- [Services](https://auth0.com/blog/angular-2-testing-in-depth-services/)
- HTTP Services (this article)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

### Testing our first request

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/github-logo.png" alt="Angular Testing Framework"/>
</p>

To get started we will test a basic request, the GET request.
It will call a parameterized url without a body or additional headers.
The [Github API](https://developer.github.com/v3/) has an endpoint for retrieving public profile information about users.
The profile information is returned in JSON format.

```typescript
import { Injectable } from '@angular/core';
import { Http, Response } from '@angular/http';
import 'rxjs/add/operator/map';

@Injectable()
export class GithubService {
  constructor(private http: Http) {}

  getProfile(userName: string) {
    return this.http
      .get(`https://api.github.com/users/${userName}`)
      .map((response: Response) => response.json());
  }
}
```

The ```getProfile``` method sends a GET request to the API and returns the response.
Every request made with the ```HttpModule``` returns an ```Observable.```
The returned value will always be a ```Response``` object, which can return the response body.
With the help of the ```json``` or ```text``` method we can transform the value of the Observable.

The first thing we have to do is to set up the test dependencies.
The ```Http``` dependency is required.
If we don't provide it, we will get this error message: ```No provider for Http!```.

```typescript
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [GithubService],
    imports: [HttpModule]
  });
});
```

The problem with the real ```HttpModule``` is that we will end up sending real HTTP requests.
It is an absolutely terrible idea to do this with unit tests, because it breaks the test's isolation from the outside world.
Under no circumstances will the result of the test be guaranteed.
For example, the network can go down and our well-crafted tests will no longer work.

Instead, Angular has a built-in way to fake HTTP requests.

```typescript
import { MockBackend, MockConnection } from '@angular/http/testing';
import { Http, BaseRequestOptions, Response, ResponseOptions, RequestMethod } from '@angular/http';

...

beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [
      GithubService,
      MockBackend,
      BaseRequestOptions,
      {
        provide: Http,
        useFactory: (mockBackend: MockBackend, defaultOptions: RequestOptions) => {
          return new Http(mockBackend, defaultOptions);
        },
        deps: [MockBackend, BaseRequestOptions]
      }
    ]
  });
});
```

Instead of providing ```Http``` as a module,
it is better to use the factory provider and pass the ```MockBackend``` instance to the ```Http``` constructor.
This way the fake backend captures every request and can respond accordingly.

Before writing the first test it is also important to get an instance of the ```MockBackend,```
because without it we won't be able to respond to requests.

```typescript
beforeEach(inject([GithubService, MockBackend], (github, mockBackend) => {
  subject = github;
  backend = mockBackend;
}));
```

Let's write the first test that checks the result of the request.

```typescript
it('should get profile data of user', (done) => {
  let profileInfo = { login: 'sonic', id: 325, name: 'Tester' };
  backend.connections.subscribe((connection: MockConnection) => {
    let options = new ResponseOptions({ body: profileInfo });

    connection.mockRespond(new Response(options));
  });

  subject.getProfile('blacksonic').subscribe((response) => {
    expect(response).toEqual(profileInfo);
    done();
  });
});
```

Requests made are available through the ```connections``` property of the fake backend as an ```Observable.```
When it receives the request through the ```subscribe``` method we can respond with a JSON object.

In our example only the response body is set. In addition, you can set the status and the headers of the request.

Another new element is the ```done``` callback that is passed into the test function.
It is needed when writing asynchronous tests.
This way the test doesn't end when the execution of the function ends.
It will wait until the ```done``` callback is called.
Of course, there is a timeout for hanging tests that don't call this ```done``` method within a given interval.

HTTP requests are asynchronous by nature,
but the fake backend we use responds to them synchronously (it calls the ```subscribe``` method synchronously).
You may wonder what makes the test asynchronous, then.

The answer is false positive tests.
If we comment out the response to the request, the test will still pass, even though we have an assertion.
The problem here is that the ```subscribe``` callback never gets executed if we don't respond to the request.

```typescript
it('should get profile data of user', () => {
  // backend.connections.subscribe...

  subject.getProfile('blacksonic').subscribe((response) => {
    expect(response).toEqual(profileInfo);
  });
});
```
### Checking the request

Until now we haven't made any assertions for the request.
For example, what was the called url, or what was the method of the request?
To make the test more strict we have to check these parameters.

```typescript
backend.connections.subscribe((connection: MockConnection) => {
  expect(connection.request.url).toEqual('https://api.github.com/users/blacksonic');
  expect(connection.request.method).toEqual(RequestMethod.Get);

  ...
});
```

The original ```Request``` object resides on the ```MockConnection``` object.
With its ```url``` and ```method``` property, we can add the assertions easily.

### Digging deeper

GET requests are good for retrieving data, but we'll make use of other HTTP verbs to send data.
One example is POST.
User authentication is a perfect fit for POST requests.
When modifying data stored on the server we need to restrict access to it.
This is usually done with a POST request on the login page.

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/auth0-logo.png" alt="Angular Testing Framework"/>
</p>

Auth0 provides a good solution for handling user authentication.
It has a feature to authenticate users based on username and password.
To demonstrate how to test POST requests, we will send a request to the Auth0 API.
We won't be using their recommended package here, because it would abstract out the actual request,
but for real-world scenarios I would recommend using it.

```typescript
@Injectable()
export class Auth0Service {
  constructor(private http: Http) {}

  login(username: string, password: string) {
    let headers = new Headers({
      'Content-Type': 'application/json'
    });
    let options = new RequestOptions({ headers });

    return this.http
      .post(
        'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
        { username, password, client_id: 'YOUR_CLIENT_ID' },
        options
      )
      .map((response: Response) => response.text());
  }
}
```

The main difference between this example and the previous one is that here we are sending a JSON payload to the server
and appending additional headers onto it.
We don't have to manually ```JSON.stringify``` the payload --- the request methods will take care of it.
The response will be in text format, so this time we don't have to convert anything to JSON.

Let's look at the test to see how we can check every detail of the request.

```typescript
it('should be called with proper arguments', (done) => {
  backend.connections.subscribe((connection: MockConnection) => {
    expect(connection.request.url).toEqual('https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login');
    expect(connection.request.method).toEqual(RequestMethod.Post);
    expect(connection.request.headers.get('Content-Type')).toEqual('application/json');
    expect(connection.request.getBody()).toEqual(JSON.stringify(
      {
        username: 'blacksonic',
        password: 'secret',
        client_id: 'YOUR_CLIENT_ID'
      }, null, 2
    ));
    ...
  });

  subject.login('blacksonic', 'secret').subscribe((response) => {
    expect(response).toEqual('<form />');
    done();
  });
});
```

The headers are also available on the ```Request``` object and can be checked one by one.
The payload can be retrieved with the ```getBody``` method.
This method always returns the body converted to a string, which will we see in the network traffic.
When we send JSON it will contain the output of the ```JSON.stringify``` method: printed with spaces and an indentation of two.

### Refactoring

The previous setup works, but it has multiple problems.

- For every service we test, the provider configuration will be exactly the same.
- The subscription to the outgoing connection responds the same immediately, regardless of the url.
- The assertions are verbose and hard to read.

Those who have tested their HTTP services in Angularjs may remember how simple the setup was for those tests.
Angularjs provided convenient methods for setting expectations on requests.

Angular doesn't have those built-in functionalities,
but very similar ones are present in the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library.

It can solve the problems mentioned earlier.
Let's look at the test with the library for the Github profile fetch.

```typescript
...
import { FakeBackend } from 'ngx-http-test';

describe('GithubServiceRefactored', () => {
  ...

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        GithubService,
        FakeBackend.getProviders()
      ]
    });
  });

  beforeEach(inject([GithubService, FakeBackend], (github, fakeBackend) => {
    subject = github;
    backend = fakeBackend;
  }));

  it('should get profile data of user', (done) => {
    backend
      .expectGet('https://api.github.com/users/blacksonic')
      .respond(profileInfo);

    subject.getProfile('blacksonic').subscribe((response) => {
      expect(response).toEqual(profileInfo);
      done();
    });
  });
});

```

The setup becomes a function call to ```FakeBackend.getProviders()```.
Setting the expectation hides the subscription and gives more readable methods like ```expectGET```.

The login test also becomes less verbose.

```typescript
it('should be called with proper arguments', (done) => {
  backend.expectPost(
    'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
    {
      username: 'blacksonic',
      password: 'secret',
      client_id: 'YOUR_CLIENT_ID'
    },
    { 'Content-Type': 'application/json' }
  ).respond(responseForm);

  subject.login('blacksonic', 'secret').subscribe((response) => {
    expect(response).toEqual('</form>');
    done();
  });
});
```

## Aside: Securing Angular Applications with Auth0

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

We provide the simplest and easiest to use [User interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users.

### Conclusion: What we've learned about Angular HTTP testing

In this tutorial, we managed to:

- setup tests and fake an HTTP backend
- write assertions for requests
- refactor the tests to be more readable

Angular has the tools to test HTTP requests, but still lacks the readable assertion methods that were present in Angularjs.
Until such methods are implemented, the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library can be used.

To see the tests in action check out
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").


"ref"