I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

Discover the Model Context Protocol (MCP) and its authorization mechanisms. Learn how to use API keys, OAuth 2.1 implementation, and best practices for secure LLM API connections.

An Introduction to MCP and Authorization

tyler-nix

Tyler’s professional experience spans engineering, architecture, sales, and product at companies ranging from a small Series B startup to a large Fortune 5 enterprise. He now uses his diverse experiences to build better products at Okta. When he is not scaling digital products, he is pursuing hobbies that inherently don’t scale (especially those outside). He loves hearing his kids laugh while riding bikes, spotting a new bird species, and watching his garden grow.

Product Manager

Tyler Nix

Learn how the ReBAC authorization model overcomes RBAC when it comes to evaluate permissions on a specific resource.

In today’s dynamic digital landscape, ensuring users have the right permissions for specific resources is a critical task for any organization. Resource-based access control often needs to be highly fine-grained, especially in complex systems with millions of objects—such as files, projects, records, accounts, etc.

Yet building fine-grained authorization (FGA) correctly with traditional Role-Based Access Control (RBAC) presents several challenges, particularly when it comes to protecting against the top vulnerability in web applications: [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/).

RBAC itself isn't inherently problematic. But when you try to build fine-grained authorization on top of RBAC, the struggle creeps in. However, this is where Relationship-Based Access Control (ReBAC) shines: evaluating permissions on a per-resource basis. ReBAC makes it simple to perform an authorization check on complex permission models.

## The Difficulty of Building Fine-Grained Authorization with RBAC

[RBAC](https://auth0.com/docs/manage-users/access-control/rbac) has been the go-to method for managing access control in many applications. In RBAC, users are assigned to roles (e.g., admin, editor, viewer), and roles are mapped to permissions that give access to various resources.

A common approach to evaluating access to a resource in an application is to include the permissions in a user’s access token as scopes. However, since most scopes are generic and binary (e.g. `_view_all_documents_`), it would be difficult to manage detailed, resource-specific scopes (e.g. _view_document_123_) by adding them to the token because it would lead to token bloat. Additionally, since scopes in a token are static by design, they cannot easily reflect real-time permission updates until the token is refreshed.

Because of this, developers will often implement their own custom FGA solutions using RBAC built with SQL tables to unlock more dynamic and real-time access control. But this approach isn’t without its issues.

As systems grow and product improvements require more intricate resource hierarchies, the need to manage numerous roles, users, and resource-specific permissions leads to messy databases and unruly SQL queries, which often involve multiple joins spread out across database tables or services.

In contrast, [(ReBAC)](https://docs.fga.dev/authorization-concepts#what-is-relationship-based-access-control) models permissions based on relationships between users and resources, simplifying the evaluation logic. With ReBAC, permissions are dynamic and context aware. While you can fully implement RBAC roles within ReBAC, it also allows for more granular control over who can do what with each resource.

## Evaluating Resource-Specific Permissions with RBAC

Let’s consider an example: In a project management application, Aria is the admin for her entire organization. She is thus granted permissions to view and edit all documents in any project. The developers of the application have chosen to implement resource-specific authorization by building RBAC in SQL tables.

How do we determine if Aria has access to view a specific document? She would not have any direct assignments because she is not the document creator, but she should inherit the “editor” permissions since she is the organization’s admin. Evaluating this resource-specific authorization check in RBAC would require joining the various database tables that contain the role assignments and resource hierarchies in the organization to see if her "admin" role cascades down to that specific document.

As a result, with each permission check requiring more complex SQL queries, the application’s authorization logic becomes difficult to manage and even harder to update, possibly even leading to performance issues with deeply nested resources.

## How ReBAC Simplifies Resource-Specific Permission Checks

With ReBAC, permissions are calculated based on relationships instead of explicitly assigned roles, simplifying the evaluation of who has access or not. In a ReBAC system, Aria’s permissions aren’t solely based on her role but also on her role’s relationships with a document. Since Aria is the admin of the organization, the relationship can be cascaded down from the organization level via inheritance to a specific project or document level.

When you need to make an authorization check on a specific resource, the authorization system references the logic defined in the authorization model against the known object relationships and returns a decision (i.e. true or false). “_Can Aria edit the document business-report-1?_” = TRUE. We’ll learn later why this authorization check can be so simple.

> ReBAC makes it far more efficient than RBAC to check access on a per-resource basis.

## Evaluating Permissions with Okta Fine Grained Authorization

Now, let’s explore how Okta Fine Grained Authorization, a hosted and managed service of the popular open-source ReBAC project OpenFGA, leverages relationship-based access control to simplify access management.

Okta Fine Grained Authorization is designed to be flexible enough to work for small startups scaling single applications but powerful enough for large enterprise corporations creating complex relationships at a global scale. It does all of this while staying friendly enough for adjacent stakeholders on the team to read and understand the authorization logic.

Let’s build on the practical example above of Aria being an admin in her project management company. Suppose you have a hierarchical system in which different teams have access to various documents in a project based on the user's assignment.


### Sample Authorization Model in Okta Fine Grained Authorization

```bash
model
   schema 1.1

type user

type organization
  relations
    define admin: [user]

type project
  relations
     define organization: [organization]
     define owner: [user] or admin from organization
     define member: [user]
     define viewer: member or owner

type folder
  relations
     define parent: [folder, project]
     define owner: owner from parent
     define viewer: viewer from parent or owner

type document
  relations
     define parent: [folder]
     define editor: [user] or owner from parent
     define viewer: [user] or viewer from parent or editor
```

In this model, there are five core “types”: `user`, `organization`, `project`, `folder`, and `document`. Each plays a specific role in managing access within the system.

- `User` represents the individuals who will interact with the system. Users are assigned roles and permissions either directly or through group memberships.
- `Organization` contains all the projects with the ability to assign a global admin (like Aria).
- `Project` contains members, controlling access to project documents through membership at a top-level project.
- `Folder` adds a hierarchy to managing resources, connecting users to documents, even through deeply nested folders.
- `Document` inherits access permissions from their parent folder, which ultimately inherits from the project, all while allowing direct assignment to enable use cases like sharing a document with an external user.

A typical authorization scenario might look like this:

1. _Document_ business-report-1 is nested inside two _Folders_ under _Project_ Alpha.
2. _Project_ Alpha is a part of the Acme _Organization_.
3. Aria is assigned as the admin of the Acme _Organization_.

In Okta Fine Grained Authorization, these would be represented as relationship tuples stored in the centralized authorization system. You can think of Okta Fine Grained Authorization as a permissions database and tuples are the data. Each tuple will contain a user, relation, and object value like this:

```bash
{
  User: user:aria
  Relation: admin
  Object: organization:acme
}
```

Thus, following the logic in the authorization model, the access check for _“Can Aria edit the document business-report-1?”_ would return TRUE because:

1. Aria has the admin relationship in the Acme organization.
2. The admin relationship receives the owner relationship in the projects of that organization.
3. The owner relationship is thus inherited by the folders in that project.
4. Owner permissions continue to cascade down to the editor relationship of the documents inside the organization’s project folder, of which Aria is the admin.

![](https://images.ctfassets.net/23aumh6u8s0i/3pEKrtX5hEZrGMz2mT40RV/d13f7730b526aec43508c1f1294b37e3/01_rebac.png)

![](https://images.ctfassets.net/23aumh6u8s0i/65WRfIj3zGTtCo8S5dimhn/e8150eab044f6763069ff81cb42bf5c7/02_rebac.png)

## The Okta Fine Grained Authorization API

With ReBAC and Okta Fine Grained Authorization, querying permissions is as simple as checking a user’s relationship to a resource. Instead of performing multiple joins across tables as in RBAC, a single API call checks the relationship, making it highly efficient.

```bash
curl -X POST https://api.fga.dev/stores/{store_id}/check \
  -H "Authorization: Bearer {your_api_token}" \
  -d '{

    "tuple_key": {
        "user": "user:aria",
        "relation": "editor",
        "object": "document:business-report-1"
      }
}'
```

While RBAC is a powerful model for role-based permissions, it can struggle when adapted to manage fine-grained, resource-specific permission scenarios. Alternatively, ReBAC excels in dynamic, heavily-nested environments where permissions are based on inherited relationships between users and resources. By adopting ReBAC (and using a platform like Okta Fine Grained Authorization), development teams can streamline how they handle complex access control in their applications, reducing the major risk of broken access control that can stem from complex database queries. Try [Okta Fine Grained Authorization](https://auth0.com/fine-grained-authorization) for free.

### Additional Resources

- [https://fga.dev](https://fga.dev/)
- [FGA Playground](https://play.fga.dev/)
- [Fine-Grained Authorization in your Next.js application using Okta FGA](https://auth0.com/blog/fine-grained-access-control-with-okta-fga-nextjs/)
- [FGA Modeling Guide Video Series](https://www.youtube.com/watch?v=8VGy52SQ8bw)

How To Evaluate Resource-Specific Permissions Efficiently with ReBAC instead of RBAC

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Take control of your encryption keys using the BYOK security model in your Auth0 tenant.

As the cloud continues to spread and sensitive data is entrusted to service providers, customers wonder how it is protected and how they can exercise control over the security of their data. One way to allow a customer to take control of the confidentiality of their data is to use the Bring Your Own Key (BYOK) approach. In this article, you'll learn what BYOK is and how you can leverage it in Auth0.

## What Is Bring Your Own Key?

Cloud service providers secure customer secrets and data using [envelope encryption](https://en.wikipedia.org/wiki/Hybrid_cryptosystem#Envelope_encryption). This is a proven security mechanism that ensures a high level of protection of customer data using a hierarchy of encryption keys. Specifically, to encrypt data, the cloud provider platform uses Data Encryption Keys that are wrapped by a Root Key. So, to access the Data Encryption Key, a service needs access to the Root Key. Optionally, other intermediate keys can exist between the Data Encryption Keys and the Root Key.

This hierarchy not only enables data protection but also aims at protecting the encryption keys. Encryption and decryption of data are performed by a Key Management System (KMS) that leverages this key hierarchy. In addition, most cloud providers use a Hardware Security Module (HSM) to store the Environment Root Key, ensuring the strongest protection.

In the end, customers' sensitive data are encrypted using the Data Encryption Key, but due to this key hierarchy, only those who have access to the root key of this hierarchy can actually access the unencrypted data.

### Why BYOK?

Usually, the cloud service provider issues and manages the Root Key. Ultimately, the cloud service provider has control over the key hierarchy, the data encryption, and the security of the customer data. However, this is not always the situation that a customer wants. There may be several reasons why a customer doesn't want the cloud service provider to control the Root Key and then the key hierarchy:

- They may need to comply with some key provenance requirements.
- They may need to comply with some data protection requirements.
- They may need to attain control of the lifecycle of the cryptography for users' sensible data.

Think of the financial or healthcare sectors, where data confidentiality is key. In these cases, cloud service providers allow customers to issue and use their own encryption key as the Root Key for the key hierarchy, hence the name **Bring Your Own Key** (BYOK) for this approach to take control of the encryption in a cloud environment.

## BYOK in Auth0

As with any cloud service provider, Auth0 by Okta uses envelope encryption to secure customer data, too. To encrypt data, Auth0 uses Data Encryption Keys that are wrapped by a Tenant Master Key, which in turn is wrapped by the Environment Root Key. Take a look [here](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys#auth0-key-hierarchy) to have more details on the Auth0 key hierarchy.

Auth0 stores the Environment Root Key in a Hardware Security Module (HSM), which is deployed in a highly available, multiple geographic configuration. In other words, the HSM will failover to another region in case of a severe region-wide incident. The HSMs are available for [the two private cloud deployments](https://auth0.com/docs/deploy-monitor/deploy-private-cloud) supported by Auth0 &mdash; AWS and Azure &mdash; with [different encryption algorithms](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys#environment-root-key).

With BYOK, Auth0 allows tenant administrators to securely import their own Root Key to the respective cloud provider's HSM. They can use the Auth0 Dashboard or Management API to replace the Auth0 Environment Root Key with their own Customer Provided Root Key, as you will see in the next section.

> Bring Your Own Key is available on [Enterprise plans](https://auth0.com/pricing) with [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity) add-on.

## How to Bring Your Key in Auth0

In this section, you will learn how to import your own encryption key in your Auth0 environment using the Auth0 dashboard. Make sure you have an Enterprise plan with the Highly Regulated Identity add-on to be able to use this feature. Basically, the process consists of three steps:

1. Generate and download a wrapping encryption key from the Auth0 dashboard.
2. Generate your own encryption key and wrap it with the downloaded wrapping encryption key.
3. Upload the wrapped encryption key via the Auth0 dashboard.

For demo purposes, you will use OpenSSL to generate and wrap your encryption key, but in a real-world scenario, you should use an HSM, either on-premises or cloud-based, for key generation.

> Make sure you have [OpenSSL](https://www.openssl.org/) installed on your machine. If you have a macOS machine, be aware that it ships with [LibreSSL](https://www.libressl.org/), which is a fork of OpenSSL and has some differences.

### Get the wrapping encryption key

The first step is to get the wrapping encryption key from Auth0. Go to your [Auth0 dashboard](https://manage.auth0.com), click the *Settings* menu item, and select the [Encryption Keys](https://manage.auth0.com/#/tenant/encryption_keys) tab. You will see the following screen:

![Encryption keys management in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/3PBjaL5gFyc2iULvFb8ZSk/ad53ccc8484a587cdbea4ed60dec1efd/auth0-dashboard-encryption-keys.png)

Now, click the *Upload Key* button and you will get the modal shown below:

![Download Auth0 wrapping encryption key](https://images.ctfassets.net/23aumh6u8s0i/2ED5p9T6aUpnWPZkGffLcn/ac4069f77c95709a1034d6c80bc3bbef/download-wrapping-encryption-key.png)

Click the *Download* button to get the wrapping encryption key from Auth0. This ensures that your own key will be securely transferred to Auth0.

> Until you have uploaded your own key, Auth0 will continue to use the built-in Environment Root Key.

### Generate and wrap your own key

If you are using a Hardware Security Module to generate your key, follow its specific instructions. For test purposes, we are using Open SSL here, which requires some preprocessing of the content of the PEM file you downloaded from Auth0, the key generation, and then the actual key wrapping. Let's examine each step.

#### Preprocess the wrapping key

Open the file with a text editor and manually remove the PEM header and footer, i.e., the `-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----` strings. Then, remove all the line breaks in the file. The result will be a one-line file with the bits of the key.

Now, decode the content of this file from Base64 to binary. In Linux-based systems and macOS, you can use the [`base64`](https://www.gnu.org/software/coreutils/manual/html_node/base64-invocation.html) builtin tool as shown in the following example:

```bash
cat wrapping-key.pem | base64 -d > wrapping-key.bin
```

Assuming that your Base64-encoded file is named `wrapping-key.pem`, the previous command generates the binary decoded version into the file named `wrapping-key.bin`.

On Windows systems, you can use the [`certutil`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) tool as follows:

```powershell
certutil -decode wrapping-key.pem wrapping-key.bin
```

#### Generate your own key

Each [cloud provider has its own requirements](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys/customer-managed-keys-dashboard#cryptographic-material-requirements) for the key you should generate, so you should use the appropriate settings for the [CKM\_RSA\_AES\_KEY\_WRAP](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cos01/pkcs11-curr-v2.40-cos01.html#_Toc408226894) algorithm parameters.

Assume you are using AWS as your Auth0 cloud provider in our example. You can generate your 32 bytes (256 bits) symmetric key as follows:

```bash
openssl rand -out customer-key-material-key.bin 32
```

You also need a 32 bytes-long ephemeral AES encryption key that is required for AES Key Wrap with padding step:

```bash
openssl rand -out ephemeral-aes-kek-kwp.bin 32
```

Now you have two new files:

- `customer-key-material-key.bin`, which contains your symmetric key that will be used instead of the Auth0 Environment Root Key. Let's call it the *customer key*.
- `ephemeral-aes-kek-kwp.bin`, which contains another symmetric key that will be used to wrap the *customer key*, as [required by AWS](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys/customer-managed-keys-dashboard#auth0-on-aws-cloud). Let's call it the *ephemeral key*.

#### Wrap your own key

Let's start by wrapping the *customer key* with the *ephemeral key*. Use the following command:

```bash
openssl enc -id-aes256-wrap-pad \
        -K "$(xxd -p < ephemeral-aes-kek-kwp.bin | tr -d '\n')" \
        -iv A65959A6 \
        -in customer-key-material-key.bin \
        -out customer-key-material-wrapped.bin
```

You will get the `customer-key-material-wrapped.bin` file.

Now, wrap the *ephemeral key* with the wrapping key you downloaded from Auth0 and preprocessed earlier:

```bash
openssl pkeyutl \
    -encrypt \
    -in ephemeral-aes-kek-kwp.bin \
    -out ephemeral-aes-kek-kwp-wrapped.bin \
    -inkey wrapping-key.bin \
    -keyform DER \
    -pubin \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256 \
    -pkeyopt rsa_mgf1_md:sha256
```

The result of this command will be the `ephemeral-aes-kek-kwp-wrapped.bin` file.

As the final step, concat the two wrapped files you generated and encode the result with Base64:

```bash
cat ephemeral-aes-kek-kwp-wrapped.bin customer-key-material-wrapped.bin | base64 > encrypted-key-material-b64
```

The file `encrypted-key-material-b64` is the file you will upload to Auth0 to complete the BYOK process.

### Upload your newly created Root Key

Go back to your Auth0 dashboard and follow the steps again to open the modal to upload the key. This time, click the *Choose File* button and select the `encrypted-key-material-b64` file you created in the previous step:

![Upload customer key to complete BYOK](https://images.ctfassets.net/23aumh6u8s0i/5MSJvTULvP0zSYga5Nzjhq/22c95f9d6faa2e2a3a7ad27c457cc647/upload-customer-key-byok.png)

Click the *Save* button to complete the BYOK process.

Congratulations! Now Auth0 will be using your own encryption key as your Environment Root Key:

![Auth0 dashboard with BYOK enabled](https://images.ctfassets.net/23aumh6u8s0i/6cKLg7wB5TYxqGRL8WRfGr/3b4a64b4d61ce3cff640f46ccddbfd5a/auth0-dashboard-with-byok-enabled.png)

> Keep in mind that by importing your own encryption key, you implicitly deauthorize Auth0 from managing the lifecycle of the Environment Root Key. This means that now you are in charge of rotating the key periodically.

## Automate the Key Generation and Wrapping

As you can see, there are a few manual steps to generate and wrap the encryption key to upload to Auth0. Fortunately, you can blend it all into one script as the following (only for Bash):

```bash
#!/bin/bash

# Check if a .pem file is passed as an argument
if [ -z "$1" ]; then
    echo "Usage: $0 <path to pem file>"
    exit 1
fi

PEM_FILE="$1"

#Ensure the file exists
if [ ! -f "$PEM_FILE" ]; then
    echo "File not found: $PEM_FILE"
    exit 1
fi

#1. Remove the first line (BEGIN CERTIFICATE)
#1. Remove the last line (END CERTIFICATE)
#1. Remove  all line breaks
#4. Remove any trailing characters like whitespace

CERT_DATA=$(sed '1d;$d' "$PEM_FILE" | tr -d '\n\r' | tr -d ' ')


if [ -z "$CERT_DATA" ]; then
    echo "Cleaned certificate is empty"
    exit 1
fi


echo "Processed certificate data: $CERT_DATA"

PUBLIC_WRAPPING_KEY=public-wrapping-key.bin

printf "%s" "$CERT_DATA" | base64 -D  > $PUBLIC_WRAPPING_KEY

if [ ! -f "$PUBLIC_WRAPPING_KEY" ]; then
    echo "Public Wrapping key file does not exist"
    exit 1
fi

openssl_operations() {
    echo "Running OpenSSL..."

    openssl rand -out customer-key-material-key.bin 32
    openssl rand -out ephemeral-aes-kek-kwp.bin 32
    openssl enc -id-aes256-wrap-pad \
        -K "$(xxd -p < ephemeral-aes-kek-kwp.bin | tr -d '\n')" \
        -iv A65959A6 \
        -in customer-key-material-key.bin \
        -out customer-key-material-wrapped.bin

    openssl pkeyutl \
    -encrypt \
    -in ephemeral-aes-kek-kwp.bin \
    -out ephemeral-aes-kek-kwp-wrapped.bin \
    -inkey public-wrapping-key.bin \
    -keyform DER \
    -pubin \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256 \
    -pkeyopt rsa_mgf1_md:sha256

    cat ephemeral-aes-kek-kwp-wrapped.bin customer-key-material-wrapped.bin | base64 > encrypted-key-material-b64 

    rm customer-key-material-key.bin ephemeral-aes-kek-kwp.bin customer-key-material-wrapped.bin ephemeral-aes-kek-kwp-wrapped.bin public-wrapping-key.bin

    # echo "$DECODED_CERT" | openssl ...
}

openssl_operations
```

This simplifies the generation and wrapping steps, making the process more straightforward, as you can see in the following video:

<AmpContent>
<amp-youtube
    data-videoid="InbHi6fRMKo"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  className='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/InbHi6fRMKo'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

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

## Conclusion

This article showed you how Auth0 supports Bring Your Own Key, an approach that lets you control the provenance of the root key used to encrypt your secrets and data in the Auth0 environment.

You used OpenSSL as a testing tool to generate and wrap your own key and learned how to use the Auth0 dashboard to configure your environment with it.

A special thanks to Filip Palach and Lucas Gomes for their work on the OpenSSL process and the script.

If you want to learn more about BYOK in Auth0, leave a message below.


Bring Your Own Key (BYOK) in Auth0

Explore how tools like Auth0 Organizations, OPA, and Okta FGA can streamline your authorization strategy for secure, scalable SaaS development.

When building a multi-tenant SaaS application, selecting the right authorization model is critical to ensure the security and scalability of your system. Authorization is not only about managing user access but also about ensuring that tenants remain isolated, protected, and—where necessary—able to collaborate. The right model for your SaaS depends on the complexity of your application, the relationships between users and resources, and how dynamic or flexible your access control needs to be. This guide provides a deeper dive into how **RBAC**, **ABAC**, and **ReBAC** can be implemented for multi-tenancy, focusing on what needs to be handled in code versus what can be centralized in a system. We’ll also touch on popular services like [Auth0 Organizations](https://auth0.com/organizations), [OPA](https://www.openpolicyagent.org/), and [Okta FGA](https://fga.dev/) to streamline your implementation.

## Role-Based Access Control (RBAC)

**Role-Based Access Control (RBAC)** is often the first choice for SaaS applications that have clear roles with distinct access privileges and is often the most familiar option among developers. It’s a straightforward model where users are assigned roles (e.g., admin, editor, viewer), and those roles come with specific permissions. In a multi-tenant environment, RBAC needs some enhancements to ensure roles are properly scoped to each tenant. This way, the users' permissions are restricted to their organization.

In a multi-tenant setup, RBAC handles tenant isolation primarily by scoping roles to individual tenants. This means that roles like “admin” or “viewer” are not globally applicable across the system but are assigned on a per-tenant basis. For instance, a user might be an “admin” in “Tenant A” but only a “viewer” in “Tenant B”.

To enforce this isolation, your application will need to ensure that roles are checked **within the tenant context** before allowing access to resources.

At the **code level**, this means ensuring that the application always verifies which tenant the user is operating under when making role-based decisions. For example, when a user tries to access a resource, the system should confirm whether their “admin” role applies to that specific tenant’s resources, not to another tenant’s resources.

> Notice that when using RBAC for authorization, a user under a certain role will get access to all the resources for that tenant. Other authorization models provide ways to scope the privileges of a user to specific resources within the tenant, and we’ll cover them later in the article.

There are simpler approaches to implementing RBAC into your application; for example, when using Auth0 for authentication, Auth0 offers an **Organizations** feature, which simplifies authentication and role assignments in multi-tenant environments. Auth0 Organizations allows you to easily manage users across multiple tenants (or organizations), where each user can be assigned roles specific to the organization they belong to. By using Auth0’s built-in support for multi-tenancy, you can delegate much of the tenant-specific role management to the identity provider, reducing the amount of tenant-scoped logic that needs to be hardcoded into your app.

### Example use cases for RBAC:

- **HR Management Platform**: In an HR platform used by multiple companies, each company (tenant) has its own set of roles, such as "HR Admin" and "Employee." When an HR Admin from Company A logs in, their permissions are limited to the records of Company A, while an HR Admin from Company B has access only to their company’s records.
- **AI-Powered Customer Support Tool**: A SaaS platform for AI-powered customer support allows companies to manage their support teams. Each team has a role structure, where the "Team Lead" has access to configure the AI responses, and the "Support Agent" can only see suggestions.

## Attribute-Based Access Control (ABAC)

ABAC allows you to define access control policies based on various attributes related to the user, resource, or environment. Unlike RBAC, which assigns static roles, ABAC dynamically evaluates attributes such as the user’s department, resource sensitivity, or even contextual factors like time and location. This makes ABAC more flexible for scenarios where access decisions depend on dynamic conditions.

In multi-tenant SaaS applications, ABAC can handle tenant isolation by including the tenant ID as an attribute in access control decisions. For instance, you can create policies that grant access to users based on their `tenantId`, `role`, and `department`. This allows for more granular control over what users from each tenant can access and when.

At the **code level**, the application needs to collect the relevant attributes (e.g., `tenantId`, `userRole`, `resourceSensitivity`) and pass them to the authorization engine for evaluation. The actual logic for determining whether access is allowed is centralized in the policy engine, reducing the need for complex, tenant-specific logic in your app.

There are some caveats, though; while ABAC allows for dynamic evaluation of the information, the relationships and structure of the information are hardcoded throughout the application, and if your attributes change, it may require code changes throughout the application. This is because the relationships between a user, its role, tenant, etc, are not inferred by the policy engine, but rather specified during authorization checks. For an inferred and more fine-grained approach, there’s a different authorization model which I will cover next.

For **system-level implementation**, ABAC policies can be managed using tools like **Open Policy Agent (OPA)** or a custom policy engine. These tools evaluate attributes dynamically, ensuring that access is granted only if all conditions are met. For multi-tenancy, this would include ensuring that users are only accessing resources within their tenant.
`

### Example use cases for ABAC:

- **AI-Driven Healthcare SaaS**: A hospital management system uses ABAC to grant access to patient records based on a doctor’s role, department, and the patient’s condition. Additionally, access is restricted to working hours.
- **AI-Powered Marketing Platform**: Marketing managers can access reports based on their role, the campaign they are working on, and the region of the campaign. ABAC policies check the region, `campaignType`, and `role` attributes to ensure the user is accessing data for their tenant’s campaigns only.

## **Relationship-Based Access Control (ReBAC)**

**Relationship-Based Access Control (ReBAC)** is ideal for SaaS applications where access control is based on complex relationships between users, resources, and organizations. Instead of simply granting permissions based on roles or attributes, ReBAC models relationships (e.g., "is the owner of," "can edit") and uses these to make access decisions. This is particularly useful for collaborative SaaS platforms where permissions are based on how users interact with resources.

> If your SaaS application handles user-generated content, you’ll likely benefit from a ReBAC model)

In multi-tenant ReBAC implementations, tenant isolation is enforced by defining relationships within and across tenants. For example, a user might "own" a resource within one tenant, and another user might have "edit" permissions for that resource based on their relationship. Unlike RBAC, which assigns roles based on predefined hierarchies, ReBAC focuses on how entities (users, resources, tenants) are related.

At the **code level**, your application doesn’t need to hard-code tenant checks. Instead, all access control decisions are based on querying the relationship graph, which models how users and resources are linked. This reduces complexity, as the app doesn’t need to maintain tenant-specific logic.

For **system-level implementation**, **OktaFGA** (or **OpenFGA**, based on Google Zanzibar’s model) provides a powerful platform for managing ReBAC at scale. OktaFGA stores and manages relationships in a graph database and allows your application to query these relationships in real time. You can model tenant-specific relationships and even handle cross-tenant scenarios, such as allowing external collaborators limited access to certain resources.

### Example use cases for ReBAC:

- **AI-Enhanced Document Collaboration Platform: In this multi-tenant SaaS, users can create, share, and edit documents within their tenant. ReBAC models relationships like "owner," "editor," and "viewer" for each document.**
- **AI-Powered Learning Management System**: A university (tenant) uses the platform to manage courses and student access. Students are "enrolled" in courses, and professors "teach" those courses. ReBAC models these relationships, ensuring that only enrolled students can access course materials. If a student transfers to a new university (tenant), their access is automatically updated based on their new relationships within the system.

## Summary

When it comes to building a multi-tenant SaaS application, your choice of authorization model determines how much of the access control logic is handled by your code versus the authorization system and how wide or fine grained the access control is over the resources of the tenants.

- **RBAC** requires tenant-specific role checks in your code, but tools like **Auth0 Organizations** can offload much of this complexity by managing roles and tenants externally.
- **ABAC** offers fine-grained, context-aware access control, where the system dynamically evaluates policies based on attributes like `tenantId` and `role`. Tools like **Open Policy Agent (OPA)** can centralize these decisions, reducing the need for custom code.
- **ReBAC** excels in scenarios with complex, dynamic relationships. Solutions like **OktaFGA** allow you to manage relationships at scale without embedding tenant-specific logic in your app. Instead, the relationship engine handles access control based on real-time relationships between users and resources.

By leveraging these models and tools, you can build a secure, scalable, and maintainable multi-tenant SaaS platform that fits your unique authorization needs.

Thanks for reading!

How to Choose the Right Authorization Model for Your Multi-Tenant SaaS Application

Calah Vargas

Calah Vargas is the Associate Manager of Product Led Growth, focusing on nonprofits, startups, and partnerships. She works on product marketing and customer marketing initiatives. Outside work, you can find her cooking, trying new restaurants, and traveling with friends and family.

Associate Manager, PLG

Upgrading made easy: from in-house authentication to modern login flows, flexible user profiles, and the convenience and security of passkey

Imagine you’re working on a monolithic application that includes a home-grown authentication system. Over the years, the authentication function has received upgrades here and there to improve security and to stay reasonably up-to-date in a changing world.

Sooner or later — perhaps triggered by considering different growth paths and how best to make use of developer time — you start to recognize that your in-house Identity stack is a limiting factor:

* Integrating with partners and other technology components requires custom work
* Maintenance obligations are distracting from work on your core app
* Meeting regulatory requirements for privacy is an ongoing challenge 
* Providing different access privileges to different types of end users is becoming more complicated than ever anticipated
* With every breach headline, you’re reminded of the constant need to strengthen security

Shopper Approved found themselves in a similar situation — in 2017, the company’s ambitions were outgrowing the home-grown Customer Identity capabilities of their monolithic PHP app.

With that realization, the search was for a third-party authentication solution.

# Why Shopper Approved chose Auth0 by Okta 

Since its launch in 2010, [Shopper Approved](https://www.shopperapproved.com/) has helped over 20,000 eCommerce brands — from mom-and-pop shops to global enterprises — generate more online trust, visibility, and conversions.

> “We knew we wanted to replace our login and authentication mechanism, and we needed a solution that would ‘tango’ with our [Laravel](https://laravel.com/) front-end templating engine,” Christopher Budge, Shopper Approved’s CTO recalled, “but we didn't know which direction we wanted to go in.”

<include src="QuoteCard" body="The Self-Service pricing was really attractive to us. The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While searching online for ideas and options, Budge came across Auth0 — and, in particular, the Self-Service plans.

> “The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application.”

The Self-Service option gave Budge and the wider team plenty of time to perform due diligence. “_We looked for a long time before ultimately deciding upon Auth0,_” he shared. “_The more I dug into it, the better it looked._”

The ability to explore the solution in a hands-on manner, without a commitment, helped the team to make an informed choice. Budge explained that:

<include src="QuoteCard" body="I got together with our technical lead and programming contractor, and they started playing with it — and then they said, 'Yeah, we think this is going to work." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While every organization’s Identity journey is unique, here’s how Shopper Approved implemented Auth0.

## Migrating Users from the Legacy System to Auth0	

No matter how much preparation is done, a migration is always a nervy thing. As it turns out, those nerves were unnecessary — Shopper Approved’s migration from their legacy, home-grown authentication system to Auth0 went off without a hitch.

Budge recalled, “_We weren't sure how well our system would adapt to having its old authentication system ripped out and something new put in its place, but the migration actually exceeded expectations. Within 24 hours, we were able to ingest our entire user database into Auth0 and have them set up as users able to log in._”

However, migrating users was simply the foundation for modernizing the experience for Shopper Approved’s customers, with Budge adding, “_The universal login allows for such a smooth application login and flow. And our marketing team has really appreciated the customization and branding options that allow us to deliver a better customer experience._”

### Letting quickstarts guide the way

One of the first things Budge’s team did was explore Auth0’s step-by-step [quickstart guides](https://auth0.com/docs/quickstarts) to get a feel for the overall migration process.

“The quickstart guides were dead easy. Plus, between your host documentation and the notes in GitHub, it’s really, really easy as a developer to figure out ‘where am I and where do I need to go?’” and ‘What’s next?’”

![quickstarts](https://images.ctfassets.net/23aumh6u8s0i/58lZcrqemW0dCDEIrlLxef/fd17a831afcbbe647abd73d3420e9d95/01-migration.png)

### Leveraging SDKs

SDKs reduce the developer effort required to implement specific use cases, and Budge’s team found exactly what they needed among Auth0’s 40+ SDK libraries.

“Your SDKs are written really well, and your APIs are documented really well. So, code-wise, it’s extremely easy to interact with the platform — you can get going and don’t really have to think hard about it.”

![SDKs](https://images.ctfassets.net/23aumh6u8s0i/1cSZQDXlQ1VDHD7RFG71vu/6922a4a4409f3bab6453b7b48f12541e/02-migration.png)

## Building User Profiles

User data can come from many sources, including your own databases as well as social, legal, and enterprise identity providers. Some examples include Google, Facebook, Active Directory, and SAML.

In Shopper Approved’s case, there was an added complication — practically every user profile that had ever been created in their system still existed, and collectively, many of these profiles had inconsistent and incomplete data. But, perhaps counterintuitively, the upgrade actually presented an opportunity to clean up the user database. Budge’s migration script identified existing user records that were poorly formatted, allowing the team to quickly correct any issues — ultimately improving the overall structure of the company’s user data and laying a strong foundation for efficient scalability.

“The way your user profiles are set up — they’re just really easy to understand, manipulate, and customize. The data structure was easy to map to what we had and what we needed.” Maybe even more importantly, Budge recalled that “It just worked. When we were playing around with it, we saw that it does exactly what [your documentation](https://auth0.com/docs/manage-users/user-accounts/user-profiles) says it does.”

![User Profiles](https://images.ctfassets.net/23aumh6u8s0i/3EfvAVkkj9Ornz9JcTH5CJ/1783bd310eb0cd0722dbbe754aa606c4/03-migration.png)

## Innovating With Identity: Exploring Passkeys

The Identity domain is always evolving, with new specifications, standards, and [regulatory requirements](https://auth0.com/security) frequently appearing.

Unsurprisingly, one of the reasons why Budge was so eager to introduce a leading off-the-shelf solution was that it would allow the company to keep pace with these changes — while at the same time allowing the team to apply their finite resources on their core value proposition. In short, he knew that choosing Auth0 meant that Shopper Approved’s CIAM needs would be met today, tomorrow, and as far into the future as he could imagine.

Like many CTOs, Budge had closely been following [passkeys](https://learnpasskeys.io/) — FIDO credentials that are discoverable by browsers or housed within native applications to enable — and was excited by their potential to provide [a highly secure and very convenient user authentication experience](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

> “I’ve been watching passkeys for a long time, and — literally the day I got [the announcement that they were available](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) — I jumped right in. We really enjoyed rolling them out early to our organization, and we’ve had zero issues. And it’s great that we didn’t have to build passkey support ourselves!”
> _Christopher Budge_

![Passkeys](https://images.ctfassets.net/23aumh6u8s0i/3qOGVNCBexcnp5LqxkAcNB/7a0c5eaa7bdb2cd37987795f7a504712/passkeys.png)

## Enjoying Ongoing Value

Budge’s hopes for lower support and maintenance obligations have come to fruition. “We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken.”

Similarly, the upgraded security is evident. 

> “We've had many security researchers and penetration testers try to break in. Every time they run smack-dab into Auth0.”

<include src="QuoteCard" body="We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

### Get started in minutes — for free — with no humans (other than yourself) required!

We’ve always tried to make things less complex for developers, which is why [our Self-Service plans](https://auth0.com/pricing) allow you to create a trial account with nothing more than an email address. During your 22-day trial period, you can create a simple app, configure its look and behavior, and explore the Auth0 solution in detail — giving you plenty of time to really get your hands dirty.

![Get started](https://images.ctfassets.net/23aumh6u8s0i/3s3e2u6XsF3BitzYgE3TpY/1097a71343e41a488444684c12c2c248/identity_journey.png)

Plus, anyone using our products can take advantage of resources including [quickstarts](https://auth0.com/docs/quickstarts), [40+ SDKs](https://auth0.com/docs/libraries), [detailed guides](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication), and [extensive (but easy-to-follow) documentation](https://auth0.com/docs/articles) to help get started and implement a strong Customer Identity function.

In fact, with only a few lines of code, you can have Auth0 integrated into any app, written in any language, and in any framework.

[Try for free](https://auth0.com/signup?utm_source=whitepaper&utm_medium=auth0&utm_campaign=whyauth0) and see for yourself.


A Customer Identity Migration Journey

Let’s find out how to add Auth0 authentication to the new Blazor application model introduced in .NET 8.

Add Auth0 Authentication to Blazor Web Apps

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby, Python, and Elixir.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Senior Developer Advocate

Carla Urrea Stabile

Learn which is the right authorization model for your application based on your use case.

Authorization is the process of verifying access to specific resources. In modern systems, using modern security workflows, an application can control what a user is authorized to do; this process is known as access control. 

In this post, you'll learn about access control and why you'll probably want to use an access control model to provide the structure and rules for deciding who can access what.  

Let's think of an example application like an *expense report management system* to walk you through the different access control models. In these types of systems, you want some users to be able to approve the expense reports submitted by other users. 

You start working on an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) for this project and want to iterate as the product evolves and grows. You decide to build it in Ruby On Rails because you are proficient in it. You have built your brand new expense app and are proud of it. It has all the features anyone needs: the ability to create a new expense report, update and delete reports, list and approve, and so on. **Now it's time to restrict who can do what, i.e., to build your authorization system.**

## First Step: Authentication 

You don't want just anyone to access your app and create expense reports or see the existing reports. You need to restrict access to your app to users who are authorized. Who are those users? Well, these are the users that your app recognizes as being authenticated.

If a user provides valid credentials (i.e., is authenticated), then they are authorized to access your app.

Often people [confuse the terms authentication and authorization](https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization), and the main reason is that **authentication is usually the first step in the authorization.** 

> Authentication is the process of verifying someone is who they say they are, and authorization is the process of verifying what they can and cannot access.

Only in very simple use cases is authentication enough to authorize users to use an application. For example, in your expense report app, using just authentication as the criteria for authorizing users leads to potential problems: any authenticated user can create, list, and approve reports. Presumably, this is different from what you want.

So how can you make sure only *some* users can perform operations on your reports? 🤔

## Using Roles

Your users can submit reports, but at this point, you might need a group of users in charge of approving them. It might be a case of defining an "expense approver" role. 

When you are defining your authorization model, and you realize you can **group your users based on their shared responsibilities, you are referring to [Role-Based Access Control (RBAC)](https://auth0.com/docs/manage-users/access-control/rbac).** This model offers a simple, manageable approach to access management that allows your app to determine what a user can or cannot do based on their specific responsibility, i.e., their role.

In Auth0, a [role](https://auth0.com/docs/manage-users/access-control/rbac#roles) is defined as a collection of operations that can be executed on a resource. In this case, you want to create an "expense approver" role to perform the *approve* operation on *expense reports*, which fulfills your current use case. Great! 🙌

At this point, your users can submit reports, and expense approvers can approve them. Although you haven't defined which users can see which reports, meaning **any user could see the report of another user.** 😩 

## Using Permissions

Roles have limitations in access control implementation; the more your application grows, the more complex it is to maintain the list of possible roles. Using RBAC alone can lead to role explosion, meaning you can end up having hundreds of roles to manage. So you decide to also implement permissions. 

> [A permission is a declaration of an action that can be executed on a resource](https://auth0.com/blog/permissions-privileges-and-scopes/#What-Are-Permissions). Permissions defined for an API in Auth0 can be used as part of the access control mechanism used by your application.  

Using permissions allows your application logic to no longer rely solely on roles for access control. Permissions allow you to define more granular access control, and Auth0 also allows you to add permissions to a role as a handy way to assign them to users en masse. 

In this case, you want permission that allows users to read expense reports only if they are expense approvers or the creators of such reports. To implement permissions, you need to add some logic in your application to define which reports a user can see. Let's break this down into two groups: the expense approvers and the rest of the users.  

What you want to achieve is that expense approvers can see all expense reports while the rest of the users can only see their own reports. For the expense approver use case, you can add the permission *read expense report*, say, to their role and define in your application logic that this implies all expense approvers can see all expense reports. So far, so good. The expense approver role still suffices for the use case 🙌.

For the rest of the users to see only their reports, they require the *read expense report* permission. Because they do not have the "expense approver" role, then your application logic can prevent them from reading any expense report except their own. The use of roles in conjunction with permissions allows your application to tell which report(s) the user can read and which they can't.

You could have a method that verifies if the user has the role of expense approver; otherwise, check against your relational database if the user is the submitter of the expense report. In ruby-like syntax, it would translate to something along the lines of: 

```ruby
def can_read_expense_report(user)

  return true if user.expense_approver?

  expenses = db.fetch(
    "SELECT expenses.id, users.user_id
     FROM expenses WHERE id = %
     JOIN users WHERE users.user_id = expenses.submitter_id")

  authorize!(user, :read, :expenses)
end
```

Another option is for you to use an external gem, like [CanCanCan](https://github.com/CanCanCommunity/cancancan) or [pundit](https://github.com/varvet/pundit). Implementation details are completely up to you and your application.    

At this point, each user can see the reports they have submitted, and there is an expense approver role that can see all reports and approve them. You show your application to your stakeholders, and they decide that now **expense approvers can only approve expenses of their direct reports** 😧

You take a deep breath 🧘 and start thinking this through...

## Using Attributes for Access Control

Let's assume that in your system, you know the direct reports of your users because your user entity has a `manager_id` attribute. 

**When you define an authorization system that evaluates attributes (or characteristics), you are using [Attribute-Based Access Control (ABAC)](https://www.okta.com/blog/2020/09/attribute-based-access-control-abac/).** The purpose of ABAC is to protect objects from unauthorized users and actions — those that don't have "approved" characteristics as defined by an organization's security policies.  

In your case, your security policy will be as follows: 

> If user A is the manager of user B, then user A can approve an expense report from user B

Then, in your application code, you have to define the method that executes this policy. Let's say you have this information available in your relational database, and you can run a query to get the expenses of a user and, if they are the manager of the submitter user, approve the expense. A way to do this in *ruby-like (more like pseudo-code)* syntax, similar to what you did with your implementation of permissions, would be:

```ruby
def approve_expense(user)
  expense = db.fetch(
    "SELECT expenses.*, users.manager_id as submitter_manager_id
     FROM expenses WHERE id = %
     JOIN users WHERE users.user_id = expenses.submitter_id")

  authorize!(user, :approve, :expense)
end
```

The code above is similar to the one you wrote when implementing permissions. The key difference is that you are basing your `approve_expense` method and policy on the attributes of an object, in this case, the user. As you see, ABAC, RBAC, and permissions can all be used together. 💡

The `approve_expense` method works pretty great with your application 🥳 so you think of ways to optimize it and make it scalable. In a small organization with only one level of management, your authorization system works well, but when you take it to a bigger organization with multiple levels of management, you realize your solution can cause performance and maintenance issues. 🤔

The above code is **embedding authorization logic in your application code**, making it difficult to understand how authorization is implemented in the system without looking at the source code.

Also, if there are any **changes in your authorization policy, it will require you to change your application code.**

Lastly, every time you need to approve or verify if a user can read an expense report, you are hitting your operational databases, adding more load to those databases and therefore **adding latency to your requests.** 

You see, there is a clear relationship between the expense approver, the submitter, and the expense report; the attribute of being a manager works but adds complexity you don't need, so you decide to take a step back and re-think your implementation.

## I Need to Grant Access Based on Relationships

You were on the right track when you modeled your authorization system based on the user's attributes and the object you're trying to access. But that solution didn't work so well when management changed their mind and the application needed to grow 🙄 So now you decide that instead of using attributes, **it makes more sense to work based on the user's relationships with each other and the expense report too**. And the good news is that there is an authorization model out there that can help you do just that!

**[Relationship-Based Access Control (ReBAC)](https://docs.fga.dev/intro/authorization-and-auth0-fga#what-is-relationship-based-access-control-rebac) allows you to express rules based on relations that users have with objects and that objects have with other objects, providing a more expressive authorization model that can describe very complex contexts.** An example of where you find this authorization model is a social media app, where users can control who has access to their profile or information based on their relationship with other users. 

ReBAC is an example of a model that will typically offer you the most flexibility; models with a high degree of flexibility are often referred to using the term [Fine-Graned Authorization (FGA)](https://docs.fga.dev/intro/authorization-and-auth0-fga#what-is-fine-grained-authorization-fga). At scale, a system could have millions of objects, users, and relations with a high change rate, meaning that objects are regularly added, and access permissions are constantly being updated. An example is Google Drive, where you can grant access to documents or folders and where access can be granted to users individually or as a group. Access regularly changes as new documents are created and shared with specific users, whether inside the same company or without.

A Fine-Grained Authorization model sounds exactly like what you need for your use case 🤩. But wait. Surely something like this will be complex to build, right? Well, yes, it is. However, the good news is that we've already done it for you! [Auth0 FGA](https://auth0.com/developers/lab/fine-grained-authorization) provides an easy solution and offers a way to define your authorization model and relationships between a user and a report using something like the following:

```python
type report
  relations
    define approver: can_manage from submitter
    define submitter: [user]
type user
  relations
    define can_manage: manager or can_manage from manager
    define manager: [user]
```

With this model, you are stating the `manager` relationship between users and that the manager of the submitter is the only one who can approve a report by using the `can_manage` relation.

If you want to check if a user is a manager of another user in the management hierarchy, you could use the [Auth0 FGA Check API](https://docs.fga.dev/api/service#/Relationship%20Queries/Check). In Ruby, it'd look as follows: 


```ruby
require "uri"
require "json"
require "net/http"

FGA_API_URL="YOUR_FGA_API_URL"
FGA_BEARER_TOKEN="YOUR_BEARER_TOKEN"
FGA_STORE_ID="YOUR_STORE_ID"

url = URI("#{FGA_API_URL}/stores/#{FGA_STORE_ID}/check")

http = Net::HTTP.new(url.host, url.port);
http.use_ssl = true

request = Net::HTTP::Post.new(url)
request["Authorization"] = "Bearer #{FGA_BEARER_TOKEN}"
request["content-type"] = "application/json"
request.body = JSON.dump({
  "tuple_key": {
    "user": "user:alex",
    "relation": "can_manage",
    "object": "user:sam"
  }
})

response = http.request(request)
puts response.read_body

# Response: {"allowed":true,"resolution":""}
```

<div class= "alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>You can check out the <a href= "https://play.fga.dev/sandbox/?store=expenses">Auth0 FGA Playground</a> for more info about this concrete example as well as other useful examples for you to learn more about FGA.</strong>
</div>

Some advantages of using a third-party service like Auth0 FGA to manage your authorization system is that you remove the authorization logic from your application code and make sure all your policies are in one place, making it easier to maintain. You also minimize the latency in your requests because Auth0 FGA is optimized for reliability and low latency at a high scale, and in your specific case, you'll reduce latency even more because you won't be hitting your database every time you want to check if a user can approve an expense report. 

When you finish implementing your authorization model, you go back to your stakeholders and show them your progress; they are thrilled! 🥳 They like the progress you've made. Still, now they decided they want to have a [git-like](https://git-scm.com/) system where you can have multiple versions of the same report, branches, and teams, and you take another deep breath 🧘 and proceed to explain that this will move the initial deadline, and so the drama continues...

<include src="SmallBannerCTA" text="Want to take your Authorization to the next level? → " linkText="fga.dev" link="https://a0.to/oktafga_blog" imgLink="https://cdn.auth0.com/website/blog/banners/fga.png" imgAlt="Okta FGA Logo" />

## Conclusion 

Authorization models give you the structure and rules for deciding who can access what in your application. Depending on your use case, one model can be better than another. Or you may end up using multiple models to serve your needs, depending on the complexity of your use case. 

You almost always want to have authentication in your system, but it's usually not enough for users to be authenticated to verify if they have access to a resource or not. A Role-Based Access Control (RBAC) model might be enough for simple applications, especially if you have a few roles. However, the more granularity you want in your access control model, you might consider using permissions and assigning them to users regardless of their roles. You might define the access control based on some of your user's attributes, for example, by implementing ABAC, or you can restrict access to resources based on your object relationships using ReBAC. Whatever your requirement is, Auth0 and Auth0 FGA offer you a solution that can be used to address your authorization needs at scale in a progressive manner.

What's the Right Authorization Model for My Application?

Learn how to use roles in your Blazor Server and WebAssembly applications to implement the RBAC authorization model.

Role-Based Access Control in Blazor Applications

sandrino-di-mattia

Principal Architect

Sandrino Di Mattia

Learn how (and where) to authenticate your user in the different deployment models that exist for Next.js

The Ultimate Guide to Next.js Authentication with Auth0

manfred

Under the leadership of Manfred Steyer, ANGULARarchitects.io supports companies with the implementation of web-based business applications with Angular. <br>
 
At the Angular seminars he designs, he combined his profound knowledge of Angular, for which he was recognized by Google as a Google Development Expert (GDE), with his experience, which he worked as a team leader in the field of software development, as a Professor at a university of applied sciences and as an external member of the Angular team. <br>
 
Manfred has published books at O'Reilly, Microsoft Press, and Hanser and writes for Heise Online, windows.developer, and the Java magazine. He also regularly shares his knowledge at conferences.

Trainer and Consultant with focus on Angular

Manfred Steyer

Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

**TL;DR:** Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

## Micro Frontends

Recently, there have been a lot of discussions about Micro Frontends. The underlying idea is quite tempting: Splitting a huge software system into smaller parts and assigning each part to an individual team:

![Each micro frontend can be developed by an autarkic team](https://images.ctfassets.net/23aumh6u8s0i/38DpehwkPwiMTNBOvOQowG/ce345e71277e19f211f23add38a0ae4e/microfrontends.png)

As these teams are -- more or less -- autonomous, they can work in a more flexible way and don't need to coordinate that much with others. This shows that Micro Frontends are mostly about scaling teams. Hence, if you don't have several frontend teams, Micro Frontends might be overkill. 

## Module Federation

Splitting software systems into several parts is, however, only one side of the coin. Even though we developers might like this idea, the users don't! They aren't interested in starting several frontends but expect an integrated solution. 

Accordingly, we need to find a way to make all our micro frontends appear as one (single page) application. Very often, this involves loading micro frontends into a shell application.

For instance, the example used here mimics a simple shopping system. One of its micro frontends deals with shipping:

![Example micro frontend dealing with shipping products](https://images.ctfassets.net/23aumh6u8s0i/3Zs0it0naO2U4W1GwBMpNn/caa76eb2a246ab2dfa5d5394c6ed89c5/example-shipping.png)

For the purpose of integration, this micro frontend needs to be loaded into a shell:

![Example of a shell loading the shipping micro frontend](https://images.ctfassets.net/23aumh6u8s0i/iJOA5Lg4AHYGHBt0SK06U/8bdb25c11b8ac571f259f57217ff72eb/example-shipping-in-shell.png)

The shell loads this but also other micro frontends on demand.

For such an implementation, you needed a lot of tricks in the past. Fortunately, Module Federation makes this task straightforward. 

Module Federation is an integrated part of webpack 5, and hence, it works with all modern web frameworks. Also, as webpack is highly used in nearly all communities, Module Federation immediately becomes a widespread solution.

In order to allow loading separately compiled and deployed micro frontends, Module Federation defines two roles: the host and the remote:

![Schematic representation of Module Federation](https://images.ctfassets.net/23aumh6u8s0i/6RTBbIScEwfnZm97MMe7nJ/2138d86c99a988b286f9852d020097a4/module-federation.png)

In our case, the host is the shell, while the remote is the micro frontend. Both can be configured with their webpack configurations. 

The host defines virtual URLs pointing to remotes. In the previous picture, for instance, the URL ``mfe1`` pointing to a micro frontend, also called ``mfe1``, is defined.

The remote, in turn, exposes files -- or, to be more precise: EcmaScript modules -- for the host. To prevent that, the latter one needs to know the remote's file structure; exposed files can get a shorter alias. The example in the last picture goes with the alias ``Cmp``. 

Exposed EcmaScript modules can easily be loaded into the host by using a dynamic ``import`` together with the mapped URLs and defined aliases. The best: From Angular's perspective, this is just like lazy loading. 

As Angular doesn't even recognize that the application loads a micro frontend, we can use it exactly as it was intended to be used. We don't need any tricks or meta frameworks orchestrating different SPAs in our browser window. This eases our endeavor dramatically.

## Module Federation in Angular

Since version 12, the Angular CLI uses webpack 5. Hence, we also get Module Federation out of the box. To activate it, we need a custom builder that, e. g. ships with the community solution ``@angular-architects/module-federation``. As it comes with respective schematics, you can easily ``ng add`` it to your CLI workspace:

```bash
ng add @angular-architects/module-federation
```

![Adding @angular-architects/module-federation to your project](https://images.ctfassets.net/23aumh6u8s0i/3eoqQDVCE5OK0QfzoYmXt8/378fda04d26bd28ffc798754f3150819/ng-add.png)

The well-known CLI extension [Nx](https://nx.dev/) is supported too. The schematic asks about the name of the project in your workspace you want to enable module federation for. Also, it asks which port to assign for ``ng serve``.

After that, it generates several files, e. g. a partial webpack configuration we need to adjust for our needs. Also, it registers the custom builder in our ``angular.json``.

For the example used here, I ran this command twice: Once for the shell and once for the above-shown shipping micro frontend. The latter one is just called ``mfe1`` here.

## Configuring the Micro Frontends

Now, we need to adjust the webpack configurations generated for the shell and the micro frontend. As the Angular CLI is generating most parts of the webpack configuration, we just need to define the remaining details for the module federation. First and foremost, this is about configuring the ``ModuleFederationPlugin`` that ships with webpack.

Let's start with the configuration for the micro frontend:

```javascript
// projects/mfe1/webpack.config.js

[...]
plugins: [

  new ModuleFederationPlugin({
    
      // For remotes (please adjust)
      name: "mfe1",
      filename: "remoteEntry.js",
      exposes: {
          './AddressModule': './projects/mfe1/src/app/address/address.module.ts',
      },        
      
      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true },

        ...sharedMappings.getDescriptors()
      })
          
  }),
],
[...]
```

The property ``name`` is normally the project name and should be unique across all micro frontends. The ``filename`` points to a file webpack generates when building the project. It's often referred to as the remote entry point. This JavaScript file provides all the metadata the shell needs to know for loading the micro frontend.

While normally you can go with the generated values for ``name`` and ``filename``, you very likely need to adjust the ``exposes`` section. As discussed above, it contains the aliases for the files to expose.

With ``shared``, you define all the npm packages you want to share across the shell and the micro frontends. These packages are only loaded once at runtime. This is vital because having ten micro frontends doesn't mean you want to load Angular or other packages ten times!

Of course, when sharing packages at runtime, we might end up with version conflicts. Fortunately, Module Federation also got us covered here: It provides several strategies for dealing with version mismatches. 

In our case, the combination of ``singleton: true`` and ``strictVersion: true`` is used. Hence, only one version of the shared packages is allowed, and if Module Federation detects several versions at runtime, it throws an Error. While this seems to be quite harsh at first sight, it allows our integration tests to immediately find out about version mismatches.

More details on [strategies for preventing version mismatches](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/) can be found [here](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/).

Besides ``singleton`` and ``strictVersions``, there are two further properties used: ``requiredVersion`` and ``includeSecondaries``. If we set the first one to ``auto``, ``@angular-architects/module-federation`` assumes the version found in your project's ``package.json``. This avoids several [pitfalls](https://www.angulararchitects.io/aktuelles/pitfalls-with-module-federation-and-angular/). 

The option ``includeSecondaries`` is provided by ``@angular-architects/module-federation`` too. It automatically adds all secondary entry points to the list of shared libraries. In the case of libraries like Angular Material, this saves you a lot of typing as they provide one such entry point per component, e. g. ``@angular/material/input`` or ``@angular/material/button``.

Now, let's have a look at the exposed ``AddressModule``: 

```typescript
// projects/mfe1/src/app/address/address.module.ts

[...]

@NgModule({
  imports: [
    [...]
    RouterModule.forChild([{
      path: 'address', 
      component: AddressComponent
    }])  
  ],
  declarations: [
    AddressComponent
  ],
})
export class AddressModule { }
```

As you see, it's just an ordinary Angular module. However, as it has child routes, we can immediately route to them after loading the whole module into the shell. 

## Configuring the Shell

The shell's ``webpack.config.js`` is a bit simpler. Here, we only need to define the shared libraries:

```javascript
// projects/shell/webpack.config.js

[...]
plugins: [
  new ModuleFederationPlugin({

      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true }

        ...sharedMappings.getDescriptors()
      })
      
  }),
],
[...]
```

In addition, we also could map URLs here, as outlined above. This would look like this:

```typescript
// Alternative that maps URLs upfront
new ModuleFederationPlugin({
  remotes: {
    "mfe1": "mfe1@http://localhost:3000/remoteEntry.js"
  },
  [...]
})
```

The key is the mapped URL, and the value defines the name of the micro frontend as defined in its ``webpack.config.js``. Here, the value also contains the location of the micro frontend's remote entry point. To load ``mfe1``'s exposed Module, we could use a dynamic ``import``:

```typescript
// Using mapped URL:
import('mfe1/AddressModule')
```

As the TypeScript compiler doesn't know the file ``mfe1/Module``, we also needed a type definition. For this, we could create an arbitrary with the ending ``.d.ts``:

```typescript
declare module "mfe1/AddressModule";
```

However, while mapping URLs this way is simple, it also requires us to know about the micro frontends and their locations upfront. Hence, I'm using a more dynamic approach that does not demand us to define URLs for compile time. 

Instead, we can tell Module Federation about possible Micro Frontends at runtime. To make use of it, I use the helper function ``loadRemoteModule`` provided by ``@angular-architects/module-federation`` together with lazy routes:

```typescript
// projects/shell/src/app/app.module.ts

[...]
RouterModule.forRoot([
  {
    path: '',
    component: HomeComponent
  },
  {
    path: 'mfe1',
    loadChildren: () => loadRemoteModule({
      remoteEntry: 'http://localhost:3000/remoteEntry.js',
      remoteName: 'mfe1',
      exposedModule: './AddressModule',
    }).then(m => m.AddressModule)
  }
])
[...]
```

The ``loadRemoteModule`` function takes the location of the remote entry point, the remote's name, and the alias of the exposed EcmaScript module. All these values are defined in the micro frontend's webpack configuration. 

As these properties are just strings, we could even retrieve their values from a configuration file or from a service endpoint.

## Trying It Out

After starting both projects, e. g. with ``ng serve shell, `` and ``ng serve mfe1``, we can use the lazy route shown above to load the micro frontend into the shell. It's also interesting to inspect the loaded files in your browser's dev tools:

![The browser loads the shared libraries](https://images.ctfassets.net/23aumh6u8s0i/5YzAFolOzvMYTspPsgZ5Wb/73d1fb9772e1128fca2eca404a1aa0ce/share.png)

At first sight, it really looks like lazy loading. However, when looking more closely, we see that the lazy chunks come from the micro frontend's origin. Also, for all the shared libraries, a bundle of its own is loaded. This is necessary because the module federation decides at runtime when to load which shared package. 

## Authentication for Micro Frontends

Sometimes we need to share some information between micro frontends and the shell, e. g. context information like the current user or global filters like the selected customer. The example used here allows logging in the user via the shell:

![Logging in the current user](https://images.ctfassets.net/23aumh6u8s0i/2XumqnUE2Cp56cB0nWJt2w/37480acbfca69c8036e36d38b94fbcd2/logged-in.png)

However, when loading the micro frontend on demand, it also knows about the current user:

![Sharing information about the logged in user](https://images.ctfassets.net/23aumh6u8s0i/2BdJ84YhuAxliC349B9A2Q/6294f33fd3d8b940789da984d41efe8c/logged-in-shipping.png)

To achieve this, we just need to share a package that holds the information to share. In our case, this is ``@auth0/auth0-angular`` as we are using Auth0 as our identity provider. It's available via npm:

```bash
npm i @auth0/auth0-angular
```

To make this work, I've configured a web application at https://manage.auth0.com/. If you want to try this out, don't forget to register your SPA's URL, e. g. http://localhost:4200, under _Allowed Callback URLs_. Besides this, I went with the default values proposed by the web portal.

To get started, we need to import the ``AuthModule`` provided by ``@auth0/auth0-angular`` into the ``shell``'s but also into ``mfe1``'s ``AppModule``:

```typescript
// projects/shell/src/app/app.module.ts
//  and
// projects/mfe1/src/app/app.module.ts

[...]

import { AuthModule } from '@auth0/auth0-angular';

[...]

@NgModule({
  imports: [
    AuthModule.forRoot({
      domain: 'dev-ha-6vf7s.us.auth0.com',
      clientId: 'pQXuZGn3bfOfHpFd9ch7Wfa4xP4KhKlS'
    }),
    [...]
  ],
  [...]
})
export class AppModule { }
```

The values for ``domain`` and ``clientId`` can be found at https://manage.auth0.com after registering your application.

After that, we can use the ``AuthService`` in the shell to login the current user:

```typescript
// projects/shell/src/app/home/home.component.ts

import { Component } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.scss']
})
export class HomeComponent {

  user$ = this.auth.user$;

  constructor(private auth: AuthService) {}

  login(): void {
    this.auth.loginWithRedirect();
  }

}
```

I also decided to display the user's name after they logged in:  

```html


<h1>Welcome!</h1>

<p *ngIf="user$ | async as user">
    User: {{user.name}}
</p>

<div>
    <button (click)="login()" mat-flat-button color="primary">Login</button>
</div>
```

In the micro frontend's ``AddressComponent``, I'm also using the ``AuthService`` to get some information about the current user:

```typescript
// projects/mfe1/src/app/address/address.component.ts

[...]

import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-address',
  templateUrl: './address.component.html',
  styleUrls: ['./address.component.scss']
})
export class AddressComponent {

  [...]

  constructor(
    private auth: AuthService,
    private fb: FormBuilder) {

    this.auth.user$.pipe(take(1)).subscribe(user => {
      if (!user) return;
      this.addressForm.controls['firstName'].setValue(user.given_name);
      this.addressForm.controls['lastName'].setValue(user.family_name);

    });

  }

  [...]
}
```

In order to make this work, we need to share the ``@auth0/auth0-angular`` package:

```javascript
// projects/shell/webpack.config.js
//  AND
// projects/mfe1/webpack.config.js

[...]
shared: share({
  [...]
  
  // Add this:
  "@auth0/auth0-angular": { singleton: true, strictVersion: true, requiredVersion: 'auto' },

  ...sharedMappings.getDescriptors()
})
[...]
```

This ensures there is only one ``AuthService`` at runtime we can use to share information about the current user. 

After changing the webpack configuration, we need to restart our applications. If everything works well, we can log in the user via the shell and read the user's name in the lazy loaded micro frontend.

## Summary

Module Federation allows loading separately compiled applications at runtime. Also, we can share common dependencies. This also allows sharing common data like information on the current user or global filters.

As Module Federation allows runtime integration, it is also the key for plugin systems and micro frontend architectures. However, this approach turns to compile-time dependencies into runtime dependencies; we need a sound set of integration tests to detect issues. 

In general, Micro Frontends only makes sense if you want to scale a project by splitting it into several smaller applications developed by different autarkic teams. If you only have one frontend team, Micro Frontend architectures are very likely an overhead.

Micro Frontends with Angular, Module Federation, and Auth0

anthony-herbert

Anthony makes tutorials on his <a target='_blank' rel='noopener noreferrer' href='https://www.youtube.com/c/prettyprintedtutorials'>YouTube channel Pretty Printed</a>. He focuses primarily on Python web development, but he has broad interest in programming of all forms. Outside of writing code, he enjoys strength training and travel.

Founder of Pretty Printed

Anthony Herbert

Learn how to create a Django public feed application, add authentication, and moderate posts.

Django Authentication Tutorial

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New feature removes the need for passwords and offers unique progressive enrollment features, paving the way for the ultimate user experience.


**BELLEVUE, Wash. – June 15, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of [Auth0 WebAuthn Passwordless](https://auth0.com/passwordless), an authentication feature that enables end-users to seamlessly log in with a biometric identifier — such as facial recognition or a fingerprint — as a convenient and secure alternative to a traditional password. Removing the need for long, complex passwords, Auth0 WebAuthn Passwordless provides a frictionless experience for end-users while reducing the significant password management burden for companies. 

<include src="WebAuthnMeCTA" group="B"/>

Today’s abundance of applications and systems have never had more access points, leaving organizations and their end-users vulnerable to attacks. A reliance on passwords as a primary means of authentication, combined with users’ tendency to re-use passwords across applications, presents a number of security, user experience, and cost issues. According to a [2021 Data Breach Investigations Report by Verizon](https://www.verizon.com/business/resources/reports/dbir/), compromised passwords are responsible for 84% of breaches. Passwordless authentication mitigates these challenges and offers increased security and trust for applications, devices, and services providers; faster and smoother login experiences for their end-users; and cost savings by eliminating the need for password management support. 

“Despite ongoing guidance around proper password creation and repeated warnings against password reuse, consumers crave convenience and continue to use the easiest and most convenient path for application access,” said Shiv Ramji, Chief Product Officer at Auth0. “A passwordless future is largely being driven by two primary forces — security and convenience. Companies want to secure the vulnerabilities that come with passwords, and they also want to offer their users a better digital experience. Auth0 WebAuthn Passwordless is a modern option for organizations looking to attract and retain users.”

With Auth0 WebAuthn Passwordless, users can authenticate with Web Authentication-powered (WebAuthn) biometrics, the official web standard for passwordless authentication as published by [W3C and used by FIDO](https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/), for first-factor authentication. This form of authentication eliminates security weaknesses based on password reuse since passwords are not required. Additionally, Auth0 WebAuthn Passwordless is an ideal option for companies looking to build and provide an authentication experience supporting conversion and retention of users who want more choice and less friction in their login experience.

Auth0 WebAuthn Passwordless eliminates the need for users to enter username and password credentials and enables simpler login with a biometric identifier such as facial recognition like Apple Face ID or a fingerprint scan on a mobile device or laptop. The biometric data remains stored on the device, alleviating privacy and security concerns for end-users. The feature also allows end-users to progressively enroll devices one at a time, as they use them, without needing a centralized portal, giving them the flexibility of having multiple passwordless authentication options — an advanced, unique capability that maximizes end-user adoption and enables a faster transition from passwords to passwordless, benefiting both end-users and organizations.

More detailed information on Auth0 WebAuthn Passwordless can be found here: [7 Things You Need to Know About Passwordless Authentication](https://auth0.com/resources/whitepapers/passwordless-authentication) (whitepaper) and on [Auth0’s blog](https://auth0.com/blog/freedom-from-passwords-with-auth0-webauthn-passwordless). 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit [The Auth0 Identity Platform](https://auth0.com/identity-os) to learn more.


<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications<br />
Auth0 <br />
[press@auth0.com](mailto:press@auth0.com)<br />

Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />

Auth0 WebAuthn Passwordless Offers New Levels of Ease and Security for Modern Authentication

bruno-krebs

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

R&D Content Architect

Bruno Krebs

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



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

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

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

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

## The Contents of the OpenID Connect Handbook

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

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

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

## Introduction

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

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

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

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

## OpenID Connect Introduction

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

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

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

## OpenID Connect in Action

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

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

## OpenID Connect and Traditional Web Applications

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

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

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

## Traditional Web Apps and the Delegated Authorization Flow

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

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

## OpenID Connect and Single-Page Applications

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

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

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

## Conclusion

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

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

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

<include src="asides/AboutAuth0" />


The OpenID Connect Handbook

chris-adriaensen

Chris is a Lead Solutions Engineer at Auth0 and has been in the digital identity industry for about 10 years. He works with clients to build successful and trusted solutions using Auth0's platform. Prior to joining Auth0, Chris was a Solution Architect at ForgeRock, as well as Verizon, where he worked on various strategic identity projects.

Lead Solutions Engineer

Chris Adriaensen

A look at four different authorization models to map users to the correct permission



> EDITOR’S NOTE: Welcome to the EMEA Blog Takeover, where our EMEA employees take over the Auth0 blog to share success stories from the region. This week, you’ll meet our thought leaders across the pond, discover some of our most compelling use cases, and read about the trends that influence how we do business.

## The Scene

Online media includes a vast world of mostly free and some exclusive paid content, consumed through a plethora of devices. We read the news and listen to music on our phones or smart assistants, skim articles and books on our tablets, and watch movies on our laptops or TVs. More and more, the shape of our devices is changing — from hand-held and large-screen TVs to standalone speakers and connected cars.

In the highly-competitive world of media, understanding the consumer can make the difference between going under or keeping your head above the water. Users need to be able to find media on their devices and consume it at the time they prefer. Keeping the user engaged by offering additional media choices builds loyalty and increases consumption, making room for additional revenue streams.

<include src="TweetQuote" quoteText="The shape of our devices is changing — from hand-held and large-screen TVs to standalone speakers and connected cars."/>

Understanding the consumer’s [social graph](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Social_graph&sa=D&ust=1559296160314000&usg=AFQjCNETRz-kST9SoFHeZgzwLticknD59A) can provide a competitive edge, as it allows media providers to differentiate between different consumers sharing a subscription. This is critical to avoid mixing up personalization efforts, while correctly tailoring media access and subscription usage according to a user’s location, role, and age (e.g. restricting content for younger audiences). Knowing how the consumer relates to others in their network also helps to provide more relevant media recommendations.

Many established media providers are still grappling with [digital transformation](https://auth0.com/blog/solving-5-media-industry-challenges-with-auth0-identity-solutions/). While there are innovative ways to design a [paywall strategy](https://auth0.com/blog/the-role-of-ciam-in-implementing-a-sound-paywall-strategy/), paywalls can be challenging as content has increasingly become abundant and often free. A frictionless consumer onboarding process with a low barrier to entry is key, as well as an outstanding initial, and continued, digital customer experience. For this you need a minimal amount of effort needed to setup an account as well as a low commercial threshold, such as a 1-month free or low-entry monthly subscription.

Lots of providers today merely focus on a subscriber account, and perhaps attach some profiles, missing out on truly understanding their consumers. We all know how subscriptions are shared — even with attached profiles it doesn’t provide good separation — and consumers get annoyed when personalisation engines get confused. Furthermore, children grow up, employees move companies, users can become full-blown subscribers themselves, people move across countries … starting with a blank digital profile is painful for all parties involved.

<include src="TweetQuote" quoteText="A frictionless consumer onboarding process with a low barrier to entry is key."/>

## Authorization Models

As we’ve discussed, it’s important for every user to have his or her own account, or data gets mixed and becomes useless very quickly. Let’s imagine a simple traditional family setup: **mom** and **dad** manage the subscription (`1234`), also used by two children, an adult (`child_adult`), and a minor (`child_minor`). We also have a partner of the oldest child using the subscription (`partner_child_adult`). All of them have seperate accounts and we assume they can be recognized seamlessly by all the devices. We’re going to focus on how users are mapped to permissions, i.e. the authorization model used.

> **Note:** The examples below are simplified for illustrative purposes. Please reference the linked documentation for more information about the specific features can be used to implement these models.

## Discretionary Access Control (DAC)

In a DAC model, all permissions are assigned directly to users, so the model is basically a direct mapping between users and permissions. It holds little information as to why permissions are assigned they way they are, and hence makes it extremely inflexible and hard to manage. In our family example we have five permissions, administration of the subscription (`sub_admin`), access to minor-approved content (`content_minor`), access to High Definition streaming any content (`content_hd`), access to content for 18 years of age or older (`content_adult`), and access to admin-only content (`content_admin`). 

![Discretionary Access Control](https://images.ctfassets.net/23aumh6u8s0i/7kn3G5wVhONPOg2SyKCbZA/b2b348844ef44f90f79bc0ded46a22d1/dac)

Our example using DAC:

```javascript
// RULES: DAC
// set subscription
context.accessToken[`subscription`] = user.subscription;
	
// collect permissions
for (permission in user.permissions) context.accessToken.scope.push(permission);

// USER: MOM
“subscription”: 1234,
“permissions”: [“sub_admin”, “content_minor”, “content_hd”, “content_adult”, “content_admin”]

// USER: DAD
“subscription”: 1234,
“permissions”: [“content_minor”, “content_hd”, “content_adult”]

// USER: CHILD (ADULT)
“subscription”: 1234,
“permissions”: [“content_minor”, “content_hd”, “content_adult”]

// USER: CHILD (MINOR)
“subscription”: 1234,
“permissions”: [“content_minor”, “content_hd”]

// USER: PARTNER (CHILD ADULT)
“subscription”: 1234,
“permissions”: [“content_minor”, “content_adult”]
```

The amount of static decisions to make in this DAC model would be:

```javascript
complexity_dac = users * (subscriptions + permissions)
[users: 10.000, subscriptions: 5.000 & permissions: 5 => 50.050.000]
```

When faced with an extremely small number of users, subscriptions, and permissions, it might still be manageable. At Auth0, we provide support for DAC by [allowing permissions to be stored directly in the user’s account](https://auth0.com/docs/users/concepts/overview-user-metadata) in the `metadata` fields, which can store generic JSON information.

## Role-Based Access Control (RBAC)

In an RBAC model, an abstraction layer is introduced using the concept of roles or groups. Each role or group can be attached to multiple users on one side and multiple permissions on the other side. In other words, instead of having permissions directly assigned to users, they’re now assigned to roles, which in turn get assigned to users.

![Role-Based Access Control](https://images.ctfassets.net/23aumh6u8s0i/23aOZR4SybM4AtiLhtF6aY/e275fd5129f75e6afaf986754aea8c77/rbac)

Our example using RBAC:

```javascript
// RULES: RBAC
// set subscription
context.accessToken[`subscription`] = user.subscription;

// collect roles and permissions
for (role in user.roles)
	for (permission in role.permissions) context.accessToken.scope.push(permission);
	
// ROLE: ADMIN
“permissions”: [“sub_admin”, “content_admin”]

// ROLE: FAMILY (MINOR)
“permissions”: [“content”, “content_hd”]

// ROLE: FAMILY (ADULT)
“permissions”: [“content”, “content_hd”, “content_adult”]

// ROLE: FAMILY (EXTERNAL)
“permissions”: [“content”, “content_adult”]

// USER: MOM
“subscription”: 1234,
“roles”: [“admin”, “family_adult”]

// USER: DAD
“subscription”: 1234,
“roles”: [“family_adult”]

// USER: CHILD (ADULT)
“subscription”: 1234,
“roles”: [“family_adult”]

// USER: CHILD (MINOR)
“subscription”: 1234,
“roles”: [“family_minor”]

// USER: PARTNER (CHILD ADULT)
“subscription”: 1234,
“roles”: [“family_external”]
```

The amount of static decisions to make in this RBAC model would be:

```javascript
complexity_rbac = users * (subscriptions + roles) + roles * permissions
[users: 10.000, subscriptions: 5.000, roles: 4 & permissions: 5 => 50.040.020]
```

When there are significantly fewer roles than permissions, it can vastly reduce the complexity. With Auth0, RBAC can be implemented through the use of [roles](https://auth0.com/docs/authorization/guides/manage-roles) — permissions can be assigned to roles and roles to users in a static way, either using the Administrator UI or the Management API.

## Attribute-Based Access Control (ABAC)

In an ABAC model, policies are introduced that can dynamically determine how permissions are assigned to users based on attributes of the user, but also whatever information is available to the policy engine (like request or context information). 

![Attribute-Based Access Control](https://images.ctfassets.net/23aumh6u8s0i/6rUta5WyLMmZSoL4Q7pxM6/33a1a814369958b0df2121b70e5c7a5a/abac)

Our example using ABAC:

```javascript
// RULES: ABAC
// set subscription
context.accessToken[`subscription`] = user.subscription;

// check if admin and add permissions
if (user.admin) context.accessToken.scope.push(["sub_admin", "content_admin"]);

// check if family and add permissions
if (user.external) context.accessToken.scope.push("content");

// check if adult and add permissions
if (user.age >= 18) context.accessToken.scope.push("content_adult");

// check if not external and add permissions
if (!user.external) context.accessToken.scope.push("content_hd");

// USER: MOM
"subscription": 1234,
"admin": true, "external": false, "age" : 45

// USER: DAD
"subscription": 1234,
"admin": false, "external": false, "age" : 47

// USER: CHILD (ADULT)
"subscription": 1234,
"admin": false, "external": false, "age" : 20

// USER: CHILD (MINOR)
"subscription": 1234,
"admin": false, "external": false, "age" : 16

// USER: PARTNER (CHILD ADULT)
"subscription": 1234,
"admin": false, "external": true, "age" : 21
```

The amount of static decisions to make in this ABAC model would be:

```javascript
complexity_abac = users * (subscriptions + attributes)
[users: 10.000, subscriptions: 5.000, attributes: 3 => 50.030.000]
```

When the number of attributes is significantly lower than the number of roles or permissions, it can vastly reduce the complexity. Of course, now a dynamic component of policies is introduced. At Auth0, we provide support for ABAC through [rules](https://auth0.com/docs/rules), which are JavaScript snippets that run after login and allow customizing the permissions returned to the applications.

## Relationship-Based Access Control (ReBAC)

In a ReBAC model, a graph-based model is introduced between users and subscriptions, and policies dynamically determine how permissions are assigned to users based on relationships of the user. This allows for a lot more expressive and powerful policies, enabling the business to truly understand the user’s environment and act accordingly. 

![Relationship-Based Access Control](https://images.ctfassets.net/23aumh6u8s0i/4ijiLd7E4K6FbKLYzfKVku/76e6faa1377b5e6f6311bae7d66e0518/rebac)

Our example using ReBAC:

```javascript
// RULES: REBAC
// if subscription is managed by user …
if (sub:subscription--managed_by-->user:user)
	context.accessToken[`subscription`] = sub:subscription.number;
	context.accessToken.scope.push([“sub_admin”, “content_admin”]);

// if user is related to admin of sub with max 2 hops …
if (sub:subscription--managed_by-->--related_with(2)--user:user)
	context.accessToken[`subscription`] = sub:subscription.number;
	context.accessToken.scope.push(“content”);

// check if adult and add permissions
if (user:user.age >= 18) context.accessToken.scope.push(“content_adult”);

// if user is related to admin of sub with max 1 hop ...
for (sub:subscription--managed_by-->--related_with(1)-->user:user)
context.accessToken.scope.push(“content_hd”);

//RELATIONSHIPS
sub:1234--managed_by-->user:mom
user:mom--related_with-->user:dad
user:mom--related_with-->user:child_adult
user:mom--related_with-->user:minor_adult
user:child_adult--related_with-->user:partner_child_adult

// USER: MOM
“age” : 45

// USER: DAD
“age” : 47

// USER: CHILD (ADULT)
“age” : 20

// USER: CHILD (MINOR)
“age” : 16

// USER: PARTNER (CHILD ADULT)
“age” : 21
```

Notice that we’ve now stated that everyone who’s related to the admin of the subscription within one hop is considered “close family” and is able to stream content in HD, and everyone who’s related to the admin of the subscription within two hops can access content, allowing all “in-law family” to access content as well, not only **child_adult_partner**.

The amount of static decisions to make in this ReBAC model would be:

```javascript
complexity_rebac = users * attributes + subscriptions + users * (users - 1) / 2
[users: 10.000, subscriptions: 5.000, attributes: 1 => 50.010.000]
```

When the number of attributes is significantly reduced through a small number of possible relationships, it can vastly reduce the complexity. Although harder to quantify, it’s clear it provides more power to define generalized policies. As with ABAC, Auth0 supports ReBAC through the use of rules, which can call out to external sources such as a graph database, where the model can be stored and queried efficiently.

The same model could also be used to enrich the information provided back to the application for improved personalization. This allows for a smoother migration of accounts, as social graphs don’t need to change, and can handle more complex setups.  For example, an admin on one subscription could also have non-admin access to another subscription.

## Conclusion

We looked at four different authorization models to map users to the correct permissions:

1. **Discretionary Access Control** (DAC) where permissions are statically assigned to users directly and only proven manageable with extremely small amounts of users, subscriptions and permissions. Supported by Auth0 using [metadata](https://auth0.com/docs/users/concepts/overview-user-metadata) on accounts.

2. **Role-Based Access Control** (RBAC) where permissions are statically assigned to roles/groups which in turn are assigned to users, vastly reducing complexity when less roles than permissions. Supported by Auth0 using integrated [roles](https://auth0.com/docs/authorization/guides/manage-roles).

3. **Attribute-Based Access Control** (ABAC) where permissions are dynamically assigned in policies to users based on the attributes or roles/groups of the users, vastly reducing complexity when less attributes than roles/groups and permissions. Supported by Auth0 using [rules](https://auth0.com/docs/rules).

4. **Relationship-Based Access Control** (ReBAC) where permissions are dynamically assigned in policies to users based on the relationships or attributes of the users, vastly reducing complexity when attributes are significantly reduced through a small number of possible relationships. Not only does it provide some complexity gains it also allows for far more complex scenarios to be modeled. Supported by Auth0 using [rules](https://auth0.com/docs/rules), calling out to an external graph database.

<include src="asides/AboutAuth0" />

---


Understanding a Media Consumer’s Social Graph

olususi-oluyemi

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

Software Engineer / Technical Content Creator

Olususi Oluyemi

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

Developing Modern Apps with Symfony and React

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 how to develop and secure modern applications with GraphQL, React, Apollo, and Auth0.

Secure GraphQL, React, and Apollo Apps with Auth0

Build Apps with GraphQL, React, and Apollo

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Learn how to leave usernames and passwords behind with social and passwordless authentication.



**TL;DR:** Learn how to leave usernames and passwords behind with social and [passwordless authentication](https://auth0.com/passwordless) with Auth0's [Identity and Access Management solution](https://auth0.com/user-management).

---

After months and months of developing your new app, it's finally ready to launch. You feel confident that you've got all the features and functionality you need. But with all of that work, you've let your login fall by the wayside. A simple a username and a password will do the trick, right?

Wrong. In the age of modern authentication, you need to go beyond usernames and passwords to protect customer information and give users frictionless logins that they trust. Embracing login as identity management rather than as a simple gate to access is imperative.

Here's what you need to know.

## Implement Easy Login Options for Users

Between the growing number of passwords users have to remember and the multiple steps needed to reset a forgotten password, users are demanding easier login options.

Making it as easy as possible for them to visit your site means they'll [stick around longer](https://blog.fullstory.com/the-best-products-will-win-7ec43a93186#.onq2r8lau). By removing the friction usually associated with activating a new account or simply signing in, you'll reduce your abandon rate.

Using modern authentication practices, [Auth0](https://auth0.com) has built a system that can be quickly integrated into your site to give users the easy access they've been asking for. [Social login](https://auth0.com/learn/social-login/) and [passwordless authentication](https://auth0.com/passwordless) are two options that provide freedom from usernames and passwords.

With social login, users confirm their identity by using a third party site that has already vetted their authenticity.

![Social authentication](https://images.ctfassets.net/23aumh6u8s0i/1OFiTKkAcgA3DECIVuNOKL/05681fd900210170f791822e35124c2c/social-login)
[Source](http://tradablebits.com/social-login)

It takes less time for users to set up an account and profile since their personal information is automatically filtered into the new site. Almost everyone has at least one social media profile, so it's perfect for users who want one fewer password.

With passwordless authentication, users are sent timed codes via SMS or email to access their account.

They only need to have immediate access to their phone or email to quickly access their account. Again, this saves them time and effort while their account remains accessible and secure.

## Provide Enterprises with Centralized Oversight

Enterprise customers need to maintain control of their many employees' login access. They want a secure, central place to manage user identity, and often want the benefits of [Single Sign-On (SSO)](https://auth0.com/learn/how-to-implement-single-sign-on/) as well.

They also need you to be able to comply with whatever their given enterprise connection is, whether that's AD, LDAP, ADFS, SAML, Ping, or Google Apps. These connections can be difficult and time-consuming to implement, and that's _without_ looking at getting everything up to specific industry standards.

If identity isn't part of your core business, scaling up to support enterprise authentication only serves to take attention away from what you do best.

In this case, enterprise federation is the best approach for enterprises. Scaling up to an enterprise platform is quick and easy to set up with an [IAM (Identity and Access Management) solution like Auth0](https://auth0.com). Once up and running, it's easy to choose who will manage and monitor access based on identity, add and remove users, manage login requirements, and run any necessary analytics.

From the Auth0 dashboard, go to Connections > Enterprise to view available connections or to create new ones.

![Auth0 enterprise connections dashboard](https://images.ctfassets.net/23aumh6u8s0i/7EuJvrcgzvbIjrFpZCtWfj/af08c4fa5429eb1ea34cdb5e5fee87b1/auth0-enterprise)

With this platform, enterprises can monitor user accounts from one central dashboard.

## Make Security a Top Priority

Both users and enterprises want secure logins. Users expect a certain level of protection from the sites they access and enterprises want to secure their internal data. Unfortunately, simply relying on the username and password approach might not get you very far.

Just look at companies like [LinkedIn](http://fortune.com/2016/05/18/linkedin-data-breach-email-password/) and [Yahoo](https://auth0.com/blog/yahoo-confirms-data-breach-of-half-a-billion-user-accounts/). They are some of the largest companies out there, but were still susceptible to data breaches. User data was easily accessed by hackers due to inadequate security parameters.

That's why modern authentication is so important. Instead of building a system from scratch, you can access ready-made platforms that provide encryption, brute force protection, constant monitoring for attacks, and the ability to promptly notify users.

With Auth0's approach to modern authentication, we take away the need for in-house custom builds that don't meet compliance standards.

For example, as part of a suite of [security features](https://auth0.com/security), Auth0 offers anomaly detection to fight against brute force attacks. If suspicious activity is detected, users are notified immediately. All of Auth0's automated blocking features are built with resilience in mind.

Another important security feature is credential and user login monitoring.

![Auth0 log tracking](https://images.ctfassets.net/23aumh6u8s0i/6rogIjpng0uNPfQHJ8rILE/16474d490bddf002418e9d26660af093/auth0-logs)

From the dashboard, you can easily track logs and be confident in knowing that security compliance and regulations are automatically taken into consideration and deployed across your site.

## Moving Forward with Modern Authentication

Now more than ever, authentication involves more than just supporting usernames and passwords. Modern authentication puts the emphasis on creating and protecting identity for users, whether they're an individual using an app or enterprise employees.

Usernames and passwords aren't going to disappear, but authentication is complex, and it's only going to get harder to manage.

There's no need to struggle to keep up using in-house solutions when you can rely on experts that live and breathe identity management. Your IAM solution can support everything you want to offer your users, while letting you focus on the product that got users to sign up in the first place.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can improve your product's security 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) so you can get started with modern authentication.


Go Beyond Username/Password with Modern Authentication

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

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

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Auth0 makes it simple and easy to add authentication and authorization to any app. By localizing our marketing website, we hope to make it easier for developers and companies to implement and see the benefits of modern identity management.



**BELLEVUE, WA - Konnichiwa!** We are pleased to announce that the Auth0 marketing website has been localized for the Japanese market. Auth0 makes it simple and easy to add authentication and authorization to any app with its powerful API and SDK’s for most languages and frameworks. 

Auth0 has always championed and embraced open-source software and we hope that by localizing our vast knowledge of security best practices we can make it easier for developers and companies, regardless of industry, location, or *language*, to make the web a safer and more secure place for everyone.

![Auth0 Japan](https://images.ctfassets.net/23aumh6u8s0i/7iYJ6F6NCYo6rYEaMi42b7/a7e02e6cc8b91a632cbd34e9a3a3486a/auth0-jp)

If you are visiting the Auth0 website from a Japanese locale, you will automatically see the website presented in Japanese. If you wish to view the Japanese version of the website but are outside of the Japanese locale, you can view it by visiting [https://auth0.com/jp](https://auth0.com/jp).

<include src="asides/AboutAuth0" />


The Auth0 Marketing Website Has Been Localized for the Japanese Market

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Ado Kukic

Legacy username and password authentication is not enough. Learn about modern authentication and how Auth0 can help you implement it for your clients.



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

---

**TL;DR** Whether you're a small consultancy working with a few clients or have been around for some time, the authentication needs of your customers are likely similar. Legacy authentication via username and password is not enough. Your customers are demanding multifactor authentication, single sign-on, and greater security. Building these features in-house is complex, but with Auth0 it doesn't have to be.

---

Being a consultant or systems integrator means wearing many hats. To be successful you must be knowledgeable about various technologies, methodologies, and best practices as well as know how to put them all together to meet your clients' goals. The technological landscape is constantly changing and keeping up can be a challenge.

When it comes to authentication and security, usernames and passwords are simply not enough. Modern authentication focuses on:

* [Managing user identity](https://auth0.com/docs/user-profile)
* [Top tier security and availability](https://auth0.com/security)
* [Multiple authentication strategies](https://auth0.com/docs/identityproviders)
* [Multifactor authentication](https://auth0.com/docs/multifactor-authentication)
* [Single sign-on](https://auth0.com/docs/sso)
* [Passwordless authentication](https://auth0.com/passwordless)
* and more...

*Keeping up* with modern authentication and security best practices would be challenging on its own, but *implementing* it alone would require a herculean level of effort.  At Auth0, we can provide your consulting organization with the tools and support to implement modern authentication for your clients.

<include src="TweetQuote" quoteText="Building modern authentication is difficult, but with Auth0 it doesn't have to be."/>

## Auth0 for Systems Integrators

Whether you're a small consultancy working with a few clients or have been around for some time, the authentication requirements from your customers are likely similar. Auth0 can provide a comprehensive authentication platform that your clients will love. Your organization will benefit from being able to provide modern authentication in record time. Let's take a look at some of the features.

### Modern Authentication

Authentication starts at the login screen. The [Lock](https://auth0.com/lock) widget provides a modern login widget that supports traditional username and password, social, and enterprise authentication. This cross-platform widget can be implemented in as little as ten lines of code but supports various branding and configuration options to truly make it your own. If you prefer to implement your own unique UI instead, our RESTful API provides the same functionality so you can have full control.

### Enterprise Federation and Single Sign-On

Enterprises require governance over their users and will demand [single sign-on](https://auth0.com/docs/sso). Implementing and maintaining integrations with the various [enterprise federation providers](https://auth0.com/docs/identityproviders#enterprise) would be a very challenging task. Auth0 has built integrations with leading platforms like [Active Directory](https://auth0.com/docs/connections/enterprise/active-directory), [Ping](https://auth0.com/docs/protocols/saml/identity-providers/ping7), [ADFS](https://auth0.com/docs/connections/enterprise/adfs), [LDAP](https://auth0.com/docs/connections/enterprise/active-directory), [SAML](https://auth0.com/docs/protocols/saml/saml-configuration) and more so all you have to do is provide the configuration details and we'll take care of the rest.

### Social Connections

Allowing users to log in with their existing social accounts can increase conversion rates and improve the user experience. Auth0 supports [over thirty social connection](https://auth0.com/docs/identityproviders) providers including [Facebook](https://facebook.com), [LinkedIn](https://linkedin.com), [Twitter](https://twitter.com), and [Google](https://google.com). Auth0 can additionally be integrated into any provider that supports [OAuth 2](https://auth0.com/docs/extensions/custom-social-extensions).

### Traditional Authentication with Enhanced Security Features

If [username and password](https://auth0.com/docs/connections/database) authentication is a requirement, Auth0 has you covered. Traditional **username and password** or **email and password** authentication is provided with enhanced security features. [**Multifactor authentication**](https://auth0.com/docs/multifactor-authentication) greatly enhances the security of this type of authentication and can be added with the flip of a switch. Anomaly detection, which prevents brute force attacks, as well as [breached password detection](https://auth0.com/breached-passwords) go a step further to provide greater security for your users.

### Passwordless Authentication

[Passwordless authentication](https://auth0.com/passwordless) allows your users to log in without having to enter or remember a password. Instead, when the user wants to log in, they provide their email address or phone number and receive a one time passcode that they use to authenticate instead. Auth0 provides various options for passwordless authentication including SMS and Email. 

## Auth0 Partners Program

Auth0 solves authentication, identity, and security challenges for organizations by providing a complete platform for managing modern identity. Our goal is to make identity simple and easy, so you can spend less time worrying about authentication and focus on your clients and their needs. [Contact us](https://auth0.com/partners#become-a-partner) today to learn more about becoming an [Auth0 Technology Partner](https://auth0.com/partners).


Modern Authentication for Your Clients Made Easy

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Conventional authentication is challenging for today's web applications. Learn about the reasons and how to use JSON Web Tokens (JWT) for modern authentication.



---

**TL;DR:** Traditional session-based authentication with cookies presents difficulties, especially for modern web applications. We can instead use JSON Web Tokens (JWT), which make our apps stateless. Migrating a legacy app over to JWT authentication can be done piece by piece, and if we need to, we can use cookies to handle JWTs. To see how this is done, take a look at the [repo](https://github.com/auth0/cookie-jwt-auth) for this tutorial.

---
Authentication for web applications has historically been fairly straightforward and followed a common pattern, but this has been changing significantly in recent years. There are several reasons for these changes, and the prominent ones are related to the way in which modern applications are built and distributed.  In this article, we'll see how things have changed and also some ways we can adapt legacy applications to modern day practices.

## Traditional Web Applications

In a general sense, traditional websites and applications typically implement user authentication using **sessions** and **cookies**. When users log in to a site, their username and password are matched against database entries. If the login is successful, the server saves the user's authentication state in memory and sends a cookie back in the response that contains some data, which in most cases includes the user's ID. Browsers will save the cookie for the domain from which it came and then automatically send it back when subsequent requests are made. For example, if a cookie is saved with a domain of auth0.com, it will be sent back on any future request to auth0.com as long as it is valid. This works great for traditional web apps.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/2E0gj0N91SqR18iJcYX0pS/2843825e62cc48a85c287ffad235efc9/legacy-app-auth-1)

Even though we've labeled the process described above as being "traditional", it should be noted that *most* of the web still operates this way. While this approach is still perfectly valid for a lot of use cases, we're going to explore some of the reasons why relying on it has become challenging for modern web applications.

## Authentication Challenges for Modern Web Apps

Modern web applications present a few challenges for authentication that are difficult to solve using conventional methods. The reasons for this have to do with how applications are crafted and the environment in which applications reside.

### 1. Apps are distributed across many servers

Many of today's applications aren't deployed the same way they were in the past. It is now very common--and often necessary--for apps to be distributed across many servers so that up-time is increased and latency issues are mitigated. With this comes the side effect that, when a user accesses an application, it is no longer guaranteed that they are always accessing the same server.

Since traditional authentication relies on the server to keep the user's authentication state in memory, things break down when the app is accessed from different servers. The user might be logged in on one server but not on the others that the application is distributed across.

We can get around this by using methods like [**sticky sessions**](http://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions). A sticky session will essentially route the user to the server instance from which they logged in so that the authentication state can be presevered. This type of workaround will do the job, but as we'll see, stateful servers in general don't play that well with modern applications.

### 2. Apps use APIs for data

A common pattern for modern applications, especially single-page apps, is to retrieve and consume JSON data from a [RESTful API](http://www.restapitutorial.com/). Serving data from an API has several distinct advantages, one of them being the ability for data to be used in more than just one application. For example, an organization might start with the intent to build an internally facing application, but may soon realize that some of its functionality could be used in a public-facing app. Down the road, the organization might also decide that some of its data should be accessible by other application developers to build third-party apps with. This can all be made possible with an API.

Using APIs in this fashion is great, but things can become challenging when it comes to authentication. The traditional approach of using sessions and cookies for the user's identity doesn't work so well in these cases because their use introduces **state** to the application. One of the tenets of a RESTful API is that it should be **stateless**, meaning that, when a request is made, a response within certain parameters can always be anticipated without side effects. A user's authentication state introduces such a side effect, which breaks this principle. Keeping the API stateless and therefore without side effect means that maintainability and debugging are made much easier.

<include src="TweetQuote" quoteText="Keeping the API stateless means that maintainability and debugging are made much easier."/>

Another challenge here is that it is quite common for an API to be served from one server and for the actual application to consume it from another. To make this happen, we need to enable [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS). Since cookies can only be used for the domain from which they originated, they aren't much help for APIs on different domains than the application.

### 3. Apps rely on downstream services

Another common pattern seen with modern web applications is that they often rely on downstream services. For example, a call to the main application server might make a request to a downstream server before the original request is resolved. The issue here is that cookies don't "flow" easily to the downstream servers and can't tell those servers about the user's authentication state. Since each server has its own scheme for cookies, there is a lot of resistance to flow, and connecting to them is difficult.

## A Modern Alternative: The JSON Web Token (JWT)

To combat the issues detailed above, we can take a token-based approach by using JSON Web Tokens (JWTs) for authentication. A JWT contains three parts:

**1. Header**

The header tells us about the algorithm and token type. It is Base64URL encoded.

**2. Payload**

The payload contains any arbitrary information in the form of claims that we as developers find useful for our applications. The user's ID must be sent as a `sub` claim, but we can also send other useful information, such as the username, email, and more. The payload is also Base64URL encoded.

**3. Signature**

The signature is used to verify the authenticity of the JWT. There are several different algorithms that can be used for the signature. Some algorithms implement a shared secret (HMAC), and others use public-private key secrets (RSA).

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/1sS3oSviChEPzlXMAYHHLQ/b58c9c25c3ecb38505a5e77e5965e981/legacy-app-auth-5)

From the user's perspective, logging in to an application that uses JWTs looks much like traditional authentication. Users enter their credentials as usual, but instead of the server creating a session and returning a cookie, it will respond with a JSON object that contains a JWT. The JWT then needs to be saved locally, which is normally done with local storage. However, as we'll see in the next section, it is possible to save the JWT in a cookie.

The JWT must be sent to the server to access protected routes, and it is typically sent as an `Authorization` header. The scheme used for this header is `Bearer`, so the full header looks like this:

```js
Authorization: Bearer <token>
```

Middleware on the protected API routes will check for a valid JWT, and if there is one, it will let the request through and return the data being requested. Since the user's information is contained within the JWT itself, there is no need to look the user up in a database, so there is less latency in the application.

It should be reiterated that the user's state is never saved in memory on the server, meaning that the user isn't "logged in" in the conventional sense. However, a valid JWT gives the user the keys to access data each time a request is made, and in this way, a stateless authentication mechanism is in place.

![](https://images.ctfassets.net/23aumh6u8s0i/1f37fJAPR7UgfFW8oYYeKs/5f00a4413b04510ad6bd6801f04a2fed/legacy-app-auth-2)

Using a JWT for authentication helps to solve the challenges noted above. We can fully rely on data APIs that are stateless and even make requests to downstream services. Since JWT is a specification [implemented nearly everywhere](http://jwt.io), connecting to downstream services built on a stack other than our own is easy. It also doesn't matter which domain is serving our API, nor does it matter which specific server a request goes to if the app is deployed across many.


## Bridging the Gap: Using JWTs in Cookies

Modernizing legacy applications by implementing token-based authentication can lead to many gains. If it isn't feasible for an organization to totally throw away cookies, there are still ways to make token authentication viable. Let's take a look at how this can be done with NodeJS and the **express-jwt** package.

### Step 1: Set Up a Back End

To follow along, you can download Auth0's [NodeJS seed project](https://auth0.com/docs/node-auth0/master/create-package?path=examples/nodejs-api&filePath=&type=server) from the [docs page](https://auth0.com/docs/quickstart/backend/nodejs/). Even though we're using an Auth0 seed project here, doing cookie-based authentication in this way will work with any service.

### Step 2: Install Cookie Parser

Once the dependencies for the seed project are installed by following the [installation steps](https://github.com/auth0/node-auth0/tree/master/examples/nodejs-api), we'll need to add one more package: **cookie-parser**. This package will allow us to read JWTs from cookies that are sent to the server.

```bash
npm install cookie-parser --save
```

With **cookie-parser** installed, we now need to require and use it in `server.js`.

```js
// server.js

...

var cookieParser = require('cookie-parser');

...

app.configure(function() {

  app.use(cookieParser());

  ...

});
```

### Step 3: Save the JWT as a Cookie

We'll need to retrieve a JWT for a user and save it locally as a cookie. If you're using Auth0 for this tutorial, you can find out more about retrieving JWTs for users in your Auth0 account by reading the [API documentation](https://auth0.com/docs/api/v2). We'll use jQuery in this example to make the AJAX calls easy.

Lets make a call to Auth0 to get a JWT.

```js
// app.js

$('.btn-login').click(function() {
  $.ajax({
    type: 'POST',
    url: 'https://{your-auth0-account}.auth0.com/oauth/ro',
    data: {
      client_id: '{your-client-id}',
      username: document.querySelector('#username').value,
      password: document.querySelector('#password').value,
      grant_type: 'password',
      scope: 'openid',
      connection:'Username-Password-Authentication'
    },
    success: function(data) {
      getJwtCookie(data.id_token);
    },
    error: function(error) {
      console.log('There was an error: ' + error)
    }

  });
});
```

In the success handler, we're calling a function called `getJwtCookie` and passing in the token that was received from Auth0. We need to create an endpoint on our application server that can validate the JWT that was received from Auth0 and send it back to us as a cookie, and we can do that in the `getJwtCookie` function.

```js
// app.js

function getJwtCookie(token) {
  $.ajax({
    type: 'POST',
    url: 'http://localhost:3001/secured/authorize-cookie',
    data: {
      token: token
    },
    headers: {
      'Authorization' : 'Bearer ' + token
    },
    success: function() {
      console.log('Cookie received!');
    },
    error: function() {
      console.log('Problem with cookie');
    }
  });
}

```
Next, lets set up the `authorize-cookie` endpoint to handle this call.

```js
// server.js

app.post('/secured/authorize-cookie', authenticate, function(req, res) {
  res.cookie('id_token', req.body.token, {
    expires: new Date(Date.now() + 36000),
    httpOnly: true
  });
  res.send(200, { message: 'Cookie set!' });
});
```

In the next step, we'll set up our **express-jwt** middleware, but we're making use of it already in the `authorize-cookie` route by passing it in as the second argument, `authenticate`. The middleware secures the endpoint and a valid JWT will be needed to access it. If the JWT is valid, we simply reflect it back as a cookie and set the `httpOnly` flag to `true` so that the cookie can only be accessed by the server. This route accomplishes the steps of validating the JWT that was received from Auth0, as well as the step of setting a cookie with the JWT.

**Note:** We are using an `Authorization` header to accomplish our cookie JWT in this example. This is the only place we would need to make a request using this header--the rest of the application will handle JWTs with cookies.

### Step 4: Set Up Middleware to Check for the Cookie
Normally, the **express-jwt** middleware will look for the presence of a header and retrieve the JWT from there. However, we can also create a custom function to define how the token should be retrieved.

```js
// server.js

...

var authenticate = jwt({
  secret: new Buffer(process.env.AUTH0_CLIENT_SECRET, 'base64'),
  audience: process.env.AUTH0_CLIENT_ID,
  // Custom function to retrieve the JWT
  // We first look for the JWT in a header and if it isn't there,
  // we look for it in a cookie
  getToken: function fromHeaderOrCookie(req) {
    if(req.headers.authorization && req.headers.authorization.split(' ')[0] === 'Bearer') {
      return req.headers.authorization.split(' ')[1];
    } else if(req.cookies && req.cookies.id_token) {
      return req.cookies.id_token;
    }
    return null;
  }
});

...
```

We've added the `getToken` function as an option on the object that is passed into `jwt`. Our implementation here says that we want to first look for the presence of a JWT as an `Authorization` header, and if there isn't anything there, we want to check whether there is a cookie with the name `id_token`.

### Step 5: Test the Secured Route

With the `id_token` cookie in place, we can see that requests to the `secured/ping` endpoint go through just fine.

![modern authentication jwt](https://images.ctfassets.net/23aumh6u8s0i/4j5ZnQitsiwgVbLtwupT71/104a61fb2584f11a192c1fb36e476f92/legacy-app-auth-3)

<include src="asides/Jwt" />

## Wrapping Up

As we've seen, modern web applications are crafted and deployed in ways that make conventional user authentication challenging. JWT authentication is an excellent way to get around these challenges and allows us to keep our application server stateless. If we need to lean on old practices, such as using cookies, we can do so and still support JWT authentication with a little tweaking on the server.


5 Steps to Add Modern Authentication to Legacy Apps Using JWTs

bb9128fac91692ad4f46a785d772dd39?s=200 avatar

bb9128fac91692ad4f46a785d772dd39?s=200

Data Scientist and Engineer, I love tinkering with data!

Head of Data

Pablo Seibelt

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



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


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

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

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

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

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

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

So, let's get started with the steps.

## Installing and Configuring Shiny

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

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

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

## Installing Apache and the OpenID Connect Module

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

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

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

```
a2enmod proxy_http
```

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

```
a2enmod auth_openidc
```

## Configure an Auth0 Account

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

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

## Configure Apache to Serve Shiny with Auth0

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

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

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

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

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

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

It should look something like this:

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

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

  OIDCClientID <YourClientID>
  OIDCClientSecret <YourClientSecret>

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

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

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

</VirtualHost>
```

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

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

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

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

## Boom.

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

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

## Gotchas

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


Adding Authentication to Shiny Open Source Edition

eugenio-pace-new-avatar

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

CEO and Co-Founder

Eugenio Pace

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

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

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

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



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

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

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

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

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

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

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

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

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

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

##How to configure it

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

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

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

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

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

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

That's it!

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

"mod_auth"