E017NDYFGQL-U4W9C40NL-51be4d627a6f-512

Ari is a seasoned Product-Led Growth (PLG) leader with a passion for architecting flawless customer journeys. As the VP of Developer-Led Growth at Auth0, he leads the Developer Marketing, Developer Relations, Activation, and Conversion teams, among others. His career journey includes a key role on the Microsoft Developer Evangelism team and a foundational period as a Software Engineer at Southworks and other firms, where he delivered mission-critical projects for Fortune 100 clients.

Vice President, DLG

Ari Schapiro

Explore Auth0's September 2025 product updates, featuring Auth0 for AI Agents, Tenant Access Control List in GA, Dry Run for Auth0 Deploy CLI, and more.




September 2025 in Auth0: Advanced Security Controls and Auth0 for AI Agents

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 and Python.  

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 about the history of AI agents, the risks they introduce and how to prevent them with a focus on fine-grained access control.


AI Agents are autonomous systems capable of executing complex tasks, making API calls, and maybe even modifying a production database on your behalf. This evolution introduces a new security challenge and attack vector as these AI agents can introduce a level of unpredictability that some access control systems are not ready to handle.

In this blog post, you’ll learn about the history of AI agents, the risks they introduce and how to prevent them with a focus on fine-grained access control. 

## A Brief History of AI Agents

In the last few years, LLMs have evolved to become the mainstream place for questions, and more recently, they have been increasingly used to call APIs on the user’s behalf, delegate work to other models, etc.

We went from simple chatbots to multi-agent collaboration in a matter of a few years, and they all cover different capabilities: 

* **Chatbot**: Can handle written questions and return text and usually operates in a browser communicating through an API endpoint, everything happens within the application.  
* **Assistants**: Can interpret a request and invoke external tools and services to fulfill it.   
* **Agentic** **System**: Chains several tools in a plan it composed on the fly. They operate by communicating the LLM with multiple other services   
* **Multi**\-**Agentic** **System**: Negotiates tasks with other agents, they operate on an agent-to-agent basis. 

## Access-Control Models Under Stress

Security teams usually reach for Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Permission or Policy-Based Access Control (PBAC), or Relationship-Based Access Control (ReBAC). Each shines in well-structured enterprise software; each shows strain when pointed at AI systems.

* **RBAC** is familiar and easy to audit. Unfortunately, an agent’s “role” can change from moment to moment. A request that begins as read-only can evolve into a code-generation exercise that needs write rights. Constant role hopping either floods your logs or drives teams to grant one oversized role that covers every possible combination.

* **ABAC/PBAC** add context: user tier, branch, time of day, tenant ID. They work well when the agent runtime can surface reliable attributes. The catch is that modern LLM stacks often rely on ephemeral containers or serverless functions where ambient context vanishes with each invocation. Persisting trustworthy attributes across the chain demands extra engineering that many proof-of-concept projects skip.

* **ReBAC** models complex resource graphs elegantly, perfect for mapping “Alice may comment on Bob’s ticket if they share a project.”. When the agent makes dozens of micro-tool calls per prompt, those lookups must complete in tens of milliseconds or users will notice a lag so your ReBAC systems must be fast

<include src="SignupCTA" text="Start building now, " linkText="Sign Up to Auth0!" />

## How Authorization Mitigates Top AI Security Risks (OWASP LLM Top 10)

The [OWASP Top 10 for Large Language Model Applications 2025](https://genai.owasp.org/llm-top-10/) explains the most critical risks for AI software and how to mitigate them. Let’s dig into it with a focus on access control. 

**LLM01 Prompt Injection**  
Attackers craft prompts that overwrite system instructions and steer the model toward harmful outcomes. A way to mitigate it is by implementing Input validation, adversarial testing and prompt isolation. In this context, Fine-Grained Access Control could block any tool call that is not explicitly scoped on the agent's permissions, so even a successful injection cannot reach sensitive operations.

**LLM02 Sensitive Information Disclosure**  
Large models sometimes expose secrets from training data or leak confidential context provided at runtime. Some of the ways to mitigate this is by encrypting secrets, removing them from prompts and adding output filtering. Implementing least-privilege scopes is also a good way to mitigate, for example let’s say you want to get data from patient records, your agent would simply lack permission to perform the request, so disclosure stops at the policy level. 

**LLM03 Supply-Chain Compromise**  
It is very common to use third-party models for agent implementations, which could be poisoned or have plugins introducing backdoors and bias. A way to mitigate this is to sign every artifact, verify checksums, and keep a software bill of materials. Assign each external component its own low-privilege identity.

**LLM04 Data and Model Poisoning**  
Attackers could add malicious examples into training or retrieval stores to change the model behaviour. One good way to mitigate this is by running rigorous data provenance checks and trusted-source allow lists help. In the context of access control, attribute-based rules can mark unvetted data as “not-usable,” preventing the agent from loading it until reviewers clear it. 

**LLM05 Improper Output Handling**  
When you give a response, you need to make sure it is validated and sanitized before passing it downstream to the user. It is important to always treat model output as untrusted, apply sanitization, and replay the action through the same access-control filter a human request would face. 

**LLM06 Excessive Agency**  
This risk is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, for example giving an agent broad autonomy could end in unintended deletions, commits and payments. A way to mitigate this is by starting with read-only scopes, requiring user approval and implementing authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not, for example by using fine-grained authorization.

**LLM07 System Prompt Leakage**  
This risk refers to when the system prompts or instructions used to steer the behavior of the model can also contain sensitive information that was not intended to be discovered. Internal instructions may reveal credentials or allowed APIs. Store prompts server-side, rotate them often and scrub sensitive content, you can also make sure that security controls are enforced independently from the LLM and as OWASP says, *“in cases where an agent is performing tasks, if those tasks require different levels of access, then multiple agents should be used, each configured with the least privileges needed to perform the desired tasks.”*

**LLM08 Vector and Embedding Weaknesses**  
Weaknesses in how vectors and embeddings are generated, stored, or retrieved can be exploited by malicious actions to inject harmful content, manipulate model outputs, or access sensitive information. A way to mitigate this is to implement fine-grained access controls and permission-aware vector and embedding stores, as well as data validation and source authentication. 

**LLM09 Misinformation**  
Misinformation occurs when LLMs produce false or misleading information that appears credible. This vulnerability can lead to security breaches, reputational damage, and legal liability. A way to mitigate with retrieval-augmented generation to retrieve verified information from trusted sources, fact-checking APIs, and human review for high-risk tasks. Access control adds a guardrail by, for example, demanding a second verified source before an important write or financial transaction proceeds. 

**LLM10 Unbounded Resource Consumption**  
Unlimited requests drain budgets or become denial-of-service vectors. To mitigate this risk, you can implement strong access controls, including role-based access control (RBAC) and the principle of least privilege, to limit unauthorized access to LLM model repositories and training environments. You could also implement watermarking to detect unauthorized use of the LLM output. 

## How Fine-Grained Authorization Controls AI Agents

1. **Least-Privilege Identities**  
   Give every agent or plugin its own low-privilege credentials and start each session in read-only mode. Grant extra verbs, such as *write invoice* or *delete file*, only after an explicit, audited elevation step.

2. **Policy Checks on Every Call and Result**  
   Route every tool invocation and any generated SQL, code, or HTTP request through an external authorization service. The LLM can propose an action, but the policy, not the model, decides whether it runs.

3. **Label and Quarantine Data Sources**  
   Tag incoming documents, datasets, and embeddings with trust levels like *unknown*, *partner*, or *verified*. Access rules block agents from training on or retrieving content until reviewers promote its label.

4. **Protect System Prompts and Internal Configs**  
    Store prompts on the server side, remove secrets, and rotate them often. Even if a prompt leaks it reveals little, because the agent’s credentials unlock only the narrow slice of resources it truly needs.

5. **Guardrails for Impact and Scale**  
    Require deterministic or human confirmation for payments, refunds, and code deploys, and apply per-identity rate limits and cost budgets. These measures blunt both hallucinated high-risk actions and runaway resource use.

## Conclusion

AI agents amplify productivity, but without the right access control rules, they also amplify risk. It’s important to treat every agent and plugin as its own low-privilege client, check every request with an external policy engine, and enforce strict boundaries around data and costly actions.

Learn more about how [Fine-Grained Authorization](https://fga.dev) works and how you can use it to [secure your AI Agents](https://a0.to/ai-content) for example by [securing a RAG application with Auth0 FGA.](https://auth0.com/ai/docs/intro/authorization-for-rag) 



Access Control in the Era of AI Agents 

Most applications start with a need for tenant-level permissions. How do you control what users can do within their own organization? Let's learn how to implement RBAC in a FastAPI Application and OpenFGA to manage multi-tenancy.

Implementing Role-Based Access Control (RBAC) with Auth0 FGA and FastAPI

ana-cidre

Ana Cidre is a passionate advocate for the developer community and leads the Developer Advocacy team at Auth0. She's committed to fostering a more inclusive and diverse tech world, drawing on her technical background and strategic vision to improve developer experiences and build meaningful connections.

<br>

As the founder of GalsTech, an initiative supporting women in tech in Galicia, and through her active efforts to create welcoming spaces for underrepresented groups, Ana's dedication to diversity and inclusion extends beyond her daily work.

<br>

Ana has a proven track record of building global Developer Relations teams, cultivating active developer communities, and crafting impactful educational content. She maintains a strong connection to the community through speaking engagements and direct interaction with developers.

Sr Manager, Developer Advocacy

Ana Cidre

June delivered robust Auth0 updates focusing on enhanced security, greater control over authentication flows, and improved integration capabilities for developers.

June delivered a robust set of updates for developers, focusing on enhanced security, greater control over authentication flows, and improved integration capabilities. From powerful new token management and authentication methods to smarter bot detection and a clearer path for managing your Auth0 configurations, this month's releases are designed to help you build more secure and efficient identity solutions.

If you're building with Auth0, these updates will help you simplify complex authentication patterns, harden your applications against threats, and give you more granular control over user experiences.

***Let’s dig in!***

## What's New

### Native to Web SSO – Now in Early Access

This new capability is a game-changer for mobile and web app developers. It enables seamless session sharing between native mobile apps and web apps using a secure, standards-based approach, meaning users can authenticate once and maintain their session across platforms without re-logging in.

![Native to Web SSO Authentication Flow](https://images.ctfassets.net/cdy7uua7fh8z/4gFE2RP5ZCEcukiNF3Gpae/f957034f63c36d5a11f6a64d988c00e9/sequence-diagram.png)

Highlights:

* Seamless session carry-over from iOS/Android to browser  
* Uses secure, signed session tokens with device binding  
* Integrated with Actions, CLI, Terraform, and SDKs  
* Works with SAML, WS-FED, and Post Login Actions

[Learn more](https://auth0.com/changelog#72JltARfrooqHBmkuTzb8d)

### Multi-Resource Refresh Tokens (MRRT) – Now in Early Access

Tired of juggling refresh tokens for every API? Now you don’t have to.

[MRRT](https://auth0.com/docs/secure/tokens/refresh-tokens/multi-resource-refresh-token) lets your app use a single refresh token to get new access tokens for multiple APIs. This simplifies lifecycle management and improves developer UX.

Highlights: 

* One refresh token → multiple APIs  
* Define audience-specific token policies  
* Works with expiring \+ rotating refresh tokens  
* Available in Management API, Deploy CLI, Terraform, iOS/Android SDKs

Perfect for microservices, distributed APIs, or mobile/web hybrids.

[Learn more](https://auth0.com/changelog#46knYejnHFSYMc59ijmGjz)

### Enhanced Bot Detection for Signups

The improved model now recognizes more legit users, especially on mobile and new browsers, with fewer false positives and unnecessary CAPTCHA prompts.

Highlights:

* Smarter handling of user-agent signals (new OS/browser versions)  
* Native mobile traffic is now better recognized  
* Enhanced security with lower friction

Available to **Enterprise customers with the Attack Protection add-on**.

[Learn more](https://auth0.com/changelog#2CLx9gZ1YB1nfO59QqH8po)

### Passkey Enrollment via My Account – Limited Early Access

**Native Passkey Enrollment** is here via our new **My Account API**. Your app can now offer seamless passkey onboarding, directly from your UI.

Highlights:

* Full passkey management via API  
* Built for native \+ web flows  
* First of many new capabilities on the self-service My Account platform

[Learn more](https://auth0.com/changelog#eW4GjQ2zYshqK7593Z1LW)

### Customize the Brute-Force Protection unblock page with Universal Login 

You can now custom-brand the unblock page for Brute-Force Protection using Universal Login. This update allows for a fully branded experience when users are locked out due to repeated failed login attempts.

Highlights:

* Branded unblock experience via Universal Login
* Improved compatibility with email security scanners 

[Learn more](https://auth0.com/changelog#3EQxapnmbIRlkDlyIxGc6S)

## Deprecations

### Multiple actions for custom phone and email provider triggers

If you use the Management API [create an action endpoint](https://auth0.com/docs/api/management/v2/actions/post-action), we are deprecating the ability to create more than one action per tenant for actions supporting custom phone or email providers and introducing a maximum limit of one action in the respective triggers:

* `custom-phone-provider`  
* `custom-email-provider`

[Read more](https://auth0.com/changelog#3x8aOrDhj5zKgYWA4e7EeD)

### Removal of Access to Specific Event Request Properties in Actions

Starting September 16, 2025, the service will restrict access to additional property names within the `event.request.query` and `event.request.body` objects when executing actions for the post-login and credentials-exchange triggers.

Request-related objects:

* `auth_session`
* `authn_response`
* `client_secret`
* `client_assertion`
* `refresh_token`

[Read the details](https://auth0.com/changelog#3FKFF7m36s3iNW64RA9xSP)

## Community and Events

### Where we were in June

June was packed with dev-first events where we shared real-world lessons in auth, AI, and secure system design:

* [dev_day(25)](https://developerday.com/) – Our virtual event for AI agents and identity fundamentals. Sessions available on-demand, [watch now](https://developerday.com/agenda).
* [Frontend Nation](https://www.ai.engineer/) – [Ramona Schwering (Moe)](https://auth0.com/blog/authors/ramona-schwering/) shared frontend security best practices  
* [AI Engineering World's Fair](https://www.ai.engineer/) – Exploring auth for agent workflows  
* [AWS Summit Hamburg](https://aws.amazon.com/events/summits/hamburg/) – with [Juan Cruz Martinez](https://auth0.com/blog/authors/juan-cruz-martinez/) at the booth answering questions    
* [React Summit](https://reactsummit.com/) – Moe on modern identity in React  
* [VLCTechFest](https://vlctechfest.org/es/) – [Carla Urrea Stabile](https://auth0.com/blog/authors/carla-stabile/) joined Spain’s open-source community  
* [Open Source Summit North America](https://events.linuxfoundation.org/open-source-summit-north-america/) – Carla on FGA  
* [AWS Summit Japan](https://aws.amazon.com/jp/summits/japan/) – with [Daizen Ikahara](https://auth0.com/blog/authors/daizen-ikehara/) at the booth answering questions  
* [Vercel Ship](https://vercel.com/ship) – with Juan at the booth answering questions  
* [A Night Of AI (NYC) Mini Tech Conference](https://www.aicamp.ai/event/eventdetails/W2025062315) – with Juan talking about AI agents and practical tooling
* [RenderATL](https://www.renderatl.com/) – Auth0 at the booth and participating in panel discussions with Netlify
![Auth0 at RenderATL](https://images.ctfassets.net/23aumh6u8s0i/7DQYTIytz6S1joIFxOwLZi/9ffb9fbe36e0c2ae389f2bb6f8a43954/Screenshot_2025-07-07_at_1.17.33_PM.png)

### Where we’ll be in July

We're heading into July with a strong presence across developer, identity, and cloud-native events — from keynotes in Europe to hands-on engagements in Asia Pacific and the U.S.

* [DWX 2025](https://www.developer-world.de/dwx) (June 30 – July 3, EMEA) – Moe presents *"From the Crypt to the Code"*, diving into secure coding and modern auth strategies
* [WeAreDevelopers World Congress](https://www.wearedevelopers.com/world-congress) (July 9–11, EMEA) – Come say hi at the booth and watch sessions by:
  * Moe - *"The Cake Is a Lie... And So Is Your Login’s Accuracy"*, unpacking real-world login flaws and how to build trust in AI-era authentication
  * [Deepu K Sasidharan](https://auth0.com/blog/authors/deepu-sasidharan/)  *"Delay the AI Overlords: How OAuth and OpenFGA Can Keep Your AI Agents from Going Rogue"*  
* [AWS Summit New York](https://aws.amazon.com/events/summits/new-york/) (July 16, AMER) – Our team will be on the ground connecting with cloud builders about secure identity at scale

Planning to attend? Reach out! We’d love to meet you and hear what you’re building.

Expect talks, demos and plenty of real-world tips on building secure, AI-aware, and scalable identity experiences.

That’s a wrap on July\! We’ll be back next month with more dev-first updates.

Until then:

**Stay secure.**  
**Keep shipping.**  
**We’re here if you need us.**

June 2025 in Auth0: Security, Control, and New Integrations

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

Let's continue to delve into the issues of Identity support in implementing Business-to-Business (B2B) Software-as-a-Service (SaaS) applications by exploring access control.

In our [previous post](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), we explored the core aspects of establishing a robust identity system for Business-to-Business (B2B) applications, including multi-tenancy, and customer and user onboarding. We discussed how Auth0's Organizations feature provides the necessary structure to isolate customer data and streamline initial setup.

Once you have the foundation of user management in place in your B2B application, the next critical challenge emerges: not all users within an organization should have the same access. A CEO needs different access than a junior analyst, and an admin for one customer’s Organization should certainly not have access to another customer’s Organization.

This article will dive into the critical realm of authorization, examining how to implement granular access control within your B2B Software-as-a-Service (SaaS) application and how Auth0 helps you achieve this with confidence.

## Using Role-Based Access Control (RBAC)

So the new challenges for a B2B SaaS developer now are: **How do I give different users within an organization different permissions and ensure that these permissions are scoped to their specific organization?**

As I recall helping build a B2B SaaS application, we had a raw version of RBAC implemented. In practice, we simply had roles attached to users and our code checked whether a given user had a specific role before granting access to a resource. This worked well enough in simple cases, but it wasn’t particularly flexible. If we added a new role, we had to change the existing code to include it in our authorization evaluations, even if the new role was only slightly different from an existing role — perhaps by one less permission. Raise your hand if you've found yourself in the same situation.

Auth0's RBAC support is out of the box and integrates well with Organizations. Essentially, a role is just a set of permissions identified by a name. These permissions can then be included in the user's access token or ID token, allowing your application's backend or frontend to enforce access policies. Your code doesn’t even need to know about roles, giving the administrator the freedom to aggregate existing permissions into new roles without any changes to your application code.

In addition, Auth0 allows you to assign roles to users **within the context of a specific Organization**. This enables you to deal with scenarios where users are members of multiple Organizations (not common, but possible). In such a scenario, the user "John Doe" can be an *Admin* for the "Acme Corp." organization but only a *Viewer* for the "Widgets Inc." organization, which prevents permission bleeding across your customer base.

> Here are some resources on RBAC:
> 
> * [Role-Based Access Control](https://auth0.com/docs/manage-users/access-control/rbac)  
> * [Add Roles to Organization Members](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles)  
> * [Implementing Role-Based Access Control in Your Blazor B2B SaaS Application](https://auth0.com/blog/role-management-auth0-organizations-b2b-saas/)

## Beyond Roles: ABAC and ReBAC for Complex Scenarios

While RBAC is pretty good for many scenarios, you might encounter situations where access needs are more dynamic or granular than a simple role can convey. Consider the case where access to a resource is based not only on user permissions but also on user attributes, such as the department they belong to, or time constraints, such as working hours.

In this case, the challenge becomes: **What if I need more dynamic access control based on user attributes or relationships to specific data?**

To correctly manage these scenarios you need to explore advanced authorization models like **Attribute-Based Access Control** (ABAC) and **Relationship-Based Access Control** (ReBAC).

Instead of defining permissions for roles, ABAC defines access rules based on attributes of the user (e.g., the user’s department or location), the resource being accessed (e.g., the type of document), and the environment (e.g., the hour of the day or the IP address). Auth0 can help gather these attributes and include them in tokens, and you can use [Auth0 Actions](https://auth0.com/docs/customize/actions) to dynamically add claims based on external data sources. The enforcement logic then resides in your application or a dedicated authorization service.

ReBAC focuses on the relationships between entities. Think of social networks: "Can user A see user B's post?" Yes, if "user A is a friend of user B". In a SaaS context, this could be: "Can user X access document Y?" Yes, if "user X is the owner of document Y" or "user X is a member of the project that contains document Y".

ReBAC requires a graph database or a specialized authorization service to model and query these relationships effectively. While Auth0 itself isn't a ReBAC enforcement engine, it provides the identity foundation and can integrate with external ReBAC systems like [Auth0 Fine-Grained Authorization](https://a0.to/auth0-fga-content).

For most B2B SaaS applications, a well-designed RBAC system, possibly enhanced with some attribute checks, is sufficient. However, understanding ABAC and ReBAC prepares you for scenarios where your application's authorization needs grow.

> Check out the following documentation to learn more about ABAC, ReBac, and FGA:
> 
> * [An Overview of Commonly Used Access Control Paradigms](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/)  
> * [How to Choose the Right Authorization Model for Your Multi-Tenant SaaS Application](https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application/)  
> * [Auth0 FGA](https://auth0.com/fine-grained-authorization)

## Conclusion

In this second part of our "B2B SaaS Identity Challenges" series, we’ve tackled the crucial aspect of granular access control. We moved beyond basic user management to explore how Role-Based Access Control (RBAC) helps define and enforce permissions within Organizations, and how Auth0's out-of-the-box RBAC support simplifies this for developers. We also touched upon advanced authorization models like ABAC and ReBAC, preparing you for more complex access scenarios.

While defining who can do what is essential, the real-world demands of enterprise customers extend beyond internal permissions. They require seamless integration with their existing IT infrastructure and a commitment to advanced security measures. In [our next article](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/), we will delve into critical topics like Single Sign-On (SSO), delegated administration, and robust threat protection, addressing the expectations of your largest customers.



B2B SaaS Identity Challenges: Granular Access Control

william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Learn about Relationship-Based Access Control (ReBAC): how it works, its benefits for flexible authorization, and how Auth0 FGA helps implement it effectively.

You know how on a git repository your permissions feel so intuitive? You're not just a generic 'user' across the whole application. You might be the owner of your own repo, a maintainer with merge rights on a team project, and only have permission to help organize the bug reports and feature requests on an open-source library you contribute to.

This whole system, where your permissions change based on your specific connection to a repo, a pull request, or an organization is the core idea behind Relationship-Based Access Control (ReBAC). It’s an authorization model based on how users work together. Access is defined by your relationship to the resource and not just what role you’re assigned.

ReBAC isn't the only choice for access control. It's one tool in a toolbox that includes other models like [RBAC](https://auth0.com/docs/manage-users/access-control/rbac) and [ABAC](https://auth0.com/blog/what-is-abac-and-how-to-implement-it-rails-api/#What-Is-Attribute-Based-Access-Control--ABAC--). As a developer, you might then ask, 'Which one is the right tool for my job?'"

To help you navigate that choice, we've put together a detailed post on [how to choose the right authorization model for your SaaS application.](https://auth0.com/blog/how-to-choose-the-right-authorization-model-for-your-multi-tenant-saas-application/)

## Understanding How ReBAC Systems Function

A ReBAC system is built on three main concepts that link together, which we'll break down using a git repository as our example.

**1. Subjects in a ReBAC System**

First up, you have the "Subject." This is the person or service that's trying to do something.

*Example:* A developer's account, `user:jane-doe`.

*Example:* An automated service, like `service-account:git-actions`.

**2. Objects: the Resources Controlled by ReBAC**

Next, there's the "Object." This is the resource the Subject wants to interact with or change.

*Example:* A whole repository, like `repo:acme-corp/webapp`.

*Example:* A specific pull request, like `pr:123`.

**3. Relationships: the Core of ReBAC**

Finally, and most importantly, you have the "Relationship." This is the piece that connects a subject to an object. It’s a simple, stored fact that describes their association. This isn't the permission itself, but a label defining the connection.

These relationships come in two main types:

* A **direct relationship** is a simple, stored fact, like a direct assignment.

*Example:* `user:jane-doe` is a maintainer of `repo:acme-corp/webapp`.


* An **indirect relationship** is where the system connects the dots for you. This is often called inherited permission.

*Example:* Dave gets `write_access` to a repo indirectly simply because he's a member of a team that has that access.

## How Does ReBAC Grant Permissions?

So if the relationship isn't the permission, how is a decision actually made? The system uses a separate set of rules that it checks against the facts.

Let's walk through a real git repository scenario:

* **The Ask:** Jane (`user:jane-doe`) tries to merge a pull request into the main branch of the `acme-corp/webapp repo`.

* **The System Checks:** The system doesn't ask, "Is Jane an admin?" Instead, it asks, "How is Jane connected to this specific repo?"

* **It Finds a Fact:** The system sees the stored fact: (`user:jane-doe`, `maintainer`, `repo:acme-corp/webapp`).

* **It Checks the Rulebook:** The repository's rules say something like: "Anyone with the maintainer relationship is allowed to `merge_pull_request`."

* **The Result:** The fact matches the rule, and the merge is allowed.

The power of this model is its flexibility. It means you can tweak your enforcement rules in GitHub (like requiring two reviews before merging) at any time, without having to go back and change the underlying relationship facts for all your developers.

## Challenges of Implementing ReBAC in Your Authorization System

Thinking about using ReBAC? Here's a quick heads-up on the common challenges you might run into.

### Performance Considerations for Scaling ReBAC

To check one permission, a ReBAC system might have to look up several different relationships that connect together. For example, checking if a user can see a file might involve checking their team memberships, which in turn involves checking the team's parent organization, and so on.

This can sometimes lead to slow queries and performance hits. As your application grows, it takes lots of engineering work to keep those lookups from slowing everything down.

### Designing Effective ReBAC Models

What makes ReBAC so great is its flexible, graph-style structure, but that's also what makes it tricky. The complexity isn't in a long list of rules, but in the designing of the relationship model itself.

Figuring out the "right" way to model your permissions (e.g., should a manager automatically inherit the permissions of everyone on their team?) is a big deal to start with. A poorly designed model can be hard to understand and even harder to change later on.

### Ensuring Audibility in Complex ReBAC Models

A side effect of a complex model is that auditing permissions can be tough. Answering a seemingly simple question like, "Why does Jane have access to this document?" can feel like untangling a ball of yarn. You might have to trace a path through five different indirect relationships involving teams and groups, which can make security reviews and debugging a pain.

### Keeping Your Data in Sync

Another roadblock you could run into is the dual-write problem. If your app's source of truth includes who's on what team or who owns what file lives in your main database and your ReBAC system is a separate service with its own database, it will need its own copy of that data to know what's going on.

And that’s how to get into the dual-write problem. When a manager moves someone to a new team, you've got to update that info in two places: your app's database and the authorization system. So, what happens if the write to your database succeeds, but the one to the auth system fails? Now you've got a user whose status is out of sync with their permissions. That can cause confusing bugs or, even worse, a security risk.

> This is a well-known problem in distributed systems If you want to see the different patterns for solving it, check out this blog post on ["Handling the Dual-Write Problem in Distributed Systems".](https://auth0.com/blog/handling-the-dual-write-problem-in-distributed-systems/)

All of these challenges point to the same advice. Using ReBAC successfully means putting in serious thought at the design stage. It trades the ongoing complexity of other systems for a thoughtful investment in your initial model.

## How Auth0 FGA Helps with ReBAC

So how do you actually use these concepts in a real tool? Let's look at [Auth0 FGA](https://a0.to/auth0-fga-content), a managed service for ReBAC. It provides the tools to get hands-on with the concepts we've been talking about and is built on the open-source [OpenFGA](https://a0.to/fga-content) (inspired by Google's Zanzibar).

Let's model our git scenario to show both direct and indirect permissions.

## Defining the ReBAC Authorization Model in Auth0 FGA

First, we define our authorization model in the Auth0 FGA Model Explorer. This is where we'll spell out the concepts we talked about earlier in the blog post. By defining the types of **objects** to be protected and the possible **relations** a **subject** can have with them. For example, a key **relation** in our model is `can_write`, which grants access if a **subject** has either a direct `maintainer` relationship with the **object**, or an indirect one by being a `member` of a `writer` team.

```js
model
  schema 1.1

type user

type team
  relations
    define member: [user]

type repository
  relations
    define maintainer: [user]
    define writer: [team]    
    define can_write: maintainer or member from writer
```

This model sets up our rule:

* A user gets `can_write` permission directly if they are a `maintainer`.
* A user gets `can_write` permission indirectly if they are a `member` of a `team` that is a designated `writer`.

## Creating Relationship Tuples in Auth0 FGA

Remember how we described a relationship as just a simple, stored fact? Now, it's time to actually store some of those facts in our system.

In the world of Auth0 FGA, each one of these "facts" is stored in something called a Tuple. Think of a Tuple as a single line-item that records one specific relationship, it's the raw data that connects a user to an object and solidifies their connection. You can use **Tuple Management** in the Auth0 FGA dashboard to add Tuples

```js
[
  // 1. Anne is a direct maintainer of the "webapp" repo
  {
    "user": "user:anne",
    "relation": "maintainer",
    "object": "repository:webapp"
  },
  // 2. The "developers" team is a writer on the "webapp" repo
  {
    "user": "team:developers",
    "relation": "writer",
    "object": "repository:webapp"
  },
  // 3. Bob is a member of the "developers" team
  {
    "user": "user:bob",
    "relation": "member",
    "object": "team:developers"
  }
]
```

### Verifying Access in Auth0 FGA

Now for the test. We ask the system simple questions, and it uses the model and the facts to give us an answer. In Auth0 FGA, we write assertions for this.

**Check #1 (Direct Relationship)**

* **Question:** Can Anne write in the "webapp" repo?
* **Answer: Yes.** The system checks the `can_write` rule. It sees that `maintainer` is a type of `can_write`, finds the fact that Anne is a `maintainer`, and grants access.

**Check #2 (Indirect Relationship)**

* **Question:** Can Bob write in the "webapp" repo?
* **Answer: Yes.** This is where the power of the model shines. 

The system checks:

1. Is Bob a direct `maintainer`? No.

2. Is Bob a `member` of a `team` that is a `writer` on this repo?

3. It finds the fact that the `team:developers` is a writer on `repository:webapp`.

4. It then checks if `user:bob` is a `member` of `team:developers`. Yes, it finds that fact.

5. The indirect rule (member from writer) is satisfied. Access granted.

Bob never got permission directly, but the system figured it out by traversing the relationship graph. If you want to get your hands dirty and build this yourself, the [Auth0 FGA documentation](https://docs.fga.dev/getting-started) is the best place to start.

You can see what each of these steps look like in Developer Mode of the Auth0 FGA playground.

![](https://images.ctfassets.net/23aumh6u8s0i/CQLIiE44n6iPLE7wP6xeo/1c02f3f14fc626d391a0b8ab8de5ab71/Screenshot_2025-06-13_at_11.57.21_AM.png)

## Final Thoughts on Relationship-Based Access Control

To bring it all together, ReBAC is an approach for modeling permissions that mirrors how your application actually works. Instead of relying on broad, static roles, it focuses on specific relationships: who owns a document, who is a member of a team, or who is assigned to a task. 

It does need more thought upfront to design that relationship model well. But the payoff for that initial work is an authorization system that's ultimately easier to use and change. When your app's features change, you often end up adding new relationships rather than rewriting hard-coded permission logic.

[Auth0 FGA](https://a0.to/auth0-fga-content) is a tool that provides the high-performance infrastructure for this approach, but the essential first step is always the work of designing a solid model that fits your application's needs.

What Is Relationship-based access control (ReBAC)?

Learn how to add Role-Based Access Control (RBAC) to your B2B SaaS application that leverages Auth0 Organizations.

In the realm of B2B SaaS, the ability to offer isolated and tailored experiences to distinct customer organizations is paramount. Auth0 Organizations provides a robust framework for managing these multi-tenant environments, offering features like dedicated user bases, custom branding, and organization-specific configurations. Building upon this foundation, implementing Role-Based Access Control (RBAC) within Auth0 Organizations unlocks a new level of granularity in managing user permissions.

In this article, we will explore how roles fit in the Auth0 Organizations framework and how to manage them programmatically using the SaaS Blazor application we are building throughout a series of articles.

## Understanding Role Management in Auth0 Organizations

Auth0 allows you to define roles and permissions to apply the [Role-Based Access Control authorization model](https://auth0.com/docs/manage-users/access-control/rbac). Usually, roles assigned to users apply across your entire Auth0 tenant. For example, a user who is assigned the _editor_ role will keep this role in all applications registered in your Auth0 tenant unless you apply a different authorization policy via [Actions](https://auth0.com/docs/customize/actions).

Auth0 Organizations allow you to represent your customers' users as distinct entities within your Auth0 tenant. This isolation is crucial for managing users, connections, and policies on a per-organization basis. In the Auth0 Organization context, roles are defined and scoped *within* a specific Organization. This crucial distinction allows for fine-grained control over what members can do *within* their designated Organization.

Consider a scenario where you have two customers using your SaaS application: Acme Inc. and Foo Corp. You used Auth0 Organizations to separate Acme Inc. users from Foo Corp. users. However, based on the [login flow you configured for your application](https://auth0.com/docs/manage-users/organizations/login-flows-for-organizations) and the [connection model](https://auth0.com/docs/manage-users/organizations/organizations-overview#connection-model) you are applying, you can have specific situations.

For example, suppose you have enabled users to log in as both an individual and an organization user. In that case, the question arises as to which role to consider. In fact, the user can be the application administrator when logging in as an individual, but a mere member when logging in as an Acme Inc. user.

Similarly, if you allow users to be shared between organizations, i.e., a user can be both an Acme Inc. and a Foo Corp. user, then there may be a need for the user to have different roles based on the Organization they are logging in to. For example, the user can be an administrator when logging in to Acme Inc. and just a member when logging in to Foo Corp.

Hence, the need for having roles linked to the Organization.

> In this article, we discuss traditional Role-Based Access Control, but in more complex B2B SaaS scenarios, you may need more granularity for your authorization check. In this case, you can leverage [Fine-Grained Authorization](https://a0.to/auth0-fga-content).

## Creating Roles for an Auth0 Organization

Creating roles to assign to users in an Auth0 Organization is straightforward. You can use your Auth0 dashboard or the Auth0 Management API. In both cases, there are two basic steps:

1. Create [the roles your application needs in your tenant](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/roles/create-roles).
2. Assign one or more [roles to the members of an Organization](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles).

In this article, we will use the Auth0 Management API to create roles and assign them to the members of an Organization.

### The Sample Application

The scenario you will be using is the B2B SaaS application we built in the previous articles using Blazor. The following articles recap how we built the application:

- [Add Auth0 Organizations to Your B2B Blazor Web App](https://auth0.com/blog/auth0-organizations-for-b2b-saas-blazor-web-apps/)
- [Enable Self-Subscribing Model in Your Blazor B2B SaaS Application](https://auth0.com/blog/enable-self-subscription-in-blazor-b2b-saas-application/)
- [Enforce Customer Email Verification in Your B2B Blazor Web App](https://auth0.com/blog/enforce-customer-email-verification-b2b-saas-blazor-app/)

You can download the starting Blazor project by running the following command:

```bash
git clone --branch email-verification --single-branch https://github.com/andychiare/MyBlazorSaaS
```

Follow the instructions in the attached README file to register and configure the application with Auth0. If you don't have an Auth0 account, [you can sign up for free](https://a0.to/blog_signup).

The Blazor application allows a new customer to subscribe and create a new Organization, but currently it makes no distinction between users. We want to introduce two roles in the application:

- the *admin* role, which is automatically assigned to the user who subscribes to your application and allows them to access an admin dashboard.
- the *member* role, which can be assigned to users who can't access the admin dashboard.

> In this example, you do not use permissions, which are typically assigned to roles. To keep things simple, you are focusing on role names to make access control.

<include src="Auth0TemplatesForDotnetCTA" />

### Creating the roles for the Auth0 Organization

Before modifying the application code, make sure you to update the permissions your application needs for managing roles. Assuming you have configured your application accordingly to the mentioned README file, go to your [Auth0 dashboard](https://manage.auth0.com/) and locate the *ManagementClient* application in the [Applications > Applications](https://manage.auth0.com/#/applications) section.

Select the *APIs* tab of the application's configuration page and expand the area below the Auth0 Management API item. Then, select the following permissions to add them to the existing ones:

`read:roles`, `create:roles`,  `update:organizations`, `create:organization_member_roles` , and `read:organization_member_roles`.

Finally, click the *Update* button to apply your changes.

Now you can proceed to make the changes that allow the application to create the *admin* and *member* roles if they have not been created previously. The *admin* role will be assigned to the newly created user within the new Organization.

For this purpose, open the `CreateOrganization.razor` file in the `MyBlazorSaaS/Components/Pages/Onboarding` folder and apply the changes highlighted below:

```csharp


//...existing code..
  
  private async Task StartCreateOrganization()
  {
    if (!String.IsNullOrEmpty(OrganizationName))
    {
      Organization organization;

      try {
        //...existing code...

        // 👇 new code
        //Create admin role if it does not exist
        Role adminRole;
        var adminRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "admin"}
          );

        if (adminRoleList.Count == 0)
        {
          adminRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "admin",
              Description = "Manage the organization's configuration."
            }
          );
        } else {
          adminRole = adminRoleList[0];
        }

        //Create member role if it does not exist
        Role memberRole;
        var memberRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "member"}
          );

        if (memberRoleList.Count == 0)
        {
          memberRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "member",
              Description = "Member of an organization."
            }
          );
        } else {
          memberRole = memberRoleList[0];
        }
        // 👆 new code

        //Add member
        await managementClient.Organizations.AddMembersAsync(
          organization.Id,
          new OrganizationAddMembersRequest() {
            Members = [UserId]
          }
        );

        // 👇 new code
        //Assign admin role to the new member
        await managementClient.Organizations.AddMemberRolesAsync(
          organization.Id,
          UserId,
          new OrganizationAddMemberRolesRequest {
            Roles = [adminRole.Id]
          }
        );
        // 👆 new code

        //...existing code...
    } else {
      Message = "Organization name is required.";
    }    
  }

//...existing code...
```

The first code block creates the two roles if they already don't exist. The second code block assigns the admin role to the user in the context of the current Organization. Let's take a closer look at the code:

```csharp
        //Create admin role if it does not exist
        Role adminRole;
        var adminRoleList = await managementClient.Roles.GetAllAsync(
          new GetRolesRequest {NameFilter = "admin"}
          );

        if (adminRoleList.Count == 0)
        {
          adminRole = await managementClient.Roles.CreateAsync(
            new RoleCreateRequest
            {
              Name = "admin",
              Description = "Manage the organization's configuration."
            }
          );
        } else {
          adminRole = adminRoleList[0];
        }
```

This part creates the *admin* role. It defines the `adminRole` variable and uses the `GetAllAsync()` method of the `Roles` object to get the *admin* role from your Auth0 tenant. Notice the filter passed as a parameter to get just the role named `admin`.

> Check out the [Management API reference documentation for more details on role management](https://auth0.github.io/auth0.net/api/Auth0.ManagementApi.Clients.RolesClient.html). 

If the *admin* role does not exist in your Auth0 tenant yet, you create it using the method `CreateAsync()` of the `Roles` object. In this case, you pass a `RoleCreateRequest` instance with the role's name and a description.

If the *admin* role already exists in your Auth0 tenant, you simply assign it to the `adminRole` variable.

Similarly, you create or get the *member* role with the rest of the code.

> You may choose to [create roles for your SaaS application using the Auth0 dashboard](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/roles/create-roles). In this case, you do not need the code shown above; you only need to retrieve the *admin* role and then assign it to the user you are about to create.

After creating the user for the new Organization, you assign them the *admin* role with the following code:

```csharp
        // 👇 new code
        //Assign admin role to the new member
        await managementClient.Organizations.AddMemberRolesAsync(
          organization.Id,
          UserId,
          new OrganizationAddMemberRolesRequest {
            Roles = [adminRole.Id]
          }
        );
        // 👆 new code
```

You used the `AddMemberRolesAsync()` method of the `Organizations` object by passing the Organization ID, the user ID, and the role ID embedded in an `OrganizationAddMemberRolesRequest` instance. Read the [documentation reference](https://auth0.github.io/auth0.net/api/Auth0.ManagementApi.Clients.IOrganizationsClient.html#Auth0_ManagementApi_Clients_IOrganizationsClient_AddMemberRolesAsync_System_String_System_String_Auth0_ManagementApi_Models_OrganizationAddMemberRolesRequest_System_Threading_CancellationToken_) to learn more about the parameters of the method.

Your B2B SaaS application now has users and roles for its Organizations.

## Applying Role-Based Access Control

Once you have role support in the context of the Organizations, it's time to leverage them to control access to your application.

### Building and protecting the dashboard

As mentioned earlier, we will allow admin users to access a dashboard while Organization members will not.

Create a `Dashboard` folder in the `MyBlazorSaaS/Components/Pages` folder and add a `Home.razor` file with the following content:

```csharp


@page "/dashboard"
@attribute [Authorize(Roles = "admin")]

@inject IAuth0Management auth0Management

<PageTitle>Dashboard</PageTitle>

<h1>Welcome to your dashboard!</h1>

<div>
  <div class="form-group row my-2">
    <label for="organizationName" class="col-sm-4 col-form-label">Organization</label>
    <div class="col-sm-6">
      <InputText 
        type="text"
        @bind-Value="OrganizationName"
        id="organizationName"
        class="form-control"
        disabled/>
    </div>
  </div>
</div>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string OrganizationName = "";

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      if (state.User?.Identity?.IsAuthenticated??false)
      {
        var organizationId = state.User?.FindFirst(c => c.Type == "org_id")?.Value??String.Empty;
        if (!string.IsNullOrEmpty(organizationId))
        {
          var managementClient = await auth0Management.getClient();
          var organization = await managementClient.Organizations.GetAsync(organizationId);
          OrganizationName = organization.DisplayName;
        }
      }
    }
  }
}
```

This code defines a page that simply shows the Organization name in a readonly textbox. Notice the `Authorize` attribute at the beginning of the Razor component. It specifies "admin" as the user role authorized to access this page.

Now, open the `Home.razor` file in the `MyBlazorSaaS/Components/Pages` folder and add the markup highlighted below:

```html




@if (!string.IsNullOrWhiteSpace(OrganizationMessage)) {
  <div class="alert alert-success" role="alert">
    @OrganizationMessage
  </div>
}


<AuthorizeView Roles="admin">
    <Authorized>
      <div class="text-center">
        <p>Manage your Organization</p>
        <a href="Dashboard">Dashboard</a>
      </div>
    </Authorized>
</AuthorizeView>



```

The `AuthorizeView` component shows the dashboard link only to users with the admin role.

### Making roles available to your Blazor app

One little step is missing to get role support working in your B2B SaaS Blazor application. You need to create an [Auth0 Action](https://auth0.com/docs/customize/actions) that handles the [Post Login trigger](https://auth0.com/docs/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) by adding the user's roles to the ID token.

Read [this article to learn the details about making roles available to your Blazor application](https://auth0.com/blog/role-based-access-control-in-blazor-apps/#Making-Roles-Available-to-the-Application).

Basically, the Auth0 Action you need to create has the following code:

```javascript
exports.onExecutePostLogin = async (event, api) => { 
  const roleClaim = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role';

  if (event.authorization) { 
    api.idToken.setCustomClaim(roleClaim, event.authorization.roles);
  }
}
```

Make sure to deploy and add your Action to the login flow. Read [this article for an introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/).

## Testing Role-Based Access Control in Your Organization

Now it's time to test your Blazor application to ensure that users access it based on their assigned roles.

### Testing as an Organization admin

Run the application and create a new Organization by clicking the *Subscribe* link in the upper right corner of the home page. The newly created user will be assigned the admin role, so after the Auth0 Organization is created, your home page should look like the following picture:

![Blazor B2B SaaS application home page with a link to manage the organization for admin users](https://images.ctfassets.net/23aumh6u8s0i/2sHsCL5X0Jef40upiskLQ5/d57fa0a8511a4f4a7f52e18d77a598ec/homepage-admin-access.png)

Notice the link "Manage your Organization" in the center of the page. Navigating that link, you will see the following page:

![Admin dashboard in a Blazor B2B SaaS application showing the organization name](https://images.ctfassets.net/23aumh6u8s0i/XwvP3tm9SzdyMMlpRh7Do/5ddcd30334cb4ac6e75fd3384799e33b/blazor-app-admin-dashboard.png)

As an admin in the current Organization, you can access the application's dashboard.

### Testing as an Organization member

Now, log out of the application and [add a member to the Organization using the Auth0 dashboard](https://auth0.com/docs/manage-users/organizations/configure-organizations/assign-members) and [assign the member role](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles). You will learn how to add a member to an Organization through your application's dashboard in a future article.

If you log in to your Blazor app as a member user, you'll get the following home page:

![Home page of a Blazor B2B SaaS application for a member user, without the organization management link](https://images.ctfassets.net/23aumh6u8s0i/7qHAZhM7Ls7HZAdk565eQA/5cf22a865c4f1b6b08dc194aeeb7a88d/homepage-member-access.png)

As an Organization member, you will not see the link to access the application dashboard.

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

## Recap

In this article, we walked through setting up Role-Based Access Control (RBAC) for a B2B SaaS Blazor application using Auth0 Organizations. Basically, you learned how to create roles like "admin" and "member" using the Auth0 Management API and then assign them to users belonging to an Organization.

You also set up an Auth0 Action to add user roles to the ID token for your Blazor app.

Finally, we showed how to protect routes and content using the `Authorize` attribute and the `AuthorizeView` component based on these roles. We tested with both admin and member roles to confirm that RBAC was working, making sure only the authorized users could get into the dashboard.

You can find the final code of the sample project implemented throughout the article [here](https://github.com/andychiare/MyBlazorSaaS/tree/roles-organizations).

In a future article, we will add the ability to create new users to the dashboard. Stay tuned!

Implementing Role-Based Access Control in Your Blazor B2B SaaS Application

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

Generative AI is everywhere, and since not every user has access to all data, learn how to use retrieval-augmented generation with fine-grained authorization to ensure that private information stays private.

Build Trustworthy AI: Implementing Access Control for RAG Systems Using FGA

Michelle Agroskin

Michelle Agroskin is a Staff Product Marketing Manager for Okta. She leads the Customer Identity AI, Authorization, and Consumer portfolios; driving go-to-market strategy, messaging, launches, and strategic growth initiatives.

She lives in NYC and in her free time, loves to travel the world and try new restaurants!

Staff Product Marketing Manager, Auth0

sam-yapkowitz

I began my career in enterprise software development and got exposure to lots of different frameworks and methodologies. I quickly realized my passion was in the architecture and design of solutions to unique problems. I now get to use these skills to help my customers build high-quality experiences using Okta. When not at work you can find me on the golf course, playing Rocket League or watching football with my friends.

Specialist Solutions Engineer

Sam Yapkowitz

Secure AI agents need more than context. MCP + Auth0 combines identity and control for safe, scalable, autonomous actions.

AI agents are moving from helpful assistants to autonomous actors. They don’t just summarize documents or answer questions—they take actions on our behalf: managing calendars, filing support tickets, and even completing purchases.

To do any of that, they need context. Who is the user? What are they allowed to do? What’s happening in the session?

Today, delivering that context to an agent is messy and ad hoc. That’s where the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2025-03-26/index) comes in—a new specification designed to standardize how context is passed to AI models.

At Auth0, we believe **MCP is necessary but insufficient**.

It’s a great first step, but it **must be paired** **with robust identity and access controls**. Without them, AI agents operate on blind trust, which is a massive security and privacy risk.

This is where identity standards like OAuth 2.0 and OIDC, alongside tools like Auth0, come in.

## The Rise of Capable AI Agents (and Why Context Matters)

AI agents are growing more capable. Developers are building agents that can:

* Query internal systems and databases
* Execute transactions
* Act as customer support reps or internal assistants
* Chain together APIs and services to complete user goals

However, to act effectively and safely, these agents need access to **context**—structured information about the user, their permissions, their past behavior, and their intent. Without context, the agent is just guessing.

Today, there’s no standard way to pass that context. Developers are building custom solutions—often without a strong security model.

## MCP: A Powerful Foundation for Context

MCP is a crucial step toward solving this. Created by Anthropic, MCP provides a standardized payload format for delivering relevant information to AI agents—user identity hints, permissions, claims, and more.

We applaud the teams defining this specification. Standardization helps agents interoperate, improves developer experience, and lays the groundwork for more powerful agent behavior.

But here’s the catch:

> MCP does not secure the payload. It defines _what_ context can be sent—not _who_ can send it, whether they’re authorized, or what the agent can do with it.

This creates significant risk:

* **Anyone** could invoke an agent.
* **Any context** could be injected—true or not.
* **Any action** could be taken on behalf of a user.

MCP is the envelope. But we still need to know who can send it and what the recipient can do with it.

## The Critical Missing Layer: Identity 

Passing sensitive data or enabling agent actions without robust authentication and authorization is dangerous. We can think of MCP without security the same way as an API endpoint without security – both are just communication protocols, and security must be layered on top. The lack of security could cause:

* **Impersonation** – Malicious actors pretending to be someone else (i.e., who is really invoking the agent and providing context?)
* **Data leakage** – Agents receiving context they shouldn’t have access to (i.e., is the context provider authorized to share this specific user data?)
* **Privilege escalation** – Tricking an agent into acting beyond its scope (i.e., can the agent be tricked into performing actions the user isn’t authorized to do?)
* **Compliance violations** – handling sensitive data without proper controls (GDPR, CCPA, HIPAA, etc.)

These aren’t hypothetical. AI agents will soon be responsible for customer interactions, business workflows, and system integrations. We can’t afford to leave their security to chance. MCP needs a robust mechanism to verify the *source* of the context and authorize *what* context is shared and *what* actions the agent can subsequently take. 

Security must be built in—not bolted on.

## Identity Protocols Are the Key

Thankfully, we don’t need to invent a new solution.

> Established identity standards—OAuth 2.0 and OpenID Connect (OIDC)—are perfectly suited to solve this problem.

They are mature, well-understood standards for delegated **authorization** and **authentication** and provide the exact tools MCP needs:

* **OIDC**: Authenticates the entity (user, system, or service) interacting with the agent.
* **OAuth 2.0**: Authorizes what context can be shared and what the agent can do on the user’s behalf—using scopes, access tokens, and delegated permissions.

This makes it possible to:

* Ensure **only authenticated users or systems** can invoke the agent.
* Use **granular scopes** to control what context is sent in the MCP payload.
* Define what downstream **actions** an agent is allowed to take—based on token claims.

As Aaron Parecki notes in [his breakdown of OAuth for MCP](https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol), these protocols map cleanly onto the challenges MCP doesn’t solve.

## Auth0 Is the Bridge

This is where **Auth0 fits in.**

> **Auth0 is uniquely positioned to operationalize secure MCP implementations.** Our platform brings OAuth 2.0 and OIDC to agents to enable more secure and scalable workflows. 

We’re investing in new capabilities designed specifically for AI security, including:

* **User authentication** to easily implement secure login experiences for AI agents, from interactive chatbots to background workers.
* **Token Vault** to securely call APIs like Google, Slack, Spotify, and Github on users’ behalf while seamlessly integrating an application with other products.
* **Async Authorization** to enable autonomous agents to work independently while maintaining user control by getting explicit user approval for critical actions. 
* **Fine-grained authorization for RAG** to enforce granular permissions for document retrieval and helps ensure AI agents only access authorized content. 

![Capabilities and Features](https://images.ctfassets.net/23aumh6u8s0i/6SiMeLDwE0oAw9dSJnQOkF/40ebf7b7f1033880123f93597342ffe2/Capabilities_and_features.png)

And because this builds on existing identity infrastructure, you get the benefits of:

* Developer familiarity
* Reduced integration overhead
* Centralized policy management
* Better auditability and compliance

We make securing AI agents feel like a natural extension of your current Auth0 implementation—not a one-off hack.

## A Real-World Scenario

Let’s walk through what this looks like in practice:

1. A user logs into your customer support portal—powered by Auth0.
2. The app requests an access token with scopes like `read:user_profile`, `read:recent_orders`.
3. Auth0 authenticates the user and issues a signed token containing relevant claims.
4. The application constructs an MCP payload using claims from the token.
5. The AI agent receives the payload, verifies the token, and uses only the authorized context to respond.
6. Later, the user says, “Reorder my last purchase.” The agent requests a new token with the scope `execute:reorder`, prompting the user to re-consent via OAuth.
7. Auth0 issues the new token. The agent performs the action—securely, transparently, and with the user’s permission.

Every step is authenticated. Every action is authorized. Check out more examples on our [documents page](https://auth0.com/ai/docs).

## The Bottom Line: Secure AI Starts with Identity

AI agents are the next interface frontier—but only if we get security right.

> MCP is foundational—but without an Identity solution, it’s not safe for real-world use.

Auth0 provides the missing layer—bringing identity, permissioning, and governance to the world of AI agents. Our platform makes it possible to adopt MCP without compromising on trust, compliance, or control.

[Learn more](http://auth0.com/ai) about securing AI interactions, read our [documentation](https://auth0.com/ai/docs), and [contact us](https://auth0.com/contact-us) to discuss your AI security needs.


MCP + Auth0: An Agentic Match Made in Heaven

37590801?s=460&v=4

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

Software Engineer

Dan Arias

AAA (Authentication, Authorization, Accounting) helps developers secure web apps by verifying users, controlling access, and tracking actions.

Historically, the AAA framework (Authentication, authorization, and accounting) has been deeply tied to network security, particularly in the context of remote access, VPNs, and network devices. However, AAA is a conceptual framework and not a protocol itself, allowing us to apply it anywhere identity and access matter. Instead of a VPN gateway, you’re securing a web application. Instead of a network admin, it’s a customer buying shoes online. The scale gets bigger, the users are external, and the focus shifts toward balancing security and usability, but the AAA principles still fit to help us build robust, secure, and maintainable user-facing applications.

For developers, considering AAA in your design decisions means not only verifying who your users are (Authentication) but also controlling what they can do (Authorization) and tracking their actions for auditing and analytics (Accounting). This holistic approach minimizes security risks, enhances user experience, and simplifies compliance.

## A Framework to Measure Identity Platforms

A good identity platform gives you features out of the box that tackle each component of the AAA triad, transforming a simple login system into a comprehensive identity management system that meets your security and compliance requirements. User data is one of the most precious and valuable assets we handle as developers. As such, when we make the decision to delegate creating and handling the identity of our users to a third-party vendor, we need to ensure that we are getting better security, scalability, and user-centric experience than what we could build ourselves. The AAA framework is a helpful tool to assess whether an Identity-as-a-Service (IDaaS) vendor can help you build application systems that are resilient against threats, aligned with business requirements, and equipped for future growth.

In today’s competitive digital landscape, including identity and security as part of your MVP or existing product is a competitive advantage. A holistic approach to security is not just an option—it’s a necessity. However, not every player in the field can deliver the security the current security and threat landscape requires. Let’s dive into why Auth0 is a robust identity platform that meets the requirements of the AAA framework and why you should consider it as your identity solution of choice.

## Authentication

Authentication is the process of verifying a user's identity before granting access to your application. It answers the question: **"Who are you?"**

* [Seamless User Sign-Up and Login](https://auth0.com/docs/authenticate/login)
    * Auth0 offers multiple authentication methods, such as social logins, passwordless options, and multi-factor authentication (MFA). These features enable quick and secure identity verification.
* [Personable User Experience](https://auth0.com/docs/customize)
    * With customizable interfaces, Auth0 reduces barriers during sign-up and login, ensuring that the verification process is both secure and user-friendly.
* [Relevant User Journeys](https://auth0.com/docs/customize/forms)
    * Auth0 offers customization of the metadata you collect from users or creates a unique authentication journey that serves your business needs while still being secure.
* [Uncompromised Internationalization and Localization](https://auth0.com/docs/customize/internationalization-and-localization)
    * Auth0 can handle different languages across the authentication experience, allowing you to connect authentically and accurately with millions of potential customers across the globe. Auth0 adapts to your users instead of forcing users to adapt to inflexible platforms.

## Authorization

Authorization defines what actions or resources a user is allowed to access once they are authenticated. It answers the question: **"What can you do?"**

Auth0 allows developers to implement flexible yet comprehensive authorization models that fit different threat models.

* [Role-Based Access Control (RBAC)](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Role-Based-Access-Control--RBAC-):
    * Auth0 allows you to set granular permissions by assigning roles to users. This ensures that users only access the features and data relevant to their privileges.
* [Auth0 Actions](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization)
    * Actions are secure  Node.js functions that allow you to modify or complement the outcome of the decision made by pre-configured authorization policies. Developers can use Auth0 Actions to[ handle more complicated cases](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization) than is possible with role-based access control (RBAC).
* [Fine Grained Authorization](https://auth0.com/fine-grained-authorization)
    * Auth0 FGA delivers relationship-based access control ([ReBAC](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Relationship-Based-Access-Control--ReBAC-)) designed for complex authorization needs, such as restricting resource edits to team leads. As a managed service, it scales to handle millions of permission checks per second with minimal latency, eliminating the need to build and maintain custom solutions.

## Accounting

Accounting, also known as auditing, involves tracking and logging user activities within your application. It answers the question: **"What did you do?"**

* [Detailed Logging](https://auth0.com/docs/deploy-monitor/logs)
    * Auth0 maintains a comprehensive audit trail of authentication and authorization events. This detailed logging is essential for monitoring user behavior and identifying potential security incidents.
* [Usage Analytics](https://auth0.com/docs/get-started/auth0-overview/dashboard/activity)
    * The collected data helps analyze user interactions, optimize authentication flows, and ensure compliance with industry regulations. Accounting provides valuable insights into how your application is used.
* [Log Streaming](https://auth0.com/docs/customize/log-streams)
    * Auth0's log streaming service allows you to export tenant log events to a log event analysis service URL, leveraging robust data services, such as DataDog, Splunk, and Amazon EventBridge, and allowing you to react to events like password changes or new registrations with your own business logic.

## Bringing It All Together

Overlaying the AAA framework on your Auth0-powered B2C or B2B solutions ensures:

* **Enhanced Security:**
    * A multi-layered approach that not only verifies identities (Authentication) but also enforces precise access controls (Authorization) and continuously monitors user activities (Accounting).
* **Improved User Experience:**
    * While users benefit from a smooth and secure sign-up process, the detailed authorization rules and accounting measures ensure that they access the right features with confidence.
* **Operational Excellence:**
    * With robust logging and analytics, you can swiftly detect anomalies, refine your application, and maintain compliance with regulatory standards.

If you haven’t tried it already, [get started with Auth0 today](https://a0.to/get-started)!


Authentication, Authorization, and Accounting For Developers

The way to implement an authorization system depends on your application's needs. Let's explore Relationship-Based Access Control (ReBAC) and implement it in a Rails API using OpenFGA.

How to Implement Relationship-Based Access Control (ReBAC) in a Ruby On Rails API?

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

There are different ways to implement an authorization system and the one you choose depends on your application's needs. Attribute-Based Access Control (ABAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

Previously on your access control series \*read with TV show presenter's voice\*... You learned about [Role-Based Access Control (RBAC) and how to integrate it into your Rails API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/).
In this blog post, you’ll continue learning about different authorization systems, this time about Attribute-Based Access Control and how to migrate the access control of the expense management API from RBAC to ABAC. 

<details>
<summary>Starting from here?</summary>

If you want to start this tutorial from the beginning, [start from this blog post.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/)

Clone the application repo and check out the `add-rbac` branch:

``` bash  
git clone -b add-rbac https://github.com/auth0-blog/rails-api-authorization 
```

Make the project folder your current directory:

``` bash  
cd rails-api-authorization
```

Then, install the project dependencies:

``` bash  
bundle install
```

Then, setup the database

``` bash
  rails db:setup
```

Finally, create a `.env` hidden file:

``` bash  
touch .env
```

Populate `.env` using the `.env.example` file:

``` bash  
cp .env.example .env
```

Add your Auth0 configuration variables to the .env file and run the project by executing the following command:

``` bash  
rails s
```

</details>

## What Are Attributes in the Context of Access Control?

Let's consider the use case of the expense management API you are using in this tutorial. For RBAC, you created an `admin` role and assigned it to users using Auth0 Actions. Users with the `admin` role can approve and review expenses, and so far, that's so good. 

The following requirement you have is that only certain users can do certain things on specific expense reports: 

- Users can only see a report they own (submitted by them)
- Users can only see a report if they are the approver
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

With the current RBAC implementation, a user with the `admin` role can do all of these things, but unfortunately, not all admin users need to approve reports. So, as a solution, you think adding these guards to your code sounds good, so **you are going to check the attributes of the report** (the user is either the approver or submitter of this report), the date the report is being approved, etc. 

This practice has a name, and it's called Attribute-Based Access Control.

## What Is Attribute-Based Access Control (ABAC)?

[According to NIST, Attribute-Based Access Control (ABAC)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf) is an access control method where a subject's requests to perform operations on objects are granted or denied **based on assigned attributes of the subject, assigned attributes of the object**, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

In other words, any access decision that your application makes based on attributes of an entity can be considered ABAC and it'll be specific to your application and access control needs. 

ABAC also gives you more control and granularity over your access decisions, making it more flexible than RBAC. 

Regarding the expense management API, RBAC and ABAC can coexist; in fact, checking for a role or permission is also checking for attributes, in this case, attributes assigned to the user, so we can say RBAC is an implementation of ABAC with a limited scope of roles and permissions. So now, let's say it is a requirement that the user also needs to be an admin to perform the approver actions. Why not? 😛 

Let's look at what you'll need to change in your Ruby on Rails API to comply with the new access control requirements and implement ABAC. 

## ABAC Implementation in a Ruby on Rails API

Let's take a look at the requirements you need to implement: 

- Users can only see a report they own (submitted by them)
- Only approvers can see reports submitted by other users
- Only admin users can approve reports
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

Based on this, there are a few changes you could make to the application; most of them are related to the `report` entity. 

Let's think of the scenario where a **user can only see a report they have submitted, or they are the approver**; you could think of this as multiple things like the user needs to have some relationship with the expense report, meaning they are either the submitter or the approver.

There's little we can do with the relationship example now. Still, you can define that if a user is the submitter or approver of a report, they have some **ownership** over it and are allowed to see that report, so let's start there. 

In the API context, you can define this ownership such that **the user making the request is the same user for which we want to see reports.** At the moment, your API doesn't have the context of the user other than an access token, which tells you only that they are authorized to access your API and that they are `admin` because [you added this role as a custom claim in the access token.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Creating-and-Assigning-Roles-with-Auth0)

So, that's great 🫠 how can you get information from the user in your API using Auth0? The answer is by connecting your Auth0 API and your Auth0 Application!

### Connect Your Auth0 API with your Auth0 Application 

If you have a REST API as your backend, chances are you have a frontend application where your users authenticate and manage their data, etc. 

When you use Auth0, your users can authenticate using [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login). So, you need to create an Auth0 Application for either a SPA or a Regular Web Application and [integrate it with your code using one of the SDKs](https://auth0.com/docs/libraries). For this blog post, let's focus on the example of the regular web application. 

[When you created the expense management API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Building-the-Starter-Application), you created an [Auth0 API](https://auth0.com/docs/get-started/apis) and an Auth0 Regular Web Application for testing purposes, well now you are going to use this Regular Web Application because in a real-life scenario, your users will probably authenticate themselves *somewhere* and once they're authenticated you proceed to do X or Y in your REST API. 

In the Regular Web Application you created in Auth0 for your users to authenticate, you need to implement login, logout, etc., and you can learn how to do so by following [any of the Developer Center Guides on Authentication](https://developer.auth0.com/resources/guides?type=web-app). Still, the general process is almost identical in all of them, and the outcome is that **you will get an access token from Auth0 issued for the authenticated user.** 
 
Then, you need to tell your Regular Web Application that your users will be interacting with your REST API and, therefore, its counterpart in Auth0, so when you request the access token, you need to provide the `audience` as well. An example of how to do this in a [Ruby on Rails Web application](https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication) would be: 

```ruby
Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
 :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
 callback_path: AUTH0_CONFIG['auth0_callback_path'],
 authorize_params: {
 scope: 'openid profile email',
 audience: 'https://rails-api-authorization', # pass the audience ✨
 }
 )
end
```

Once you pass the `audience`, you'll get a JWT token containing the information about the user, as well as any scopes and claims you've added. To learn more about the audience parameter [you can check out this post.](https://community.auth0.com/t/what-is-the-audience)

That's all you need to do for now in Auth0 to make this work, so let's get back to the code!

### Validate Ownership of the User Making the Request

You already added a method to check for the user's role, so similarly, you could do the same to check for the user's *ownership*. In the context of the expense management app, we'll say: 

> A user is allowed to see an expense report of another user if they are the subject of the access token 

At the moment, you do not store any information about the user's data in your database, but you will need the Auth0 user's ID to compare it. 

#### Add the Auth0 ID to the User Model

Let's create a migration to add a new field to the User model using the following command on your terminal: 

```bash
rails g migration AddAuth0IDToUsers auth0_id:string 
```

The command above will generate a new migration file under `db/migrate/YYYYMMDDHHMM_add_auth0_id_to_users.rb` that looks like this:

```ruby
class AddAuth0IdToUsers < ActiveRecord::Migration[7.0]
  def change
 add_column :users, :auth0_id, :string
  end
end
```

Then, execute the migration by running `rails db:migrate` on your terminal. 

Now, let's add a validation to the User model to make sure the `auth0_id` field is always present and unique. Go to `app/models/user.rb` and add the following code: 

```ruby
class User < ApplicationRecord
 has_many :expenses, foreign_key: :submitter_id
 has_many :submitted_reports, class_name: 'Report', foreign_key: 'submitter_id'
 has_many :reports_to_review, class_name: 'Report', foreign_key: 'approver_id'

 validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: true
  # 👇 new code 
 validates :auth0_id, presence: true, uniqueness: true
end
```

You're all set from the model level. Let's move to the controller level. 

#### Add the Ownership Validation to the Controller

Go to the `Secured` concern in `app/controllers/concerns/secured.rb` and add the following code: 

```ruby
# frozen_string_literal: true

module Secured
  extend ActiveSupport::Concern

  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
  BAD_CREDENTIALS = {
 message: 'Bad credentials'
 }.freeze
  MALFORMED_AUTHORIZATION_HEADER = {
 error: 'invalid_request',
 error_description: 'Authorization header value must follow this format: Bearer access-token',
 message: 'Bad credentials'
 }.freeze
  INSUFFICIENT_ROLES = {
 error: 'insufficient_roles',
 error_description: 'The access token does not contain the required roles',
 message: 'Permission denied'
 }.freeze
  # 👇 new code 
  NOT_OWNER = {
 error: 'not_owner',
 error_description: 'The access token does not belong to the current user',
 message: 'Permission denied'
 }.freeze
  # 👆 new code 

  def authorize
 token = token_from_request

 validation_response = Auth0Client.validate_token(token)

    @decoded_token = validation_response.decoded_token

    return unless (error = validation_response.error)

 render json: { message: error.message }, status: error.status
  end

  def validate_roles(roles)
    raise 'validate_roles needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_roles(roles)

 render json: INSUFFICIENT_ROLES, status: :forbidden
  end

  # 👇 new code 
  def validate_ownership(current_user)
    raise 'validate_ownership needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_user(current_user)

 render json: NOT_OWNER, status: :forbidden
  end
  # 👆 new code 

  private
  # ... 
end
```

You are adding a new hash called `NOT_OWNER` to specify the error message in case the user is not the owner of the access token being passed. Then, in the `validate_ownership` method, you're checking the access token and returning an error if the user is not the owner. Since you haven't implemented the `validate_user` method yet, let's add it to the token structure. 

Go to your `Auth0Client` class in `app/lib/auth0_client.rb` and add the following code: 

```ruby
# frozen_string_literal: true

require 'jwt'
require 'net/http'

class Auth0Client

  # Class members
  Response = Struct.new(:decoded_token, :error)
  Error = Struct.new(:message, :status)
  Token = Struct.new(:token) do
    def validate_roles(roles)
 required_roles = Set.new roles
 token_roles = Set.new token[0][Rails.configuration.auth0.roles]
 required_roles <= token_roles
    end
    # 👇 new code
    def validate_user(current_user)
 current_user.auth0_id == token[0]["sub"]
    end
    # 👆 new code
  end

  # Helper Functions
  # ...
end
```

The `validate_user` method checks the `current_user` variable (the user from whom you want to check the reports) against the owner of the access token. In the access token, you have information about the user's ID in Auth0 under the `sub` field, so you are comparing that against the `auth0_id` from the local database. 

Next, call the `validate_ownership` method in the `ReportsController`. You want to validate the user's ownership when they request to review or submit a report, so let's add the validation to the corresponding actions. 

Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  def submitted
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(submitter_id: @user.id) # list only reports where user is submitter

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/review
  def review
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(approver_id: @user.id) # list only reports where user is approver

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/1/approve
  # ...
end
```

By adding the `validate_ownership` block in the controller together with the condition inside the query, you are implementing a form of ABAC because you're allowing or denying access based on certain attributes of the user or the report. 

### Validate that Only Approver Users can Approve Reports 

Even though this might be a new requirement, you already took care of this scenario when you first added RBAC. If you look at the `approve` action in the `ReportsController`:

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  # ...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        @report.status = "approved"
        @report.save
 render json: @report
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

The check for `@report.is_approver?(@user)` already confirms that 
 `@user` is the approver of `@report`. This is interesting because sometimes we mix up different authorization models without even realizing it, and that's okay as long as it fits your business model. s

### Validate that Approvals Only on Weekdays

You only have to add another validation to allow users to approve expense reports on weekdays, and this is possible by adding a new check to the `approve` action in the `ReportsController`. Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  #...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        # 👇 new code 
        if Date.current.on_weekday? # can only approve on weekdays
          @report.status = "approved"
          @report.save
 render json: @report
        else
 render json: {message: "Can only approve on weekdays"}, status: 401
        end
        # 👆 new code 
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

[The function `Date.current.on_weekday?`](https://api.rubyonrails.org/classes/DateAndTime/Calculations.html#method-i-on_weekday-3F) returns true if it's a weekday (Mon-Fri) and false otherwise. Users who try to approve during the week will get an error.

At this point, you've fulfilled all the requirements you've received so far! 🚀 It's time to go back to the client and discuss the progress you've made. 

> Up until here, all the changes in the code are available in the [`add-abac` branch of the repository.](https://github.com/auth0-blog/rails-api-authorization/tree/add-abac)

## What About Policies?

You're introducing a lot of extra complexity in the application code that needs to be recreated by each environment, such as web, mobile, CLI, etc. Using a policy engine can streamline application decision-making. 

[A policy](https://csrc.nist.gov/glossary/term/access_control_policy) is a set of rules defining a software service's behavior. There are access control systems like [Open Policy Agent (OPA)](https://www.openpolicyagent.org/), a full-featured policy engine that offloads policy decisions from your software so you don't have to implement it from scratch, or [Policy-Based Access Control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control), where access control decisions are made based on the business roles of users and is combined with policies.

You won't implement PBAC for the sake of this tutorial, but I thought it was interesting for you to know that decision-making engines like these exist.

## Oh, No. What's Next?

You are showing your implementation to the client, and they're satisfied, but as usual, they came back with more requirements 🥲 

- Users who are managers can see the reports of their directs, plus the reports of their directs' directs, and so on 😵‍💫

You think of a way to implement this with your current solution and... recursiveness 🥲 you know this is possible, but you also start exploring what options are out there for these scenarios. You bump into Relationship-Based Access Control, which seems interesting 🤔 because you feel like basing your implementation on the relationships of your users could work, but you need to do more research. 

## Conclusion 

When we talk about attributes, we refer to properties of the entities of your application; in the expense management application example, we are talking about attributes of a user or an expense report. Attribute-Based Access Control is an authorization model that allows you to make decisions based on these attributes. ABAC gives you more granularity than RBAC because you can specify access control on specific resources other than a role that usually includes more than one resource. 

In the next blog post, you'll learn about ReBAC and its implementations. 

How to Implement Attribute-Based Access Control (ABAC) in a Ruby On Rails API?

Sam4-square

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

Sam Bellen

When you are working on a complex web application, at some point, you’ll want to restrict or grant access. In this post we'll explore some of the most commonly used access control paradigms.

Whether you are working on a complex web application, managing a hosting infrastructure, or configuring your company's applications, at some point, you’ll want to restrict or grant access to specific people, groups, or applications, depending on some properties. These can be a role or permission, the time of day or location, or the relationship between two entities. Based on your scenario and the level of complexity, one or more access control approaches might work for you.

## Coarse-Grained (CGA) Versus Fine-Grained Access Control (FGA)

We can distinguish two general strategies based on how granular you want to be when making access control decisions. You either choose a coarse or fine-grained approach.
A coarse-grained approach assigns permissions to a large group of users and resources.
A fine-grained approach looks at the bigger picture, taking into account a lot of different data points and scenarios or assigning permissions to a more limited group of users and resources, or even unique permission per user and resource.

Both strategies have their place, and choosing the level of detail you want to include in your access control decisions might influence the paradigms you can use. For example, a role-based access control usually implements coarse-grained access control, while the relationship-based access control approach is ready to make very fine-grained decisions.

## Role-Based Access Control (RBAC)

The first access control paradigm we’ll discuss in this article is **role-based access control**. It is the most commonly used approach and the simplest to start with. Role-based access control, as the name implies, uses a system of roles and permissions to make a decision.

A role is a collection of permissions that can be assigned to a user, and a permission indicates a certain allowed action that can be performed by any user assigned a role containing this permission. For example, a `guest` role might have permission to view all posts on a website, while an `admin` role could have both a view and delete permission attached to it.

```shell
guest: [
  view:post
]

admin: [
  view:post,
  delete:post
]
```

Your application can either check if the current user has `delete` permissions or has been assigned the admin role. Either scenario will let your app know the user should be able to delete posts. Checking for permissions over roles offers the benefit that your application doesn’t need changes when roles and their permissions change over time.

To get the roles or permissions, your application typically requests them from a user-info endpoint, or your authorization server adds them to the access and/or ID tokens issued when the user is authenticated.

Because we check for permission based on a resource type rather than a specific resource like `post x` or `post y`, RBAC is an example of a coarse-grained access control approach.

## Attribute-Based Access Control (ABAC) or Policy-Based Access Control (PBAC)

**ABAC** or **PBAC** is an access control strategy in which a decision is made based on assessing attributes related to a request or situation. Policies define how these attributes are evaluated. The most common types of attributes are **user** (role, job title, security level), **environment** (time of day, location), **resource** (resource type, data sensitivity), and **action** (read, write, delete). Combining multiple attributes into one or more policies offers a highly customizable and fine-grained solution to grant or limit actions within your applications or systems. The more policies you create, the more control you have over your access decisions, but the harder it becomes to maintain these policies.

An attribute-based access control system often consists of at least a decision engine and a policy language you can use to describe scenarios and their outcome. The same is true for ReBAC, but more on that later.

The decision or policy engine will evaluate data presented in a request against one or more policies written in the policy language. The downside is that you first need to gather the relevant data before passing it to the decision engine for evaluation. This often requires some extra database lookups.

If, for example, you’d like to check if a user can view a document in a parent folder owned by the same user, you’d first need to read the document database table. You'd then search the parent folder for that document and check if a user has access to that folder. Once you’ve done the lookup, you can pass this information to the policy engine to make an informed decision. 

### Open Policy Agent (OPA)

[Open Policy Agent (OPA)](https://www.openpolicyagent.org) is a declarative policy engine that strongly focuses on access control for infrastructure like Docker or Kubernetes containers. Their homepage describes OPA as “Policy-based control for cloud-native environments, flexible, fine-grained control for administrators across the stack.”. This doesn’t mean you can’t use it for other use cases, but it is best suited for managing infrastructure access.

Open policy agents are usually deployed as a “sidecar” beside your applications or infrastructure. This sidecar contains all policies and some relevant data in JSON files. If you run multiple applications, containers, or clusters, it can become a difficult chore to keep all policies and data up-to-date across all OPA sidecars.

Let’s look at an example. If a request comes from an origin we have on a disallow list, the policy engine will return a negative decision. For this to work, we would have written a policy that specifies that the engine looks through a list of blocked origins and checks if the origin, which is part of the request to the decision engine, is part of that list.

OPA policies are written in REGO, a generic programming language that allows you to write detailed policies. Because it is a generic language, it has a steep learning curve and usually takes some time to get used to.

Some [pseudocode](https://play.openpolicyagent.org/p/THKqtQ3QME) for the example above written in [the REGO language](https://www.openpolicyagent.org/docs/latest/policy-language/) would look like the following. 

```shell
deny[reason] {
    disallowedOrigins := ["blocked.com","malicious.com"]

    some input.request.origin in disallowedOrigins
    reason := sprintf("origin %s has been blocked", [input.request.origin])
}
```

Because Policy engines are usually built to make split-second decisions by evaluating a limited dataset against a mostly static set of policies, they are perfect for infrastructure scenarios without constant changes to the data or the policies. Therefore, there’s no need for a scalable, consistent way to add or remove decision data within these engines. 

This might become an issue when dealing with application access control, especially if your application deals with many users who create or manage content. Each time a user performs an action, your application needs to gather all relevant data points before passing them on to the policy engine. Because of this, the latency of your request depends more on how much time it takes to gather this information than on how fast your decision engine can evaluate its policies. As your application scales, so does your data. These lookups can become a bottleneck for fast and reliable access control decisions.

Luckily, the next access control strategy I want to discuss, relationship-based access control, is built just for these use cases.

## Relationship-Based Access Control (ReBAC)

**Relationship-based access control** is a strategy that offers a fine-grained control based on looking at relationships between users and resources, or between multiple (different) resources.

Most ReBAC implementations today are based on Google's Zanzibar paper. In this paper, they describe the system they’ve built internally to handle a variety of access control scenarios across the whole Google ecosystem. This system needs to be flexible enough to handle authorization scenarios for their varied range of products and fast enough not to impact the user’s experience with them. 

To learn more about the Zanzibar paper, visit our informational website [zanzibar.academy](https://zanzibar.academy).

Just like attribute-based access control, ReBAC usually has a decision engine and a modeling language that lets you define relationships the engine will evaluate. New to this paradigm is a database that stores a large and ever-changing set of data related to all users and resources and their relationships. Whenever a user performs an action, this dataset can be impacted.

### OpenFGA 

[OpenFGA](https://openfga.dev) is an open-source solution for Zanzibar-style ReBAC access control. It’s been adopted by the Cloud Native Computing Foundation (CNCF) and actively worked on by members of Okta and the open-source community. OpenFGA uses an easy-to-read domain-specific language (DSL) to model the authorization model and exposes an API to add tuples to a database or query for access control decisions.

<include 
    src="LinkCard" 
    title="Do you prefer a managed ReBAC solution?" 
    link="https://fga.dev" 
    description="Okta FGA is built on top of OpenFGA and takes away the headaches of hosting, scaling, securing, and backing up your data. 
Find out more at fga.dev."
/>

### Direct versus indirect relationships

The relationships defined in the authorization model can be either direct or indirect. Simply put, direct relationships are directly assigned between a consumer and a resource (we call them user and object) and stored in the database. Indirect relationships are the relationships we can infer based on the data and the authorization model. 

We can write our first simple authorization model using OpenFGA DSL to define a `user` and a `repository` type. A repository can have a user or multiple users as a relation. Knowing this, we can assign a user as the owner of a GitHub repository by saving the following tuple in the database:

```yaml
type user
type repository
  relations
    define owner: [user]
```

```json
{
  user: "user:sam",
  relation: "owner",
  object: "repository:fga-demo"
}
```

When we ask the decision engine whether user `Sam` is the owner of the `fga-demo` repository, the engine looks in the database, finds the tuple, and gives us a positive response.

The true power of ReBAC lies in its ability to calculate indirect relationships—relationships that are not explicitly defined but can nonetheless be found between a user and an object. If we expand the GitHub example and add an organization, we can check whether members of that organization can commit to a repository owned by that organization, even if they are not directly assigned as a `repo_writer`.

```yaml
type user
type organization
  relations
    define member: [user]
    define repo_writer: [user] or member
type repository
  relations
    define owner: [organization]
    define can_commit: repo_writer from owner
```

```json
{
  user: "user:sam",
  relation: "member",
  object: "organization:okta"
},{
  user: "organization:okta",
  relation: "owner",
  object: "repository:fga-demo"
}
```

Given this new model and these two tuples, we can query for some direct and indirect relationships.
- Direct: `Sam` is a `member` of the `Okta` organization 
- Direct: The organization `Okta` is the `owner` of the `fga-demo` repository
- Indirect: `Sam` is a `repo writer` for the `fga-demo` repository
- Indirect: `Sam` can commit to the `fga-demo` repository

By examining the relationships between users (consumers) and objects (resources) instead of a static list of roles and permissions, Rebac offers a highly flexible and powerful way to deal with fine-grained authorization decisions within applications.

## Hybrid Access Control Solutions

While most access control products, services, or libraries started out with a specific approach in mind, many of them added (partial) support for other paradigms to be flexible, all-in-one solutions.

Using **OpenFGA**, [Contextual Tuples](https://openfga.dev/docs/modeling/token-claims-contextual-tuples) allow authorization checks that depend on dynamic or contextual relationships not written to the OpenFGA store, enabling some attribute-based access control (ABAC) use cases. For example, allow or disallow an action based on the time of day. You can also use [conditions](https://docs.fga.dev/modeling/basics/conditions) to make your authorization models more flexible.

**OPA** was originally created to deal with ABAC for infrastructure. There are some initiatives, like [TOPAZ](https://www.topaz.sh), that are adding a database to the system, allowing it to make decisions on a larger, more dynamic dataset, just like ReBAC does, avoiding the need to gather all relevant data before asking your policy engine for a decision.

[OPAL](https://www.openpolicyagent.org/integrations/opal/) is another initiative that adds an administration layer to OPA. This layer helps you sync the policies and data in your OPA sidecars across your agents.

## Conclusion

There is **no magic bullet for dealing with authorization in all scenarios** we, as application builders, have to face. 

Considering which approach works well for your situation will help you scale your authorization decisions as your application or infrastructure grows more complex. So, ask yourself whether you’re looking for a simple role-based or finer-grained solution. An attribute or policy-based approach might work great if you're dealing with infrastructure. Still, a relationship-based approach might be the best solution for complex applications, saving you from doing some extra database lookups before making each access control decision.

An Overview of Commonly Used  Access Control Paradigms

There are different ways to implement an authorization system and the one you chose depends on your application's needs. Role-Based Access Control (RBAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

How to Implement Role-Based Access Control (RBAC) in a Ruby On Rails API?

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

Samuel Frank

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

Senior Product Manager

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

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

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

## NFTs in Identity and Access Management (IAM)

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

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

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

## Token Gating

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

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

## EVM Compatible, Open Source Coming Soon

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

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

## Unlocking NFTs for Your Application

### How it Works

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

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

### Installation

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

## What’s Next?

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

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

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

1Vitor de Sousa_Auth0

As Regional Vice President, Vitor de Sousa supports Okta and Auth0's German customers in achieving their Identity and Access Management goals. With more than 20 years of experience in the consumer goods industry, as well as in technology and software sales, he develops strategically smart and creative solutions for the interplay of identity authentication, customer experience, and data protection.

Regional Vice President, Enterprise Sales - Germany

Vitor de Sousa

Partnering with a provider to centralize identity lets you maintain control over your data without compromising user experience

Consumers expect the web apps and services they use to be intuitive while also requiring secure and private transactions and a low-friction experience. A good example of this is the increasing demand for biometrics, the use of a person’s physical attributes like a fingerprint or face scan to prove identity and control access. Consumers have become accustomed to the security and convenience that using a fingerprint to unlock their smartphone offers, so using the same technology to secure your web app is an intuitive way to help secure their account data.

[Auth0’s recent global survey](https://info.auth0.com/erwartungen-und-realitat.html), including more than 2,000 consumers and 200 IT/marketing decision-makers in Germany, found that 31% of German consumers are more likely to sign up for a service if it offers biometric authentication. Yet only 17% of German businesses offer this feature. SO biometric authentication is one way for businesses in the DACH region to better align themselves with their customers’ expectations for security without compromising their customer experience (CX). 

Partnering with an [Identity as a Service (IDaaS)](https://auth0.com/blog/what-is-idaas/) provider who understands how to combine an intuitive user interface with strong security measures like that offered by biometrics can bring additional benefits to your organization. For example: freeing your in-house development talent to focus on your core product, helping you meet regional data privacy regulations, and maintaining active control over your user data.

## Let Your Internal Talent Focus on Your Core Product

Germany is not only the largest economy in the EU; it is also home to the largest software developer talent pool in the region. [As of 2019](https://www.cbi.eu/market-information/outsourcing-itobpo/software-development-services/market-potential), there were more than 900,000 developers in the country, with a majority describing themselves as [Full-Stack front-end developers](https://insights.stackoverflow.com/survey/2021). To ensure your in-house dev teams can focus on those strengths, don’t distract them with an identity project. At Auth0, identity is our core product. Our teams built, maintained, and enhanced a Customer Identity and Access Management (CIAM) platform that incorporates industry security standards, an expert understanding of regional data privacy regulations, and a highly customizable set of integrations to bring you exactly the right mix of security, privacy, and CX.

Our identity specialists bring their expertise and knowledge to secure your authentication and authorization processes while also bringing your customers the tailored, low-friction CX they expect. That allows us to help you build a solution that will be capable of incorporating your needs in the present — while remaining extensible enough to scale with your plans for the future. 

The centralized identity solution you build will unify authentication for your platforms, services, and web apps. This single source of truth (SSoT) for your customer identity data is easier to secure than disparate, siloed data stores for each system. It also limits your attack surface by eliminating multiple access points and login boxes. 

By partnering with Auth0, you get a centralized identity platform that’s ready to be customized by your developers to meet your precise requirements. And our extensibility allows that platform to be readily extended to cover all of your existing properties, whether they’re modern cloud-based apps or legacy on-prem systems.

## Understanding Data Privacy Regulations in The DACH Region

EU Member States are allowed to enact national privacy rules to supplement, specify, and modify the GDPR rules as applied to their citizens. It’s important that companies familiarise themselves with these rules that often govern specific situations.

This document is not intended to act as legal advice. Please consult your legal counsel to ensure you are in compliance with all applicable data privacy laws and regulations.

The right to privacy is well established and respected in the DACH region, where such legislation existed long before the GDPR. Today there are additional rules such as the new German Privacy Act (BDSG-new) along with industry-specific regulations for, e.g., telecommunications, banking, and energy. In Austria, too, we see local regulations like the [Federal Act on the Protection of Individuals With Regard to the Processing of Personal Data (DSG)](https://www.dataguidance.com/notes/austria-data-protection-overview), all designed to put the privacy rights of citizens first.

[Switzerland](https://www.dataguidance.com/notes/switzerland-data-protection-overview) has a slightly different take on data protection regulations as well. In addition to GDPR, there are two additional laws that impact data collection and processing there. The first is Article 13 of the Swiss Constitution, which protects Swiss citizens’ rights to privacy in personal and family life, as well as within the home. Meanwhile, the Federal Act on Data Protection (FADP) solidified the language governing how those rights are protected in regards to digital data. Unless you have a team of lawyers and governance specialists for your developers to work with, making sure you’re in full compliance with all of these regulations will soak up a lot of internal resources. Partnering with an IDaaS provider can alleviate these additional strains by taking on the task of helping to assure compliance.

The DACH data privacy landscape can seem complex, and the responsibility for coding privacy into your applications often falls to the people building them. By partnering with Auth0, your developers can help you protect your customer’s personal information without becoming privacy experts themselves. Auth0’s key privacy-enabling features include:

* Easy access to user profiles to enable removal requests
* To export a user’s data in JSON format for data portability
* To enable Log Streaming for continuous security monitoring
* The knowledge that your data is stored locally at an AWS facility in Frankfurt

## Great Customer Experience Includes Choices for Data Location

Part of ensuring your customers get the experience they expect is maintaining control over the data they share when they create an account. Consolidating that data into an SSoT simplifies continuously monitoring its security and detecting threats and other anomalies. Having choices with respect to the location where your data is stored is another asset of partnering with an IDaaS provider like Auth0.

### Data security certification

Auth0 brings knowledge of [regional privacy regulations](https://auth0.com/docs/compliance/gdpr), along with internationally recognized certifications from organizations such as the International Standards Organization (ISO) [27001](https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-2:v1:en) and [27018](https://www.iso.org/standard/61498.html), along with a[ SOC 2 Type II audit](https://auth0.com/blog/auth0-achieves-soc-2-certification/). These are third-party verified certifications, meaning a specialized auditing body has signed off on the security of our processes, infrastructure, [platform](https://assets.ctfassets.net/kbkgmx9upatd/2KxmM5BICQ4GKgeIwA0sKu/d4f59bd579803593edcd571f1aa92ef0/Auth0_Platform_Operations.pdf), policies, and continuous monitoring framework. Auth0 complies with [additional regulations](https://auth0.com/de/security) as well, BaFin, EBA, and HIPAA for example. 

### Customizable user interfaces

[Auth0 Marketplace](https://marketplace.auth0.com/) offers integrations with major line-of-business software, while our [Actions](https://auth0.com/actions) capability allows your developers to work with these integrations with everything from drag and drop to a full Javascript editor. This ease of integration and customization means you can create your login box once and use it across properties.

### All your user data in one place

Being cloud-native gives Auth0 the flexibility to offer multiple data storage options. Access is a key piece of data residency. For organizations in the DACH region, we offer [private cloud deployment options on Microsoft Azure](https://auth0.com/blog/auth0-on-microsoft-azure-as-a-private-cloud-deployment-option/) or AWS infrastructure, as well as public cloud options using an AWS facility in multiple regions such as Frankfurt to help our customers achieve compliance. 

### Iterative deployment to ensure buy-in across the organization

Deploying a new identity and access management system can be a lengthy and complex process from a business perspective. Partnering with Auth0 and taking advantage of our identity experts allows for an iterative deployment and a smooth migration that does not jeopardize the user experience by offering frictionless user migrations without password resets. That way, each department or product team can witness a successful roll-out before giving their buy-in without straining your in-house talent. Cross-departmental collaboration is key to any software project, particularly when that software controls data access, and having a successful proof-of-concept (POC) in hand can help secure buy-in as you move forward.

Work with an identity partner that understands your need for a great digital experience without compromising the security and privacy of your customer data. [Reach out to our identity experts](https://auth0.com/contact-us) when you’re ready to continue the conversation or to find out how to start working with Auth0 today.


Centralize Identity For Security and Customer Experience

What is the best way to apply Role-Based Access Control (RBAC) to your ASP.NET Web API? Let's find out together.

Role-Based Authorization for ASP.NET Web APIs

Checking user permissions allows you to have more control over access to your ASP.NET Web API.

Protecting a Web API from unauthorized users is the first step to get control over who can access it. However, simply excluding anonymous users may be insufficient in some situations. You may need to control over who can do what on your application. This article will show you how to define and check permissions for users accessing your ASP.NET Web API secured with Auth0.

## The Need for Permissions

A previous article introduced [how to enable authorization for ASP.NET Web APIs](https://auth0.com/blog/aspnet-web-api-authorization/). The sample application accompanying that article is an ASP.NET Web API that implements the CRUD (*Create*, *Retrieve*, *Update*, *Delete*) operations over a glossary of terms. That article explains how to protect the Web API by using Auth0 so that only authorized users can create, modify, and delete glossary items. Everyone can still get the list of terms or a single glossary item.

That worked pretty well! However, you may need more granular control over the users who can do specific operations. For example, you may want to give some users the ability to add a new glossary term or modify an existing one, but you don't want them to delete items. Only specific users should be able also to delete items. To achieve this control level, you must deal with permissions.

In the security context, a **permission** is a property of a resource that indicates the operation a user can do on it, like, for example, read, write, print, send, etc. In the case of your sample application, you have the glossary and term resources. Regarding the former, you can get the list of terms and add new items. Regarding the latter, you can read, update, or delete it.

<details>
  <summary>Permissions vs. privileges</summary>
Usually, permissions and privileges are used interchangeably, but technically they have precise and different meanings in the context of computer security.


A **permission** is an action that can be performed on a resource. It is somehow bounded to the resource, and you can consider it as a resource property.

A **privilege** is a permission assigned to a user or an application. When you assign the writing permission to a user, you are granting them a privilege.
</details>

## Setting up the Web API Application

The goal of this article is to show you how to implement permission-based authorization in this sample application. 

> Make sure you have [the latest .NET SDK](https://dotnet.microsoft.com/download/dotnet/current) already installed on your machine to run the sample ASP.NET application.

So, let's start by downloading the source code with the following command:

```bash
git clone --branch add-authorization --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git
```

Once you download the application, register it with Auth0 in order to enable support for the authorization service. If you haven't an Auth0 account, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Follow the [instructions in this article to register the application with Auth0](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0).

After you completed the registration, move to the `glossary-web-api-aspnet` folder and open the `appsettings.json` configuration file. Its content looks as follows:

```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested in [the mentioned article](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0)).

> Note: Your Auth0 domain is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

Now, launch the ASP.NET Web API application by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see the [Swagger UI](https://swagger.io/tools/swagger-ui/) shown below to test the API interactively:

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

To call the `POST`, `PUT`, and `DELETE` actions, [you need an access token, as explained in this section](https://auth0.com/blog/aspnet-web-api-authorization/#Testing-the-Secure-Web-API).

Now you are ready to set up permissions on your Web API.

## Defining Permissions for an API

The first step is to define the permissions for your application. These permissions can vary depending on the needs of your application. In the glossary Web API application, we are going to define the permissions identified by the following strings:

- `create:term`. This permission allows you to add a new term to the glossary.
- `update:term`. With this permission, you can update an existing term.
- `delete:term`. This permission allows you to delete a term from the glossary.

To associate these permissions with your API, go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard and select the API you defined for the glossary application. Then select the *Permissions* tab. Here you can add the permissions with their descriptions as defined above. At the end of this process, that page will look like the following:

![Defining permissions in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52FOUrB7EcV17WYLSjdbDS/19d1360d9def0ea77cc550ba664a7748/defining-permissions-auth0-dashboard.png.png)

This configuration informs Auth0 that the glossary Web API supports only these permissions.

Next, move to the *Settings* tab and scroll down to the *RBAC Settings* section. Here, click both the *Enable RBAC* and the *Add Permissions in the Access Token* toggle buttons, as in the following picture, and don't forget to click the *Save* button at the end:

![](https://images.ctfassets.net/23aumh6u8s0i/49AQnZIW5pP4wBIHA4sV9i/2c476e2508ff68fde80061b6973016ca/enabling-rbac.png)

These settings will enforce the evaluation  of roles and permissions assignments during the user login.

> Although we will not use roles in this article, you still need to enable RBAC (Role-Based Access Control) support.



<details>
  <summary>Permissions vs. scopes</summary>
When defining the API permissions in the Auth0 Dashboard, you find the term *scope* next to the term *permission*. You may think that they are synonymous, but they actually aren't. Both describe the actions that can be performed on a resource, but they are used in different authorization scenarios.

**Permissions** are used in a [first-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#first-party-applications), i.e., when the same organization or person controls both the client and the server applications.

**Scopes** are used in a [third-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#third-party-applications), i.e., when different organizations control the client and the server applications.

In the latter scenario, the client application asks for one or more permissions to operate on a specific resource on behalf of the user. This requested permission is a **scope**. Usually, scopes limit what an app can do on behalf of the user, and the user may grant them to the application or not.

Scopes have been [introduced by OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) in the context of delegated authorization.
</details>

## Checking Permissions in an API

As the next step, you need to check that the user calling your API has the proper permissions. You can accomplish this task by defining one or more authorization policies and applying them to the controller or the methods that implement your ASP.NET Web API.

An **authorization policy** is a set of requirements that users or applications must meet in order to be allowed to perform an action on a resource. Let's see how you can define and apply an authorization policy in practice.

### Registering an authorization policy

To define an authorization policy for the glossary Web API, open the `Startup.cs` file in the root folder of the project and append the following code to the body of the `ConfigureServices()` method:

```csharp
// Startup.cs

// ...existing code...

namespace Glossary
{
  public class Startup
  {
    // ...existing code...
    
    public void ConfigureServices(IServiceCollection services)
    {
      // ...existing code...
      
      //👇 new code
      services.AddAuthorization(options =>
      {
        options.AddPolicy("WriteAccess", policy => 
                          policy.RequireClaim("permissions", "create:term", "update:term"));
        options.AddPolicy("DeleteAccess", policy => 
                          policy.RequireClaim("permissions", "delete:term"));
      });
      //👆 new code
    }
    
    // ...existing code...
  }
}

```

You invoked the `AddAuthorization()` method to configure the ASP.NET authorization service. To this purpose, you defined two authorization policies via the `AddPolicy()` method of the `options` parameter. Each policy has a name and a lambda expression. For example, the `WriteAccess` authorization policy is defined by requiring the `permissions` [claim](https://auth0.com/docs/tokens/json-web-tokens/json-web-token-claims) in the access token whose value can be `create:term` or `update:term`. Similarly, for the `DeleteAccess` policy.

### Authorization policy approaches

You defined two authorization policies based on the permissions you defined for the API in the Auth0 Dashboard. Both policies are based on requiring the existence of claims with specific values. This is the simplest way to define an authorization policy in ASP.NET. It is usually referred to as [claim-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims).

If you have more complex criteria for defining your authorization policies, you need to use the [policy-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) approach. For example, if you want to be sure that the issuer of the `permissions` claim is your [Auth0 tenant](https://auth0.com/docs/get-started/create-tenants), you can define your `WriteAccess` authorization policy as follows:

```csharp
options.AddPolicy("WriteAccess", policy => 
                    policy.RequireAssertion(context =>
                       context.User.HasClaim(claim =>
                         (claim.Type == "permissions" &&
                          (claim.Value == "create:term" ||
                           claim.Value == "update:term") &&
                          claim.Issuer == $"https://{Configuration["Auth0:Domain"]}/"
                         )
                       )
                    )
                  );
```

In this case, you used the `RequireAssertion()` method to build a boolean expression that evaluates your specific criteria. In particular, this criteria checks that the `Issuer` property of the claim matches the URL of your Auth0 tenant.

> Note that claim-based authorization is just a specialized case of policy-based authorization.

If you have more specific needs, you can even [customize the built-in ASP.NET authorization middleware](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/customizingauthorizationmiddlewareresponse).

### Applying an authorization policy

Once you define and register your authorization policies, you can apply them in your Web API. Applying an authorization policy is just a matter of passing parameters to the `Authorize` attribute. So, open the `GlossaryController.cs` file under the `Controllers` folder and apply the changes outlined in the following:

```csharp
// Controllers/GlossaryController.cs

// ...existing code...

namespace Glossary.Controllers
{
  [ApiController]
  [Route("api/[controller]")]
  public class GlossaryController : ControllerBase
  {
    // ...existing code...

    [HttpPost]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Post(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpPut]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Put(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpDelete]
    [Route("{term}")]
    [Authorize(Policy = "DeleteAccess")]    //👈 changed code
    public ActionResult Delete(string term)
    {
      // ...existing code...
    }
  }
}
```

This way, you are requesting the ASP.NET authorization middleware to evaluate a specific policy to authorize the execution of the related controller's method.

Your Web API is ready to run and check permissions!

## Testing Permissions

To test the new glossary Web API, you are going to simulate users accessing the endpoints with different permissions. For this simulation, you will interact with the API through the Swagger UI by providing an access token. So, launch the Web API by typing `dotnet run` in a terminal window and point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger).

### Testing access without permissions

Let's try to access a protected endpoint with an access token not bound to any permissions. Go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard, select the API related to the glossary app, and select the *Test* tab. Here you can get a token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copy access token](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Bearer token in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

> To learn a bit more about the Swagger UI, check out [this article about ASP.NET Web API authorization](https://auth0.com/blog/aspnet-web-api-authorization/).

Now, try to add a new glossary term through the `POST` action. You should get a negative response from the server similar to this one:

![Forbidden action on an endpoint](https://images.ctfassets.net/23aumh6u8s0i/2jJfEWsECwVKy9qwcy7Nyk/182e158601d78774ee3fd633028badea/forbidden-action-on-endpoint.png)

Notice that, this time, you didn't receive the `401 Unauthorized` HTTP status code. You received the `403 Forbidden` status code. This denotes that you are providing an access token, so you are authorized to access the application, but you don't have the required permissions to perform this specific action.

You can verify your current permissions by visiting [jwt.io](https://jwt.io/) and pasting your access token there. This tool allows you to decode your access token. You will discover that the `permissions` claim shown in the payload section is an empty array, as in the following picture:

![Empty permissions claim in JWT](https://images.ctfassets.net/23aumh6u8s0i/5bMNrF4vS9iYs3hQuxCMe2/d8bffd83f61373f5b9a6e2b0d69691b6/empty-permissions-claim-in-jwt.png)

### Testing access with writing permissions

Let's create an access token with the required permissions for adding a new term.

Back in your API configuration page on the Auth0 Dashboard, select the *Machine to Machine Applications* tab. You'll get a list of applications, some of them with the *(Test Application)* label in the name. These applications are automatically created by Auth0 when you create an API there. They are meant as test clients from your API. One of them should have the *Authorized* switch on. Click the dropdown next to it and check the `create:term` and `update:term` permissions in the section that will be shown:

![Writing permissions assignment](https://images.ctfassets.net/23aumh6u8s0i/1noHOvxBZaRERXAJ9SpPt2/849b32e5f54524cc3e6f3e58eb1f3578/assign-writing-permissions.png)

Then, click the *Update* button, move again to the *Test* tab, and copy the new token that has been generated for you. Now, in the Swagger UI of your Web API, click the *Authorize* button again. This time the following window should appear:

![Changing the access token](https://images.ctfassets.net/23aumh6u8s0i/1WKMrki5ZtwLPvBKmoQ1Gv/b276253e73ed5848f804ac69a37718d3/changing-access-token.png)

Click the *Logout* button and paste the new access token in the text box that appears.

At this point, try again to add a new term to the glossary through the `POST` action. Now you should get a successful response from the server.

If you decode your new access token in [jwt.io](https://jwt.io/), you should see that the `permissions` claim now contains the two permissions you assigned:

![Writing permissions in JWT](https://images.ctfassets.net/23aumh6u8s0i/WVVEcOwuIeuB73aYKu0Q0/e8a722919757b259befd52ddc09dfdf5/writing-permissions-in-jwt.png)

If you attempt to delete the newly created term with the same access token, you get the `403 Forbidden` status code as before. In fact, your access token doesn't contain the deleting permission.

### Testing access with deleting permissions

To be authorized to delete a glossary term, you need to grant the deleting permission to the test application. So, go back to the *Machine to Machine Application* tab of your API configuration on the Auth0 Dashboard and open the permissions section of the test application again. Check also the `delete:term` permission and click the *Update* button. Now, in the *Test* tab, copy the new access token and head back to your browser.

In the Swagger UI of your Web API, replace your current access token with the new one by using the *Authorize* button. Then, delete the glossary term you added earlier by using the `DELETE` action. This time your attempt should be successful!

## Recap

In summary, you learned that permissions give you more granular control over access to your Web API. You discovered how to define permissions associated with your API in Auth0 and how to define and register authorization policies in your ASP.NET application. You saw that checking permissions in your API controller is a matter of adding a parameter to the `Authorize` attribute. You used your test client application on the Auth0 Dashboard to generate access tokens with the required permissions. Finally, you used the Swagger UI to test your Web API with access tokens having different permissions.

You can download the final code of the sample application from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-permission).


Permission-Based Security for ASP.NET Web APIs

500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Antonello Zanini

Learn how to implement custom error handling logic in Spring Boot. You will see two approaches based on the @ControllerAdvice annotation. Similarly, you will learn how to deal with authentication and access denied errors in Spring Security.

Get Started with Custom Error Handling in Spring Boot (Java)

adam-nunn

I'm a security and compliance professional with a passion for emerging cloud technologies. I specialize in risk, privacy regulations, and industry-standard security frameworks.

Sr. Director of Governance, Risk, and Compliance

Adam Nunn

Learn how ISO 27018 controls help cloud service providers reduce security risks for personal data.



ISO 27018 is the first international standard created specifically for [data privacy](https://auth0.com/blog/data-privacy-101/) in cloud computing. Its main objective, according to the [International Organization for Standardization (ISO)](https://www.iso.org/standard/76559.html), is to establish “commonly accepted control objectives, controls, and guidelines for implementing measures to protect Personally Identifiable Information (PII).”

ISO 27018 is part of the ISO 27000 family of standards, which define best practices for information security management. ISO 27018 adds new guidelines, enhancements, and security controls to the ISO/IEC 27001 and ISO/IEC 27002 standards, which help cloud service providers better manage the data security risks unique to PII in cloud computing.

Although ISO 27018 is not a law, there are a number of benefits to following its guidelines and earning certification (more on this below). And since [the standard isn’t free](https://www.iso.org/standard/76559.html) to the public, we’ve combed through it to help you make intelligent decisions on compliance and certification.

Below are the most important things you need to know about ISO 27018 and why it’s a good idea to follow.

## Version “2019” vs. “2014” - What’s New?

ISO 27018 was first created in 2014 (ISO/IEC 27018:2014) and was last revised in 2019 (ISO/IEC 27018:2019). The differences between the two versions are minor and do not change the best practices for protecting PII in cloud computing and public cloud applications in any major way.

As ISO states in Section 2 of the 2019 version, “This second edition cancels and replaces the first edition (ISO/IEC 27018:2014).” It goes on to explain that the revisions are primarily to correct an editorial mistake in Annex A.

However, **one noteworthy revision to point out**, from a certification standpoint, is that ISO 27018 is no longer referred to as a “standard” within the document itself. Instead, the latest revision replaces all mentions of “standard” with the word “document.”

In plain English, that means **ISO 27018 is now considered a set of guidelines and controls that enhance ISO 27001** (the standard for building an information security management system or ISMS), rather than a standard for organizations to certify against.

Cloud service providers should instead certify against ISO 27001 using 27018 guidelines in the event that they process PII.

## Why ISO 27018 Compliance Is Beneficial

[A study by PWC](https://www.pwc.com/us/en/services/consulting/library/consumer-intelligence-series/cybersecurity-protect-me.html) found that “85% of consumers will not do business with a company if they have concerns about its security practices.” Simply put, ISO 27018 compliance is a competitive advantage for both cloud service providers and their customers:

* **For cloud service customers**: If you can show consumers that their data is protected by comprehensive PII protection standards (by working with cloud service providers that follow ISO 27018), they’ll be more likely to do business with you.
* **For cloud service providers**: If you’re ISO 27018-compliant, it makes it easier to close deals with prospective customers because you can say, “We follow the most comprehensive data controls.”

Here are four additional ways ISO 27018 compliance benefits businesses.

### 1. Improved Global Operations

Since ISO 27018 is an extension of ISO 27001, it’s part of an internationally recognized standard. That means it’s easier for cloud service providers to provide assurances on their security practices if they’re doing business globally, as the standard is recognized in most countries.

_**Note**: Following ISO 27018 will streamline cloud privacy in many instances, given its global acceptance. However, it’s always important to consult a data privacy attorney skilled in the laws of the specific country you’re trying to do business in to ensure that you’re compliant._

### 2. Improved Security And Legal Protection

Earning the ISO 27001/27018 certification is an important part of establishing a baseline of security for any business that processes data in the cloud. Simply put, following these standards helps you reduce security risk since they are recognized as some of the comprehensive in cloud computing applications.

Implementing ISO 27018 controls and earning a certification also helps protect your business against charges of negligence or recklessness in the event that a breach was to occur.

Negligence charges can often incur more severe penalties ([as Equifax found out in 2019](https://www.theverge.com/2019/7/22/20703497/equifax-ftc-fine-settlement-2017-data-breach-compensation-fund)). But if a business is using a well-defined, risk-based approach to protect users’ personal data, it not only decreases the likelihood of a breach, but that also evidences a company’s focus on security.

The same goes for customers of cloud service providers. Working with ISO 27001/27018-certified cloud providers shows regulators you’re taking important steps to protect your users’ personal data.

### 3. Streamlined Sales Processes

Corporate security is a major friction point for a lot of IT sales deals. ISO 27018 helps reduce that friction because it simplifies the amount of information required for corporate security to sign off.

Instead of a long drawn out inquisition or questionnaire from prospective customers, an ISO 27001/27018 certified cloud service provider can simply have their customers review their Statement of Applicability (a list of in-scope security controls and implementation) to provide them the assurances they need to close the deal.

### 4. Better Security For A Postpandemic World

Cloud computing usage is rising at a significant rate ([spending is up 37% in 2020](https://www.pwc.com/us/en/industries/tmt/library/covid19-cloud-infrastructure.html), according to PwC) due to an [increase in remote work](https://news.gallup.com/poll/321800/covid-remote-work-update.aspx) as a result of COVID-19. This increase has also led to an increase in cyberattacks across the globe, according to [Interpol](https://www.interpol.int/en/News-and-Events/News/2020/INTERPOL-report-shows-alarming-rate-of-cyberattacks-during-COVID-19) and the [U.S. Chamber of Commerce](https://www.uschamber.com/series/above-the-fold/the-evolution-of-cybersecurity-threats-during-covid-19-and-what-you-can-do).

However, while many workers have already returned to the office, as of the end of 2020, [a survey by PwC](https://www.pwc.com/us/en/library/covid-19/us-remote-work-survey.html) shows that remote work will likely stay commonplace even after the pandemic is over. As a result, cloud usage will likely remain high to accommodate remote workers, and ISO 27018 compliance will continue to remain beneficial after COVID-19 is long gone.

## ISO 27018 Controls and Compliance

If you’re serious about following the controls laid out in ISO 27018 or earning an ISO 27001 certification, we highly recommend you read both standards to familiarize yourself with all that is required of you. 

To get a better feel for what you need to prepare for, here is an overview of the controls laid out in ISO 27018 and the process for certification through ISO 27001.

### ISO 27018 Controls Overview

The requirements below are a guideline for cloud service providers on how to update their procedures, technology, infrastructure, etc., in order to follow the controls laid out in ISO 27018.

Some of these recommendations will likely feel familiar, as they show up in regulations like the [GDPR](https://auth0.com/blog/your-quick-gdpr-compliance-checklist/) (just one example of how the ISO 27018 guidelines can help you meet regulatory requirements in different countries):

1. **Always process customer data according to a customer’s wishes**. Basically, you’ll need to show that you’re only using PII the way(s) its owners have explicitly said you can. Meaning, if a user says you’re not allowed to use their information for marketing and advertising, you should have processes for ensuring that never happens.
2. **Help cloud customers provide their users access to their data when they request it**. Or, in plain English, if your customers’ customers want to access their data, you need to have the processes and technology set up to help them do that.
3. **Enable cloud customers to comply with their notification obligations in the event of a data breach**. If breached, cloud service providers should help provide their customers’ visibility into their own data.
4. **Share information with the minimum required parties**. Basically, keep data private unless you’re required to turn it over. This helps keep personal information safe.
5. **Tell your customers about any subprocessors in your contract with them**. This includes notifying your customers about any location(s) where that data is being processed.
6. **Ensure you have a policy for disposing of (or returning) data that is no longer in use**. For example, if a customer ends their service agreement with you, you must have a plan for what to do with their data.
7. **Have your operations regularly reviewed and audited by a third party**. Certification is required annually by a third party. But if you make significant changes to your processing procedures, you’ll also need a third party to review them.
8. **Ensure that every employee with access to your customers’ data is under NDA**. This adds accountability and legal protection in the event that one of your employees is responsible for sharing data when they’re not supposed to.
9. **Ensure that your staff has adequate training**. All of your employees who have access to your customers’ data should be trained to handle it in accordance with ISO 27018 guidelines.

### ISO 27001 Certification Process Overview

As mentioned above, ISO 27018 certification is part of the certification process for ISO 27001 for cloud service providers. Certification for ISO 27001 is required every three years and is determined by an ISO-accredited third party. It typically happens in two stages:

1. **Stage 1: An informal review of your information security management system (ISMS)**. The purpose of Stage 1 is to familiarize auditors with your organization. During this stage, auditors will check up on key documentation and procedures (to ensure they exist).
2. **Stage 2: A formal compliance audit**. In Stage 2, auditors will perform detailed tests of your ISMS against the requirements in ISO 27001 and 27018, looking for evidence that it meets the requirements laid out in the standard. If your ISMS passes this stage, you’ll achieve certification for the year.

After certification, you’ll be required to participate in annual surveillance audits to ensure ongoing compliance. If your ISMS is on the newer side, they could occur several times a year to ensure that everything is in order.

## Are ISO 27018 Controls Worth Implementing?

While the controls laid out in ISO 27018 are not legally required, it’s a really good idea to follow them if you’re a cloud service provider who processes PII&mdash; especially if you’re doing business internationally.

It’s true that the costs of certification through ISO 27001 can be prohibitive for some (certification costs vary from business, depending on the size of your business, the scope of your cloud utilization, etc.). But a data breach isn’t cheap either ([$3.86M](https://www.ibm.com/security/digital-assets/cost-data-breach-report/#/), on average).

And although certification won’t prevent a breach altogether, the controls ISO 27018 recommends certainly can improve your chances of avoiding one (you’ll also have better coverage in the event a breach does occur), even if you don’t pursue a certification.

Especially when you consider the impact a breach can have on your brand ([65%](https://www.centrify.com/media/4772757/ponemon_data_breach_impact_study_uk.pdf) to [80%](https://www.forbes.com/sites/forbestechcouncil/2017/12/08/mind-the-trust-gap-how-companies-can-retain-customers-after-a-security-breach/#40b4b2806c95) of consumers lose trust in a company that’s been breached)!

<include src="asides/AboutAuth0" />


What Is ISO 27018:2019? Everything Executives Need to Know

james-quick

James is a developer, speaker, and teacher with a passion for Web Development. He is a Developer Advocate at Auth0 and has over 7 years of experience in Advocacy and Software Development. In his spare time, he runs a YouTube channel, plays co-ed soccer with his wife, spends time with his dogs, and can solve a Rubik's cube in under a minute.

James Quick

Learn how to create a Twitch bot that allows users to control your Hue lights.



The Developer Relations team at Auth0 has spent a lot of time [streaming on Twitch](https://www.twitch.tv/auth0) this past year. It's been a learning process for us, so recently we've been brainstorming on creative ways to drive engagement during our streams. 

**How can give we give viewers a reason to participate? A way to feel like they are part of the stream itself?**

While I was pondering that question, I was also tinkering with my [Philips Hue lights](https://www.philips-hue.com/en-us) and how to control them with JavaScript ([read the full how-to article](https://auth0.com/blog/how-to-control-hue-lights-with-javascript/)). Anyways, I figured why not combine my Hue lights with a JavaScript Twitch bot for ultimate interaction?

So, follow along to learn how to create a Twitch bot that allows users to control your Hue lights from chat commands!

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

</AmpContent>

<NonAmpContent>


<iframe width="560" height="315" src="https://www.youtube.com/embed/I_MnBUmx7IM" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

</NonAmpContent>

## Getting Started

To run this demo yourself, you'll need to buy Hue lights and a Hue Bridge, both of which can be found on the [Philips Hue website](https://www.philips-hue.com/en-us). If you don't have those, you can still follow along for a fun walkthrough and demo 😃

Outside of the hardware requirements, you'll need to have Node.js installed.

Additionally, you'll need an OAuth Token from Twitch. You can get your OAuth Token [here](https://twitchapps.com/tmi/) by clicking "Connect" and logging in with your Twitch account. Make sure to copy that token as we'll use it shortly.

Lastly, you'll need to create a new JavaScript project. Create a new folder and open it in your text editor of choice. Then, from the command line, you'll want to initialize this as a JavaScript project. I'm passing the `-y` parameter to accept default values.


``` bash  
npm init -y
```

With your project setup create a new file called `app.js` in the root of your project.


## Create A Twitch Bot

To create our Twitch bot, we'll use the [tmi.js package](https://www.npmjs.com/package/tmi.js/v/1.5.0). This package simplifies the process for connecting to a Twitch channel and streaming the comments as they come through.

Start by installing the package.

``` bash  
npm install tmi.js
```

Now, we can initialize the chatbot by adding the connection code. This code comes almost verbatim from the [docs on Github](https://github.com/tmijs/tmi.js#readme).


``` javascript  
const tmi = require('tmi.js');
twitchClient = new tmi.Client({
    options: { debug: true },
    connection: {
        reconnect: true,
        secure: true,
    },
    identity: {
        username: <YOUR_USERNAME>,
        password: <YOUR_AUTH_TOKEN>,
    },
    channels: [<YOUR_CHANNEL_NAME>],
});

twitchClient.connect();
twitchClient.on('message', (channel, tags, message, self) => {
    console.log(message);
    console.log(tags);
});
```

With that code in place, we can run it and should be able to see Twitch chat messages (and tag information) logged to the console. Run the code with the following command.

``` bash  
node app.js
```

After it is started, you'll need to open up your Twitch page, navigate to the "Chat" tab, and type in a message.

![Twitch test command](https://images.ctfassets.net/23aumh6u8s0i/4GjvabZv9QboogTEdtYPAZ/abcbaf8af8c283247d494beafc92c430/twitch-test-command)

Then, look in your terminal!

![Twitch chat log in terminal](https://images.ctfassets.net/23aumh6u8s0i/1Sh1U3uBBVPdzNdknfizlx/25e280632f4556a4671033e66e1c2f49/twitch-command-log)

Easy, right?

## Listen For Specific Commands

Now that we can listen for Twitch chat messages, we inspect the message itself to see if it matches a certain format. For example, typically "commands" in Twitch start with a "!". So, if we wanted to have a command to turn on the lights, it might look like this, `!lightsOn`. That said, here are the commands that we are going to support.

- `!lightsOn`
- `!lightsOff`
- `!lightsRandom`
- `!lightsChristmas`

For now, let's log out if the user enters one of those commands.

``` javascript  
twitchClient.on('message', (channel, tags, message, self) => {
    console.log(message);
    console.log(tags);
    if (message.startsWith('!lightsOn')) {
        console.log('!lightsOn command');
    } else if (message.startsWith('!lightsOff')) {
        console.log('!lightsOff command');
    } else if (message.startsWith('!lightsRandom')) {
        console.log('!lightsRandom command');
    } else if (message.startsWith('!lightsChristmas')) {
        console.log('!lightsChristmas command');
    }
});
```


## Connect Chat Commands to Hue Lights

We can listen for specific commands, so now we need to connect them to the Hue lights. I've included the code snippet for the Hue lights integration, but if you want the full tutorial for how to set those up, [refer to this article](https://auth0.com/blog/how-to-control-hue-lights-with-javascript/). It will walk you through the following steps.

- find the IP of your Hue Bridge
- find the Hue Bridge user
- find the ids for your light(s)

Here's the code for the Hue lights integration. I put it in a separate file called `hueLights.js`.

``` javascript  
const axios = require('axios');

const ids = [3, 4];

const turnLightOnOrOff = async (lightId, on, hue, sat, bri) => {
    try {
        return await axios.put(
            `http://<YOUR_BRIDGE_IP>/api/<YOUR_HUE_USER}/lights/${lightId}/state`,
            {
                on,
                ...(sat && { sat }),
                ...(bri && { bri }),
                ...(hue && { hue }),
            }
        );
    } catch (err) {
        console.error(err);
    }
};

const turnLightsOnOrOff = async (on) => {
    lightIds.forEach((id) => turnLightOnOrOff(id, on));
};

const setLightsToRandomColors = async () => {
    ids.forEach((id) => {
        const hue = Math.floor(Math.random() * 65535) + 1;
        const sat = 200;
        const bri = 175;
        turnLightOnOrOff(id, true, hue, sat, bri);
    });
};

const setLightsForChristmas = () => {
    turnLightOnOrOff(ids[0], true, 27306, 150, 175);
    turnLightOnOrOff(ids[1], true, 1, 150, 175);
};

module.exports = {
    setLightsForChristmas,
    setLightsToRandomColors,
    turnLightsOnOrOff
};
```

With those helper functions in place, we can import them at the top of the `app.js` file.

``` javascript  
const {
    setLightsForChristmas,
    setLightsToRandomColors,
    turnLightsOnOrOff
} = require('./hueLights');
```

Then, we can call the appropriate function based on the chat command like so.

``` javascript  
twitchClient.on('message', (channel, tags, message, self) => {
    console.log(message);
    console.log(tags);
    if (message.startsWith('!lightsOn')) {
        turnLightsOnOrOff(true);
    } else if (message.startsWith('!lightsOff')) {
        turnLightsOnOrOff(false);
    } else if (message.startsWith('!lightsRandom')) {
        setLightsToRandomColors();
    } else if (message.startsWith('!lightsChristmas')) {
        setLightsForChristmas();
    }
});
```

Now that everything's in place, it's time to test.

<AmpContent>
<amp-video controls
  layout="responsive"
  width="480" height="270">
  <source src="https://cdn.auth0.com/blog/javascript-chat-bot-with-hue-lights/testing-lights.mp4"
    type="video/webm" />
</amp-video>

</AmpContent>

<NonAmpContent>

<video controls="controls">
  <source src="https://cdn.auth0.com/blog/javascript-chat-bot-with-hue-lights/testing-lights.mp4">
   Your browser doesn't support HTML5 video. Here is a <a href="https://cdn.auth0.com/blog/javascript-chat-bot-with-hue-lights/testing-lights.mp4"> link to testing hue lights video</a> instead.
</video>

</NonAmpContent>

## Wrap Up

Personally, I think these projects are a lot of fun. I'm looking forward to adding more interaction in Twitch, so make sure to check out the [Auth0 Twitch channel](https://www.twitch.tv/auth0) for more cool stuff to come.


JavaScript Twitch Bot to Control My Hue Lights

Learn how to control Hue lights with JavaScript



[Philips Hue lights](https://www.philips-hue.com/en-us) are easy to setup and control from a mobile app, but what if you wanted to control them from JavaScript? In this article, you'll find out how.

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

</AmpContent>

<NonAmpContent>


<iframe width="560" height="315" src="https://www.youtube.com/embed/_LcRDJPGpwo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

</NonAmpContent>

## Getting Started

First, you'll need to get yourself a bulb or two. You can find lots of options on Amazon. Then, to control your lights programmatically, you need a [Hue Bridge](https://www.amazon.com/Philips-Hue-Stand-Alone-Bridge/dp/B016H0QZ7I) (which is sometimes called a “Smart Hub”) connected to your router.

![Hue Bridge plugged into router](https://images.ctfassets.net/23aumh6u8s0i/lTHXurvtsXX5a3zOVs1jm/9200aa6dea925adc1585ffbcf24192f8/hue-bridge-router)

For details on setting up the hub and your bulb(s), refer to their [official documentation](https://www.philips-hue.com/en-ca/get-started). After you finish this setup, you should be able to control your light(s) from the Hue mobile app.

## Prerequisites

You will need Node.js installed to send HTTP requests to control your bulbs. For making those requests, you need three things.

-   the IP address of your hub
-   a username
-   the ids of your bulbs

You can the first two by following the [official documentation](https://developers.meethue.com/develop/get-started-2/).

To find the id of your bulbs, you'll need to type the following url into your browser.

`https://<HUB_IP>/api/<YOUR_USERNAME>/lights`

This will show you relevant information about your lights. **Note that the top-level object keys are the ids for your bulbs**. Also, take a look at the `state` info for each. We'll be updating the state of our bulbs next.

![BulLight details](https://images.ctfassets.net/23aumh6u8s0i/1YWzHrKAxqlr4uOhTfhpR1/ebd65aec879421255d807ebe55ab6499/light-details)

## Turn Lights On/Off

To control a given light, you'll need to send a **PUT** request to the following endpoint.

``` bash  
http://<HUB_IP>/api/<YOUR_USERNAME>/lights/<LIGHT_ID>/state
```

In that request, you'll need to include a body object with a property of `on` which is set to a boolean. Here's what it would look like to turn on a bulb with an id of 3.

``` javascript  
const test = async () => {
    const url = `http://${process.env.HUE_BRIDGE_IP}/api/${process.env.HUE_USERNAME}/lights/3/state`;
    try {
        return await axios.put(url, {
            on: true,
        });
    } catch (err) {
        console.error(err);
    }
};
test();
```

![White Lights](https://images.ctfassets.net/23aumh6u8s0i/63oqb6iWNL3ZXQhVjhwocj/f3b990c88996738c51e7c3ca9bf17804/white-lights)

To turn that light off, you can set the `on` property to `false`. However, we can do a bit better with this code by creating a general function like so:

``` javascript  
const turnLightOnOrOff = async (lightId, on) => {
    const url = `http://${process.env.HUE_BRIDGE_IP}/api/${process.env.HUE_USERNAME}/lights/${lightId}/state`;
    try {
        return await axios.put(url, {
            on,
        });
    } catch (err) {
        console.error(err);
    }
};
```

Then call it appropriately.

``` javascript  
turnLightOnOrOff(3, true); //turn light 3 on
turnLightOnOrOff(3, false); //turn light 3 off
```

## Set Lights to Christmas Colors

Hue allows you to control the color of your bulb by using values for hue, saturation, and brightness ([HSB](https://learnui.design/blog/the-hsb-color-system-practicioners-primer.html)). Therefore, you can update your `turnLightOnOrOff` function to accept values for each and conditionally pass them in the body of your request.

``` javascript  
const turnLightOnOrOff = async (lightId, on, hue, sat, bri) => {
    const url = `http://${process.env.HUE_BRIDGE_IP}/api/${process.env.HUE_USERNAME}/lights/${lightId}/state`;
    try {
        return await axios.put(url, {
            on,
            ...(hue && { hue }),
            ...(sat && { sat }),
            ...(bri && { bri }),
        });
    } catch (err) {
        console.error(err);
    }
};
```

There is one caveat with the Hue values used in these bulbs. Traditionally, the hue value in HSB is a number between 0 and 360. However, Hue bulbs use a value between 0 and 65,535.

So, if you want to set your bulbs to Christmas colors (one red and one green), create a function like this.

``` javascript  
const setLightsForChristmas = () => {
    const lightIds = [3, 4];
    turnLightOnOrOff(lightIds[0], true, 27306, 150, 175);
    turnLightOnOrOff(lightIds[1], true, 1, 150, 175);
};
```

...and voila!

![Christmas Colors](https://images.ctfassets.net/23aumh6u8s0i/4VVgzbXuV9GSBIjQfes1Oc/815979cd9d8d6be0c5f97220d8028b72/christmas-colors)

## Set Lights to Random Colors

Let's say you want to spice it up a bit and set your lights to random colors. All you need to do is calculate a random hue value for each bulb. You can hardcode the saturation and brightness values to any you prefer.

``` javascript  
const setLightsToRandomColors = async () => {
    const lightIds = [3, 4];

    lightIds.forEach((id) => {
        const hue = Math.floor(Math.random() * 65535) + 1;
        const sat = 200;
        const bri = 175;
        turnLightOnOrOff(id, true, hue, sat, bri);
    });
};
```

...and voila!

![Random colors](https://images.ctfassets.net/23aumh6u8s0i/1kWB0WyK85UeTJugK5H8q3/d5bc91f5172d383b1d17bfd611f5bcbc/random-colors)

## Wrap Up

JavaScript is an empowering language, and I'm excited to explore what other fun ideas I can come up with. I've already tied these hue lights into command bot on Twitch. More on that to come!


How to Control Hue Lights with JavaScript

jenny-obrien

I'm a former business journalist who's fascinated by the intersection of tech and business strategy — in particular how the right solution can transform an idea into reality. I specialize in ROI, data privacy, and identity.

Business Content Manager

Jenny O'Brien

Gain cloud flexibility and agility while maintaining security and control


Amazon famously brought [book publishing “to its knees”](https://mashable.com/2014/07/30/amazon-has-killed-publishers-they-just-dont-know-it-yet/) by dominating distribution, creating eBooks, and transforming the publishing world with its own titles and opportunity for authors to self publish. 

In 2018, [Amazon entered the insurance market in India](https://www.insurancebusinessmag.com/us/news/breaking-news/amazon-set-to-file-for-insurance-licence-111581.aspx). [And in 2019, the U.S.](https://www.geekwire.com/2019/amazon-jpmorgan-roll-new-health-insurance-plans-part-haven-joint-venture/) 

After killing off [car insurance comparison tools](https://www.businessinsider.com/google-kills-auto-insurance-comparison-tool-2016-2), Google’s invested in [insurance agency software](https://www.insurancejournal.com/news/national/2019/01/02/513324.htm) and signaled further interest in the market. 

In other words, digital transformation is already here. 

While industry complexities afford some protection, they offer greater opportunity for insiders, says TechCrunch. 

A recent [J.D. Power survey](https://www.jdpower.com/business/press-releases/2019-us-home-insurance-study) on customer satisfaction with home insurance noted that the home insurance business model was “primed for change” and that “weak points in customer experience offered an opportunity for startups.” 

The other side of the desire for customer experiences that are real-time and online is the fact that FinServs are tasked with protecting hackers’ favorite data targets. And the [global rise in data privacy regulation](https://auth0.com/explore/data-privacy/) makes stronger protections important from customer, legal, and compliance perspectives.

While digital transformation can seem daunting for incumbents relying on decades of legacy code, the right identity solution can create seamless customer experiences while increasing your data protection — even if you’re an incumbent partnering with (or acquiring an) up and coming Insurtech startup.

Forbes expects [XaaS (everything as a service), UX, CX (User/Customer Experience), and digital privacy](https://www.forbes.com/sites/danielnewman/2019/07/14/top-10-digital-transformation-trends-for-2020/#3dfc8bdc76be) to “take center stage” in as a digital transformation trend 2020. Like other industries, the need to streamline services, reduce capital expenditures, and be increasingly agile and innovative is fueling FinServ’s change. But FinServ’s need for security, stability, and high availability kept many systems in On-Prem solutions that have proven expensive to scale and maintain — putting the ability to keep up with evolving customer expectations at risk.

For FinServ’s looking to innovate (or even just keep pace), Public Cloud is often touted as an option, but it isn’t the best choice. Public Cloud outages and uptimes provide a strong reason to go private. Auth0 Private Cloud helps (or eliminate) that risk, by providing a secure, flexible, extensible solution. 

![Deployment Options Diagram](https://images.ctfassets.net/23aumh6u8s0i/23TVeU9N9cKlxxrenpT6hA/ae7991f61be42885833856bed91a74f7/deployment_options_diagram)

## Why Is Private Cloud Particularly Suited for Finserv Environments

For many years, incumbent FinServs have been buffered by deep compliance capabilities and an established customer base. But FinTech disruptors have eroded that edge says a recent PWC [report](https://www.pwc.com/gx/en/financial-services/assets/pdf/technology2020-and-beyond.pdf), in part because successful disruptors are able to offer a stronger customer experience at a lower cost to customers and with less investment. 

To solidify standing and increase the customer base in this environment, FinServ’s need to:

* Improve customer experience
* Keep ahead of evolving data privacy regulations
* Reduce costs without sacrificing cybersecurity

The data that FinServs hold makes them a prime target for hackers — and the sheer company scale usually means millions of breached accounts, rather than thousands. Globally, the increase in data privacy laws like GDPR and CCPA demonstrates that regulators have lowered tolerance for breaches and expect greater protections to be in place. When not implementing features like multi-factor authentication (MFA) can hit an insurer with a large fine, like what happened to [Dutch public insurance company UWV](https://auth0.com/blog/gdpr-fines-hit-these-companies-hard-heres-how-to-avoid-them/), the need for greater security while still ensuring flexibility becomes more appealing.

<include src="TweetQuote" quoteText="The data that FinServs hold makes them a prime target for hackers — how Private Cloud can help."/>

From an identity perspective, let’s take a closer look at what Auth0 Private Cloud can mean for key digital transformation considerations.

### Performance at Scale
The most innovative solution in the world does zero good if it doesn’t offer you the performance you need.  Auth0 Private Cloud offers request-per-second (rps) baseline is higher than public cloud, with the option of adding on capacity up to 1500 rps.

### Reliable High Availability
FinServ is more aware than most industries the dramatic impact of service interruptions, especially given the pressures of changing global conditions. High availability helps guard against those challenges, especially since Private Cloud can be deployed between two regions to provide failover.

### Control & Segregation
Managed Private Cloud offers a fully-isolated development environment that is updated independently from the production environment. Standard Private Cloud is a single instance production environment. Both Standard Private Cloud and Managed Private Cloud meet standards that require all data to be housed within specific regions.

### Free Developers to Improve Customer Experience
For a developer coming up with an innovative solution while working only On-Prem can feel like trying to code while wearing handcuffs — it’s hard to even get your hands on the keyboard. 

To keep up with the pace of customer’s hunger for real-time innovations, streams of data from connected vehicles and smart homes, and the data privacy compliance requirements from laws like GDPR and CCPA, developers need not only the flexibility but also the scale of a [cloud deployment](https://auth0.com/cloud). And they need that deployment to be secure and reliable enough to handle the demands of enterprises whose customers are often interacting during moments of high stress or need.

### Unify Legacy and New Data Stores
Unifying legacy and new data stores can be a giant headache, as well as a source of weeks of downtime without a plug-n-play identity solution that allows bulk imports, but can also streamline user migration without expensive forced password resets – whether unifying stores at a single organization or when an incumbent partners or acquires an insurance startup.

### Support for Different Languages/Architectures (SDK)
Aside from unifying data stores, incumbent companies often rely on a maze of programming languages and architectures. Shutting down one part of the maze can have unexpected consequences if all the interrelationships aren’t fully mapped out or even understood due to poorly commented code or loss of institutional knowledge due to attrition or staffing turnover.

Your devs will be a lot happier (and more productive) when working with an identity solution that can handle multiple programming languages and architectures and already has SDKs (software development kits) that can be dropped into place to provide rapid access to functionality. And the right solution gives you the flexibility to map the maze at your own pace, reducing costs by removing unnecessary middleware, maintenance, and security as you deem appropriate.

### Extensibility
<iframe width="560" height="315" src="https://www.youtube.com/embed/kCmU4EMMPf0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

The real world is a messy place where you might have an out-of-the-box tool that needs to be integrated with custom code. The ability to inject code into the Auth0 Identity solution means that developers can handle the last-mile customizations that execute on the C-suite’s business strategy without weeks of downtime or missed opportunities. To delve into this topic in greater technical detail, you might also check out Auth0 Principal Architect Vittorio Bertocci’s whitepaper “[The Tao of Extensibility.](https://auth0.com/resources/whitepapers/tao-of-extensibility)”

## Support and Failover
Uptimes, updates, failovers, and support can have a big impact on the success of your deployment. 

With Public Cloud coming in with an uptime SLA of 99.90%, Private Cloud offers a stronger uptime SLA of 99.95% with the option to upgrade to maxim uptime guarantees of 99.99%. Geo redundancy can provide resiliency against catastrophic events. As mentioned above, Private Cloud offers failover between two geographic regions. 

For teams that would appreciate additional support, Auth0 offers a support SLA as an add-on, as well as the add-on option to work with the skilled identity experts on our Professional Services team.

## Managed Private Cloud vs. Standard Private Cloud
Let’s take a look at the different deployment Private Cloud models and benefits, including a checklist to help you assess deployment needs.

**Standard Private Cloud** is a low touch engagement model that offers additional power, security and compliance* benefits through an isolated tenant just for a single customer. Uptime SLA is 99.95% with an upgrade possible to 99.99%. PCI compliance is available as an add-on.

**Managed Private Cloud** is a high-touch engagement model where customers are much more involved with all aspects of this deployment model. Our team will work closely with the customer to ensure all aspects of their Auth0 environment are tuned for what best suits their business needs. Uptime is 99.99%. PCI compliance is available as an add-on.

**Reasons to choose Managed Private Cloud**                                                                                                          * **Choice of update frequency**<br>Coordinated with Auth0 (required once per 3 months). The update cycle begins with the Pre-Production Environment.
* **A separate DEV (Pre-Production) environment**<br>Fully-isolated and independently updated instance for development and testing (Single Node)
* **On-demand scaling**<br>WIll scale customer environment for any spikes                                                                              * **Load Testing**<br>4x Load Testing per year with dedicated Auth0 MSE Support                                                 * **Customer-hosted AWS deployment**<br>More **control** over the environment                                                                              * **GEO-HA deployment option**<br>Datacenter **redundancy** and automatic **failure handling**.                                                               
<br>
**Reasons to choose Standard Private Cloud**
* ***Doesn’t require any of the Managed Private Cloud reasons***
* **More cost-effective**
* **Less involved with managing the deployment**<br>The customer is looking for an offering that feels similar to a standard Public Cloud SaaS but has isolation and the other advantages of our Private SaaS Deployments. |

<include src="TweetQuote" quoteText="Legacy code can make #digitaltransformation feel like a high hurdle for FinServs. Find out how Private Cloud can help securely smooth the jum"/>

## Reduce Risk, Increase Innovation With Private Cloud
Like identity, digital transformation is not a one-and-done solution, but an ongoing need to keep pace with the evolution of technological change. Auth0 Private Cloud provides the flexibility, agility offered by cloud deployments but allows FinServ’s to maintain the control and security they need to protect their customers and their businesses. Your IAM solution is a critical component of your security strategy, but even if you’re dealing with decades of legacy code, you don’t need to sit down and build it in-house. The more secure option is to let identity experts protect those critical credentials, freeing your team (and resources) to focus on what you do best. Identity no longer needs to be a roadblock or an afterthought. Identity Access Management (IAM) is an essential component of customer security and privacy. If you’d like to learn more about how Auth0 Private Cloud might work for your particular situation, please reach out to an [Auth0 resource](https://auth0.com/).


How FinServs Can Reduce Risk, Increase Innovation with Private Cloud

auziros:jeana-tahnk

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

Senior Director, Global Communications

Jeana Tahnk

Experimental modeling tool answers unmet need for holistic view of identity management design



**BELLEVUE, Wash. – December 9, 2019 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today unveiled [Auth0 Explorer](https://auth0.com/blog/charting-new-territory-with-auth0-explorer/), an experimental research tool for application developers to map, visualize, and navigate the design of identity authentication architecture, a crucial element in the creation of secure applications. Vittorio Bertocci, principal architect, will showcase Auth0 Explorer publicly at Gartner Identity & Access Management Summit, December 10-12, 2019. It can also be accessed at [https://explorer.auth0.com](https://explorer.auth0.com). 

Auth0 Explorer is born from the company’s ongoing and never-ending quest to make the very complex world of identity simple(r) for application builders. Knowing how many components are involved when building identity, Bertocci and team wanted to research and roll out an experimental tool that would help customers visualize their Auth0 tenant’s overall structure through an innovative user interface, providing them with a holistic live overview that most customers had previously drawn out on a whiteboard. Laid out very clearly, Auth0 Explorer arranges all major artifacts (connections, apps, APIs) representing relationships as a graph and allows customers to delve into every detail, path, and custom logic required for each specific architecture. 

Here’s how it works: Auth0 customers can log in to their Auth0 account at the [Auth0 Explorer landing page](https://explorer.auth0.com/), where they can select settings that allow them to customize their unique identity management architecture, with every possible component as an option. The experimental tool even has a “traffic layer” feature, which enables customers to connect an app to an identity provider and visually show (by line thickness) the volume of traffic that particular IdP generates for the application, as recorded in Auth0 logs. 

“Seeing the big picture of an identity management solution can be very difficult when you are a developer that is mired in the nitty-gritty details of building a complex identity architecture,” said Bertocci. “After consistently hearing from developers that drawing a picture is standard protocol in the planning process, we wanted to ease the developer burden by providing a much more seamless and customizable approach to navigating and planning an identity solution. The early feedback we have received from customers has been very positive, and we look forward to continuing to improve upon Auth0 Explorer to provide even more value to the application builders using it.”

Auth0 Explorer is an experiment – not a formal product offering – and is available now and accessible for customers and in demo mode at [https://explorer.auth0.com](https://explorer.auth0.com). Bertocci will be demoing Auth0 Explorer on Tuesday, Dec. 10 at 1:50 PM at the [Gartner IAM Summit](https://info.auth0.com/gartneriam2019.html). For show attendees who want to learn more about Auth0, please visit booth #517.

<include src="asides/AboutAuth0" />

### Media Contacts

Kaycie East<br>
Auth0 Communications<br>
[press@auth0.com](mailto:press@auth0.com)
 
Alexandria Plew <br>
Matter for Auth0<br>
[auth0@matternow.com](mailto:auth0@matternow.com)


Auth0 Explorer Gives Developers Greater Control, Deeper Insight into Authentication Architecture

Permissions-based access controls ease administrator management



**BELLEVUE, Wash. — November 25, 2019 —** Auth0, the identity platform for application builders, today announced its integration with Session Tags, a new IAM feature from AWS. This integration provides AWS users with access to the right information based on their user attributes, and reduces the number of AWS roles and permissions policies the administrator has to manage and update when employees’ responsibilities change. 

Customers frequently manage their workforce identities using an identity provider (IdP), federating from it into AWS using industry standards such as SAML and OIDC. Now, with session tags, when users federate into AWS, Auth0 can be configured to send attributes — for example  an environment tag, project tag, team tag, and cost center tag — which are then used to determine the correct IAM policies for controlling access to AWS resources. 

Customers can rely on the attributes from their corporate directory and ensure each employee receives defined permissions based on those attributes during an AWS session, simplifying fine-grained access control. Customers are able to scale more quickly without the administrator burden, and have a verifiable audit trail for permissions-based changes. 

“A lot of customers use attributed-based access control now, but are not able to make use of their existing IdPs to do so,” said Bill Lapcevic, VP of Business Development at Auth0. “Thanks to our integration with Session Tags, AWS IAM users will benefit from the ability to use existing attributes to automatically apply specified permissions, giving power back to the IdP as the source of truth for access control.” 

Please visit our [technical documentation](https://auth0.com/docs/integrations/aws) on Session Tags for more details on how to implement this feature.

<include src="asides/AboutAuth0" />


Auth0 Announces Partnership with AWS for IAM Session Tags

001c9ddc5ceb9829b6aaf24f5d28502a

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

Senior Engineer

Sebastian Peyrott

Embed Multi-Factor Authentication using push notifications, SMS, or TOTP anywhere, taking full control of the experience.



We are pleased to announce the availability of our [Multi-Factor Authentication API](https://auth0.com/docs/api-auth/tutorials/multifactor-resource-owner-password). Up to now, we have provided support for MFA through a simple switch in the Auth0 Dashboard, following our premise of *simplicity* and ease of use. However, we also believe in providing powerful *building blocks* for our users. For this reason we have developed a new API to perform the full MFA flow, even with multiple authenticators, in a flexible and convenient way. In this article we will take a look at the API and build a simple CLI app to demonstrate how to use it. Read on!

<include src="TweetQuote" quoteText="The MFA API is now available, learn how to embed MFA in your apps taking full control of the experience!"/>

> **Note**: for most MFA scenarios, we still recommend the use of [Universal Login](https://auth0.com/docs/hosted-pages/login) whenever possible. This new API is meant for advanced use cases where Universal Login is not flexible enough. [Universal Login is the best alternative](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) in most cases.

---

## Why?
Up to now, enabling MFA at Auth0 was simply a matter of flipping a switch and optionally selecting which application you wanted to enable MFA for. When MFA is enabled, hitting the `/authorize` endpoint or starting an authorization flow through one of our libraries was enough to trigger MFA. Simple, convenient.

![MFA Switch](https://images.ctfassets.net/23aumh6u8s0i/4Fk1xnLP6wm5Ay24YJLeex/c7047fc95a6712dfa7a92f5b7c5522e7/1-mfa-enable)

However, some of our customers have requested to have more control over the MFA process. For this reason, we have been working with [ATEA Norge](https://www.atea.no/) and other customers under a private BETA program to find the right implementation for this feature. The result: a new API for MFA to give back control to you when required. Let's check it out.

> **Note**: for most MFA scenarios, we still recommend the use of [Universal Login](https://auth0.com/docs/hosted-pages/login) whenever possible. This new API is meant for advanced use cases where Universal Login is not flexible enough. [Universal Login is the best alternative](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) in most cases.

## A Simple API
The API works by introducing some changes to how the `/token` endpoint behaves. Let's take a look.

<include src="TweetQuote" quoteText="The new MFA API is simple, it works on top of the existing /token endpoint."/>

The API works in four simple steps:

1. Access token request to `/token`.
2. Challenge request to `/challenge`.
3. Asking the user for a code (if necessary).
4. Final request to `/token`.

> This scenario assumes the user is already enrolled in MFA and has at least one authenticator enabled. There's also a [new API for enrollment](https://auth0.com/docs/multifactor-authentication/api/otp) to have full control over the enrollment process. This API also allows for obtaining a list of associated authenticators, useful for using multiple authenticator, as we will see in step 2 below.

### 1. Access Token Request to `/token`
When a request is made to the `/token` endpoint to get an access token, normally you either get an error, or you get an access token. However, when the MFA API is enabled, the `/token` endpoint may return a new error code: `mfa_required`.

```
POST /oauth/token HTTP/1.1
...

{
  "username": "...",
  "password": "...",
  "grant_type": "password"
  ...
}
```

Response:

```
HTTP/1.1 403 Forbidden
...

{
  "error": "mfa_required",
  "mfa_token": "..."
}
```

The `mfa_token` in the response value must be used in the following requests.

> MFA is also supported for the `refresh_token` [grant type](https://auth0.com/docs/applications/application-grant-types). This allows for use cases in which you want to require 2FA (TOTP, SMS, push notifications) when refreshing an access token, useful for extra security and step-up authentication.

### 2. Perform an MFA Challenge
When the `mfa_required` error is returned, the client must then perform a `challenge`. This is done by sending a request to the `/mfa/challenge` endpoint.

```
POST /mfa/challenge HTTP/1.1
...

{
  "mfa_token": "<from step 1>",
  "challenge_type": "otp oob",
  "authenticator_id": "optional, if known"
}
```

Response:

```
HTTP/1.1 200 OK
...

{
  "challenge_type": "oob",
  "binding_method": "prompt",
  "oob_code": "..."
}
```

The response tells the client which type of authenticator will be used (`challenge_type`) and also returns additional arguments relevant for that method. The `binding_method` parameter tells the client it should ask the user for a code.

The client may optionally request a specific authenticator through `authenticator_id`. This allows for multiple authenticators, even for the same resource.

> `OOB` means "out-of-band". All methods that are not [TOTP](https://auth0.com/blog/from-theory-to-practice-adding-two-factor-to-node-dot-js/) are OOB.

### 3. Prompt For Input (If Necessary)
If the `challenge_type` is `otp` or the `binding_method` parameter is set to `prompt`, the client should ask the user to input a code before continuing.

### 4. Get The Access Token
Finally, a new request to the `/token` endpoint is performed.

```
POST /oauth/token HTTP/1.1
...

{
  "mfa_token": "<from step 1>",
  "oob_code": "<from step 2, optional>",
  "binding_code": "<from step 3, if 'binding_method' === 'prompt'>",
  "otp": "<from step 3, if challenge_type === 'otp'>",
  "grant_type": "<one of two strings, see below>"
}
```

Grant type must be one of two values:
- For OTP: `http://auth0.com/oauth/grant-type/mfa-otp`
- For OOB: `http://auth0.com/oauth/grant-type/mfa-oob`

Response:

```
HTTP/1.1 200 OK
...

{
  "access_token": "...",
  "expires_in": "...",
  ...
}
```

Note that certain methods do not require the user to input anything (push notifications, for example). For those cases, this request must be performed repeatedly until an access token is returned or the authorization is denied. If the client is expected to repeat the request again in the future (after a certain amount of time) the response will be:

```
HTTP/1.1 400 Bad Request
...

{
  "error": "authorization_pending"
}
```

This means the user has not performed any actions yet and the client should wait a bit before trying again. The `error` can also be `slow_down` if the client is not waiting enough between requests.

That's it! If all went well, you now have an access token issued through MFA!

## Example: A CLI App with MFA
To give you a better understanding of how the API works we have developed a [simple CLI app that uses MFA](https://github.com/auth0-blog/oauth2-mfa-cli-example).

<video src="https://cdn.auth0.com/blog/oauth2-mfa-api/cli-demo-2.m4v" controls autoplay loop></video>

Take a look at the [full code in GitHub](https://github.com/auth0-blog/oauth2-mfa-cli-example). You will find the interesting bits in the `/token-endpoint.mjs` file, particularly in the `token` function.

To use the app, make sure that:
- You have created a new [Application](https://manage.auth0.com/#/applications) in the Auth0 Dashboard. Select the `Machine-to-Machine type`.
- The `token authentication method` is set to `none` in the Auth0 Application settings.
- You have enabled the `Password` and `MFA` grants in `Application -> Advanced Settings -> Grant Types`.
- You have MFA enabled. Go to [Multifactor Auth](https://manage.auth0.com/#/guardian) and enable SMS and push notifications for [Guardian](https://auth0.com/docs/multifactor-authentication/guardian/user-guide).
- You have set the right client ID (get this from the [application](https://manage.auth0.com/#/applications) settings area) in the MFA rule in the [Multifactor Auth](https://manage.auth0.com/#/guardian) section. Otherwise MFA will be enabled for all clients.

To use the app simply do:

```sh
git clone git@github.com:auth0-blog/oauth2-mfa-cli-example.git
cd oauth2-mfa-cli-example
npm install
node src/index.js login
```

The app supports some other commands. You can take a look at them by running it with no arguments.

## Other Use Cases
The sky is the limit! Here are some scenarios where using the new MFA API could make sense:

- Protect a VPN like OpenVPN (Pritnul) or Juniper with a second factor.
- Integrate with a PAM module to do second factor with SSH.
- Integrate with an LDAP service to provide a second factor.
- Step up authentication when refreshing an `access_token` (`refresh_token` grant).
- Trigger second factor from any backend process.

You are now free to build powerful MFA flows wherever you want!

## Conclusion
The MFA API brings flexibility to the use of MFA in your apps. One thing you may have noticed is that we are using the [OAuth 2.0 `/token` endpoint](https://tools.ietf.org/html/rfc6749#section-3.2). In fact, we designed this to be compatible with OAuth 2.0 right from the start. We have prepared two specification drafts, [one for MFA](https://github.com/jaredhanson/draft-oauth-mfa/blob/master/Draft-1.0.txt), [the other for authenticator association](https://github.com/jaredhanson/draft-oauth-mfa-assoc/blob/master/Draft-1.0.txt), to be sent to the [IETF OAuth 2.0 Working Group](https://tools.ietf.org/wg/oauth/). Other implementations of OAuth 2.0 can follow these specifications to implement MFA in a flexible, yet powerful way, while remaining compatible. We will have more information about this in an upcoming post.

We can't wait to see how you use this API to build powerful multi-factor flows! Let us know what you think in the comments.

<include src="TweetQuote" quoteText="We can't wait to see how you use this API to build powerful multi-factor flows!"/>


Introducing the Multi-Factor Authentication API

diegopoza

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

Diego Poza

With hybrid cloud deployment becoming popular, keeping tight control on authentication and authorization has become essential.



The ability to clearly observe, track, and log in as your authorized users allows for the swift implementation of updates and early alerts of any suspicious behavior.

Moving to a hybrid cloud model is the first step that many companies take when undergoing a digital transformation. Less expensive and resource-intense than a full private cloud option — yet still providing an extra measure of security, compared with the public cloud — hybrid deployment has become [highly popular](https://assets.rightscale.com/uploads/pdfs/RightScale-2017-State-of-the-Cloud-Report.pdf) among tech professionals.

Yet once you migrate to a hybrid cloud model, it can become increasingly difficult to keep track of your users. Previously, your team likely conducted critical tasks on-premises. Now, with the opportunity for multiple users to log in and work with sensitive data from a range of locations and devices, keeping tabs on authentications (who has signed in) and authorizations (who has permission to use private resources) becomes essential.

A clear identity management system can help your team organize user information in a way that makes it easy for administrators to have a birds-eye view of actions taking place and make quick changes if need be. You can build this yourself or outsource your identity and access management (IAM) needs to ensure they are professional, up-to-date, and don't cause additional security concerns.

## Track Your Users in the Hybrid Cloud

A robust IAM strategy can show you who is currently logged into your network. Having the full picture is essential to staying organized and rooting out any suspicious activity. For example, Auth0 provides a simple, efficient [dashboard](https://auth0.com/user-management) to centralize a range of user interface tools.

![Define permissions for your application](https://images.ctfassets.net/23aumh6u8s0i/4WAc5rNAGDrYtU4KvjZf3a/391b00ff76f4683a27fdadecdb9f8f47/permissions)

With this, an administrator is able to view all current users, their locations, login history, and additional personal information. From here administrators are able to supervise password resets, block and delete users, and perform a range of other tasks.

After granting a new member access, the administrator can simply add a user and create his or her profile, populating it with further details:

![Device list for a particular user](https://images.ctfassets.net/23aumh6u8s0i/2K9kiqPRE9Q8pn68PkAUMQ/535d7a9fc2b13508675f00d5d7fbf8cd/matias)

The above profile breaks down all devices the administrator has authorized for this particular user. This allows the administrator to confirm that the user is accessing any private data from an approved source. If the administrator has any questions about a user's behavior, he or she may unlink a particular device at any time.


<include src="TweetQuote" quoteText="A robust IAM strategy can show you who is currently logged into your network. Having the full picture is essential to staying organized and rooting out any suspicious activity."/>

## Restrict Access to Sensitive Documents

In the hybrid cloud, your workflow is split between confidential tasks in the private cloud and less sensitive ones in the public cloud. With a strong IAM system, you can allow access to private documents based on a user's ID. This can limit the amount of damage that can occur if someone's username or login details are stolen. IAM companies like Auth0 facilitate different permissions based on the user.

![Auth0 users list](https://images.ctfassets.net/23aumh6u8s0i/7mOPwlvOZLZLQpekVHgnS7/11bc61843543409ccca6c12da2515228/userlist)

To make the task more efficient, Auth0's [authorization extension](https://auth0.com/blog/announcing-authorization-extension-v2/) allows you to combine your users and give permission such as “approve:reports” to an entire group. As you can see above, several permissions can be created within each application, allowing administrators to assert control over nearly all actions taking place on their network.

Only a highly detailed identity management system will truly help you unlock the potential of the private portion of your hybrid cloud system.

## Conclusion: When to Shift to the Hybrid Cloud

While the hybrid cloud has enormous advantages, such as the ability to quickly scale alongside your growing company, it isn't appropriate for all organizations. Setting up your own servers on the private end of the hybrid cloud can be costly, hindering teams with small computing budgets. Major cloud service providers like [Amazon Web Services](https://aws.amazon.com/), [Google Cloud](https://cloud.google.com/), and [Microsoft Azure](https://azure.microsoft.com/en-us/) can offer a certain level of intrusion monitoring in a basic public cloud option, which can often provide enough security for smaller teams.

However, if your company has the funds, moving to the hybrid cloud can allow your most business-critical applications to remain behind an additional firewall. Creating or outsourcing a strong identity management system to better monitor and control your users in the hybrid cloud will open even further opportunities to fix bugs and root out unusual log-ins as your company continues to grow.


How a Strong Identity Management System Can Ease Your Transition to the Hybrid Cloud

bruno-krebs

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

R&D Content Architect

Bruno Krebs

Learn how to make React and Redux control a bunch of SVG elements to create a game.

Developing Games with React, Redux, and SVG - Part 4



**TL;DR:** In this series, you will learn how to make React and Redux control a bunch of SVG elements to create a game. The knowledge acquired throughout this series will also allow you to create other types of animations that are orchestrated by React and Redux, not only games. You can find the final code developed in this article in the following GitHub repository: [Aliens Go Home - Part 3](https://github.com/auth0-blog/aliens-go-home-part-3)

---

## Implementing the Leaderboard Feature in Your React Game

The first thing you will do to make your game look like a real game is to implement the leaderboard feature. This feature will enable players to sign in, so your game can track their max score and show their rank.

## Integrating React and Auth0

To make Auth0 manage the identity of your players, you have to have an Auth0 account. If you don't have one yet, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">**sign up for a free Auth0 account** here</a>.

After creating your account, you just have to create an [Auth0 Application](https://auth0.com/docs/applications) to represent your game. To do this, head to [the Applications page on the Auth0 dashboard](https://manage.auth0.com/#/applications) and click on the *Create Application* button. The dashboard will show you a form where you will have to inform the *name* of your application and its *type*. You can type *Aliens, Go Home!* as the name and choose the *Single Page Web Application* type (your game is an SPA based on React after all). Then, you can click on *Create*.

![Creating the Auth0 Application to represent your React game.](https://images.ctfassets.net/23aumh6u8s0i/5pj3GTmuI8ExyWUAnd8if3/160bb83f92bafa4bf91371474ce071bc/creating-the-auth0-client-for-your-react-game)

When you click this button, the dashboard will redirect you to the *Quick Start* tab of your new application. As you will learn how to integrate React and Auth0 in this article, you won't need to use this tab. Instead, you will need to use the *Settings* tab, so head to it.

There are three things that you will need to do in this tab. The first one is to add the `http://localhost:3000` value to the field called *Allowed Callback URLs*. As the dashboard explains, *after the player authenticates, Auth0 will only call back one of the URLs in this field*. So, if you are going to publish your game on the web, be sure to add its public URL there as well (e.g. `http://aliens-go-home.digituz.com.br`).

After inputting all your URLs on this field, hit the *Save* button or press `ctrl` + `s` (if you are using a MacBook, you will need to press `command` + `s` instead).

The last two things you will need to do is to copy the values from the *Domain* and *Client ID* fields. However, before using these values, you will need to code a little.

For starters, you will need to issue the following command in the root directory of your game to install the `auth0-web` package:

```bash
npm i auth0-web@1.7.0
```

As you will see, this package facilitates the integration between Auth0 and SPAs.

The next step is to add a login button in your game, so your players can authenticate via Auth0. To do this, create a new file called `Login.jsx` inside the `./src/components` directory with the following code:

```js
import React from 'react';
import PropTypes from 'prop-types';

const Login = (props) => {
  const button = {
    x: -300, // half width
    y: -600, // minus means up (above 0)
    width: 600,
    height: 300,
    style: {
      fill: 'transparent',
      cursor: 'pointer',
    },
    onClick: props.authenticate,
  };

  const text = {
    textAnchor: 'middle', // center
    x: 0, // center relative to X axis
    y: -440, // 440 up
    style: {
      fontFamily: '"Joti One", cursive',
      fontSize: 45,
      fill: '#e3e3e3',
      cursor: 'pointer',
    },
    onClick: props.authenticate,
  };

  return (
    <g filter="url(#shadow)">
      <rect {...button} />
      <text {...text}>
        Login to participate!
      </text>
    </g>
  );
};

Login.propTypes = {
  authenticate: PropTypes.func.isRequired,
};

export default Login;
```

The component that you have just created is agnostic in terms of what it will do when clicked. You will define this action when adding it to the `Canvas` component. So, open the `Canvas.jsx` file and update it as follows:

```js
// ... other import statements
import Login from './Login';
import { signIn } from 'auth0-web';

const Canvas = (props) => {
  // ... const definitions
  return (
    <svg ...>
      // ... other elements

      { ! props.gameState.started &&
      <g>
        // ... StartGame and Title components
        <Login authenticate={signIn} />
      </g>
      }

      // ... flyingObjects.map
    </svg>
  );
};
// ... propTypes definition and export statement
```

As you can see, in this new version, you have imported the `Login` component and the `signIn` function of the `auth0-web` package. Then, you have added your new component to the block of code that is shown only if players have not started the game. Also, you have indicated that, when clicked, the login button must trigger the `signIn` function.

With these changes in place, the last thing you will have to do is to configure the `auth0-web` with your Auth0 Application properties. To do this, open the `App.js` file and update it as follows:

```js
// ... other import statements
import * as Auth0 from 'auth0-web';

Auth0.configure({
  domain: 'YOUR_AUTH0_DOMAIN',
  clientID: 'YOUR_AUTH0_CLIENT_ID',
  redirectUri: 'http://localhost:3000/',
  responseType: 'token id_token',
  scope: 'openid profile manage:points',
});

class App extends Component {
  // ... constructor definition

  componentDidMount() {
    const self = this;

    Auth0.handleAuthCallback();

    Auth0.subscribe((auth) => {
      console.log(auth);
    });

    // ... setInterval and onresize
  }

  // ... trackMouse and render functions
}

// ... propTypes definition and export statement
```

> **Note:** You have to replace `YOUR_AUTH0_DOMAIN` and `YOUR_AUTH0_CLIENT_ID` with the values copied from the *Domain* and *Client ID* fields of your Auth0 application. Besides that, when publishing your game to the web, you will have to replace the `redirectUri` value as well.

The enhancements in this file are quite simple. This list summarizes them:

1. `configure`: You used this function to configure the `auth0-web` package with your Auth0 application properties.
2. `handleAuthCallback`: You triggered this function in [the `componentDidMount` lifecycle hook](https://reactjs.org/docs/react-component.html#componentdidmount) to evaluate if the player is returning from Auth0 after authenticating. This function simply tries to fetch tokens from the URL and, if it succeeds, fetches the player profile and persists everything in the `localstorage`.
3. `subscribe`: You used this function to log if the player is authenticated or not (`true` for authenticated and `false` otherwise).

That's it, your game is already [using Auth0 as its identity management service](https://auth0.com/learn/cloud-identity-access-management/). If you run your app now (`npm start`) and head to it in your browser ([`http://localhost:3000`](http://localhost:3000)), you will see the login button. Clicking on it will redirect you to [the Auth0 login page](https://auth0.com/docs/hosted-pages/login) where you will be able to sign in.

After you finish the sign in process, Auth0 will redirect you to your game again where the `handleAuthCallback` function will fetch your tokens. Then, as you have told your app to `console.log` any changes on the authentication state, you will be able to see it logging `true` in your browser console.

![Showing the login button on your React and Redux game](https://images.ctfassets.net/23aumh6u8s0i/57jV86VbI5EHf8c0GYHB4X/16b629d88c601fab2f0bb799e7e0be6d/showing-the-login-button-in-your-react-game)

<include src="TweetQuote" quoteText="Securing games with Auth0 is simple and painless."/>

## Creating the Leaderboard React Component

Now that you have configured Auth0 as your identity management system, you will need to create the components that will show the leaderboard and the max score for the current player. For that, you will create two components: `Leaderboard` and `Rank`. You will need to split this feature into two components because, as you will see, it's not that simple to show player's data (like max score, name, position, and picture) in a nice way. It's not hard either, but you will have to type some good amount of code. So, adding everything into one component would make it look clumsy.

As your game does not have any players yet, the first thing you will need to do is to define some mock data to populate the leaderboard. The best place to do this is in the `Canvas` component. Also, since you are going to update your canvas, you can go ahead and replace the `Login` component with the `Leaderboard` (you will add `Login` inside the `Leaderboard` in a moment):

```js
// ... other import statements
// replace Login with the following line
import Leaderboard from './Leaderboard';

const Canvas = (props) => {
  // ... const definitions
  const leaderboard = [
    { id: 'd4', maxScore: 82, name: 'Ado Kukic', picture: 'https://twitter.com/KukicAdo/profile_image', },
    { id: 'a1', maxScore: 235, name: 'Bruno Krebs', picture: 'https://twitter.com/brunoskrebs/profile_image', },
    { id: 'c3', maxScore: 99, name: 'Diego Poza', picture: 'https://twitter.com/diegopoza/profile_image', },
    { id: 'b2', maxScore: 129, name: 'Jeana Tahnk', picture: 'https://twitter.com/jeanatahnk/profile_image', },
    { id: 'e5', maxScore: 34, name: 'Jenny Obrien', picture: 'https://twitter.com/jenny_obrien/profile_image', },
    { id: 'f6', maxScore: 153, name: 'Kim Maida', picture: 'https://twitter.com/KimMaida/profile_image', },
    { id: 'g7', maxScore: 55, name: 'Luke Oliff', picture: 'https://twitter.com/mroliff/profile_image', },
    { id: 'h8', maxScore: 146, name: 'Sebastian Peyrott', picture: 'https://twitter.com/speyrott/profile_image', },
  ];
  return (
    <svg ...>
      // ... other elements

      { ! props.gameState.started &&
      <g>
        // ... StartGame and Title
        <Leaderboard currentPlayer={leaderboard[6]} authenticate={signIn} leaderboard={leaderboard} />
      </g>
      }

      // ... flyingObjects.map
    </svg>
  );
};

// ... propTypes definition and export statement
```

In the new version of this file, you defined a constant called `leaderboard` that holds an array of fake players. These players have the following properties: `id`, `maxScore`, `name`, and `picture`. Then, inside the `svg` element, you added the `Leaderboard` component with the following parameters:

- `currentPlayer`: This defines who the current player is. For now, you are using one of the fake players defined before so you can see how everything works. The purpose of passing this parameter is to make your leaderboard highlight the current player.
- `authenticate`: This is the same parameter that you were adding to the `Login` component in the previous version.
- `leaderboard`: This is the array of fake players. Your leaderboard will use it to show the current ranking.

Now, you have to define the `Leaderboard` component. To do this, create a new file called `Leaderboard.jsx` in the `./src/components` directory and add the following code to it:

```js
import React from 'react';
import PropTypes from 'prop-types';
import Login from './Login';
import Rank from "./Rank";

const Leaderboard = (props) => {
  const style = {
    fill: 'transparent',
    stroke: 'black',
    strokeDasharray: '15',
  };

  const leaderboardTitle = {
    fontFamily: '"Joti One", cursive',
    fontSize: 50,
    fill: '#88da85',
    cursor: 'default',
  };

  let leaderboard = props.leaderboard || [];
  leaderboard = leaderboard.sort((prev, next) => {
    if (prev.maxScore === next.maxScore) {
      return prev.name <= next.name ? 1 : -1;
    }
    return prev.maxScore < next.maxScore ? 1 : -1;
  }).map((member, index) => ({
    ...member,
    rank: index + 1,
    currentPlayer: member.id === props.currentPlayer.id,
  })).filter((member, index) => {
    if (index < 3 || member.id === props.currentPlayer.id) return member;
    return null;
  });

  return (
    <g>
      <text filter="url(#shadow)" style={leaderboardTitle} x="-150" y="-630">Leaderboard</text>
      <rect style={style} x="-350" y="-600" width="700" height="330" />
      {
        props.currentPlayer && leaderboard.map((player, idx) => {
          const position = {
            x: -100,
            y: -530 + (70 * idx)
          };
          return <Rank key={player.id} player={player} position={position}/>
        })
      }
      {
        ! props.currentPlayer && <Login authenticate={props.authenticate} />
      }
    </g>
  );
};

Leaderboard.propTypes = {
  currentPlayer: PropTypes.shape({
    id: PropTypes.string.isRequired,
    maxScore: PropTypes.number.isRequired,
    name: PropTypes.string.isRequired,
    picture: PropTypes.string.isRequired,
  }),
  authenticate: PropTypes.func.isRequired,
  leaderboard: PropTypes.arrayOf(PropTypes.shape({
    id: PropTypes.string.isRequired,
    maxScore: PropTypes.number.isRequired,
    name: PropTypes.string.isRequired,
    picture: PropTypes.string.isRequired,
    ranking: PropTypes.number,
  })),
};

Leaderboard.defaultProps = {
  currentPlayer: null,
  leaderboard: null,
};

export default Leaderboard;
```

Don't be scared! The code of this component is quite simple:

1. You are defining the `leaderboardTitle` constant to set how the leaderboard title will look like.
2. You are defining the `dashedRectangle` constant to style a `rect` element that will work as the container of the leaderboard.
3. You are calling the `sort` function of the `props.leaderboard` variable to order the ranking. After that, your leaderboard will have the highest max score on the top and the lowest max score on the bottom. Also, if there is a tie between two players, you are ordering them based on their names.
4. You are calling the `map` function on the result of the previous step (the `sort` function) to complement players with their `rank` and with a flag called `currentPlayer`. You will use this flag to highlight the row where the current player appears.
5. You are using the `filter` function on the result of the previous step (the `map` function) to remove everyone who is not among the top three players. Actually, you are letting the current player stay on the final array if they don't belong to this select group.
6. Lastly, you are simply iterating over the filtered array to show `Rank` elements if there is a player logged in (`props.currentPlayer && leaderboard.map`) or showing the `Login` button otherwise.

Then, the last thing you will need to do is to create the `Rank` React component. To do this, create a new file called `Rank.jsx` beside the `Leaderboard.jsx` file with the following code:

```js
import React from 'react';
import PropTypes from 'prop-types';

const Rank = (props) => {
  const { x, y } = props.position;

  const rectId = 'rect' + props.player.rank;
  const clipId = 'clip' + props.player.rank;

  const pictureStyle = {
    height: 60,
    width: 60,
  };

  const textStyle = {
    fontFamily: '"Joti One", cursive',
    fontSize: 35,
    fill: '#e3e3e3',
    cursor: 'default',
  };

  if (props.player.currentPlayer) textStyle.fill = '#e9ea64';

  const pictureProperties = {
    style: pictureStyle,
    x: x - 140,
    y: y - 40,
    href: props.player.picture,
    clipPath: `url(#${clipId})`,
  };

  const frameProperties = {
    width: 55,
    height: 55,
    rx: 30,
    x: pictureProperties.x,
    y: pictureProperties.y,
  };

  return (
    <g>
      <defs>
        <rect id={rectId} {...frameProperties} />
        <clipPath id={clipId}>
          <use xlinkHref={'#' + rectId} />
        </clipPath>
      </defs>
      <use xlinkHref={'#' + rectId} strokeWidth="2" stroke="black" />
      <text filter="url(#shadow)" style={textStyle} x={x - 200} y={y}>{props.player.rank}º</text>
      <image {...pictureProperties} />
      <text filter="url(#shadow)" style={textStyle} x={x - 60} y={y}>{props.player.name}</text>
      <text filter="url(#shadow)" style={textStyle} x={x + 350} y={y}>{props.player.maxScore}</text>
    </g>
  );
};

Rank.propTypes = {
  player: PropTypes.shape({
    id: PropTypes.string.isRequired,
    maxScore: PropTypes.number.isRequired,
    name: PropTypes.string.isRequired,
    picture: PropTypes.string.isRequired,
    rank: PropTypes.number.isRequired,
    currentPlayer: PropTypes.bool.isRequired,
  }).isRequired,
  position: PropTypes.shape({
    x: PropTypes.number.isRequired,
    y: PropTypes.number.isRequired
  }).isRequired,
};

export default Rank;
```

Nothing to be scared of about this code either. The only unordinary thing that you are adding to this component is [the `clipPath` element](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/clipPath) and a `rect` inside the `defs` element to create a rounded portrait.

With these new files in place, you can head to your app ([`http://localhost:3000/`](http://localhost:3000/)) to see your new leaderboard feature.

![Showing the leaderboard in your React Game](https://images.ctfassets.net/23aumh6u8s0i/7zDgzmih6wVEW0uuJfBP17/177147d358e6db1b41eb1ff9a6c29f2b/showing-the-leaderboard-in-your-react-game)


Developing Games with React, Redux, and SVG - Part 3

Developing Games with React, Redux, and SVG - Part 2

Developing Games with React, Redux, and SVG - Part 1

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

Learn how enterprises are taking back control of managing, tracking and securing their employee's mobile devices.


**TL;DR:**  Learn how enterprises are taking back control of managing, tracking and securing their employee's mobile devices.

You probably don't realize it, but your colleagues and you have been leading a technology revolution against your company's IT department. The day you handed in your corporate-issued Blackberry and started using your personal devices to conduct business was the day you inadvertently declared war on IT.

![Source](https://images.ctfassets.net/23aumh6u8s0i/pUmIPSCGzHyj26w3bhH6d/56aa08eb4144b70aea29f61649d41f86/it-war)

Before this revolt, IT enjoyed complete control your organization's devices, applications, and data, which made it easy to keep information secure and the systems working within the requirements of the enterprise. This all changed when employees took IT into their own hands, otherwise known as [Shadow IT](https://www.informationweek.com/cloud/shadow-it-its-much-worse-than-you-think/a/d-id/1321637?).

Your consumer-focused mobile applications were so easy to use and enhanced your productivity to a point where it made sense to start using these same applications for work. You set up Dropbox to share your team's confidential documents, you started collaborating in Google Docs, and you built presentations on Prezi.

![Source](https://images.ctfassets.net/23aumh6u8s0i/6J2aXnEp5NJjxHAZnTVBYN/ace0c9ba4fa8ce22716e9797a79a12bd/Shadow-it-happens)

While you didn't think twice about using these apps, IT had a big problem on its hands. Workers started using [hundreds](http://www.itmanagerdaily.com/study-a-majority-of-workplace-apps-are-shadow-it/) of unsanctioned apps and accessing them outside of the office on their mobile devices. This blitz on the enterprise grew into a major security liability. Something had to be done.

## The Rise of Enterprise Mobility Management (EMM)

IT had a unique challenge to solve: how could they secure and track the confidential information living on their employee's mobile devices without impeding on the flexibility and productivity that employees now relied on to conduct business?

Enterprise mobility management (EMM) emerged as the solution, with the idea of helping IT take back control of the business-related applications and data living on employee devices without actually interfering with their personal apps.

<include src="TweetQuote" quoteText="Simply put, it is a set of services and technologies that work together to secure company-owned applications and data on your employees’ mobile devices."/>

EMM is still in its infancy. Simply put, it is a set of services and technologies that work together to secure company-owned applications and data on your employees’ mobile devices. While the concept is straightforward, the complexities to achieve this goal require completely new technological approaches that continue to evolve.

![Source](https://images.ctfassets.net/23aumh6u8s0i/1uyDEbLJKZv251Igzkp6Mk/fc042c1a9e98865303e3605890c8b4d7/emm-technical-challenges)

The volume and variety of mobile applications, operating systems and device types that need to be considered create the challenge for building EMM solutions. David Johnson, a principal analyst at Forrester Research, [upped the ante ](https://www.computerworld.com/article/3230510/mobile-wireless/what-is-enterprise-mobility-management-emm.html) extending EMM beyond mobile management:

> *EMM used to be mainly about mobile device and application management, but now it’s more about enabling mobility more broadly – extending to Windows 10 and MacOS devices, identity and access management strategy, and how to design mobile engaging and productive mobile experiences for employees.*

With so many moving pieces, the definitions and expectations of EMM continue to evolve. In order to get a solid grasp on where EMM is and where it's heading, it's helpful to look at the four areas currently driving the EMM strategy.

## 4 Components of EMM

We apologize in advance for the onslaught of [acronyms](http://thecontextofthings.com/2014/02/06/whats-up-with-the-over-use-and-obsession-on-acronyms-in-american-business-and-professional-culture/), but the best way to define EMM is by explaining its core components: MDM, MAM, MCM, and MIM.

While EMM can manifest itself in different ways depending on your requirements, the technology suite is primarily focused on managing four important aspects of mobile:

1. **Device: **Mobile device management (MDM)
2. **Applications: **Mobile application management (MAM)
3. **Content: **Mobile content management (MCM)
4. **Identity: **Mobile identity management (MIM)

![emm-platform](https://images.ctfassets.net/23aumh6u8s0i/23grw37EUvrZ85A5y7akCj/7b0c4cbdcb0ef2f324e322e63c56c772/emm-platform.png)

EMM is the comprehensive method of remotely managing devices, which is accomplished by incorporating the aforementioned four tools and strategies.

### 1. What is Mobile Device Management?

MDM is mistakenly used interchangeably with EMM. While MDM focuses on the device being secured, EMM encompasses both the device and the information which isn’t always stored in the device.

With MDM software, IT administrators can oversee mobile devices in the same way they manage your desktop computers in the office. They can remotely enroll the device and then track it, manage it and secure it based on the employee's profile and tasks.

![Source](https://images.ctfassets.net/23aumh6u8s0i/6L0odS5xyll40kQKpVouhz/f932ccd48d85281fc34031d5e7b9ca21/Mobile-Device-Management2)

The company can access your device to provision and configure Wi-Fi access, install and update apps, and fix any problems on the device. IT can also enforce security measures on the device such as locking out a device and wiping data.

### 2. What is Mobile Application Management?

MAM refers to the delivery and administration of the enterprise's software to the employee's device. While MDM focuses on device activation, provisioning, and troubleshooting, MAM tools deliver and manage all aspects of the mobile software (applications).

An important feature of MAM is providing the ability for IT to wipe company-owned apps and data remotely, without affecting the user's personal items.

![Source](https://images.ctfassets.net/23aumh6u8s0i/54eQbaZlFEfona8O2g2Yps/aa6be9ce02315c81dbd84f4e66dd48ec/mam-diagram-app-level_desktop)

The admin can also blacklist or whitelist applications and control their access permissions, which helps combat sensitive data flowing through unsanctioned applications.

When combined with MDM, MAM solutions can help IT better understand employee usage of the enterprise applications with behavioral analytics.

### 3. What is Mobile Content Management?

MCM uses a set of technology tools that secure access and storage of confidential content by implementing an encrypted, managed container.

Instead of storing important, company-owned content on personal apps like Dropbox or Google Drive, employees must adhere to the MCM policies for accessing and storing content and use the enterprise's preferred application. This not only keeps corporate content separate from personal but also gives IT the power to delete content from the device at will.

![Source](https://images.ctfassets.net/23aumh6u8s0i/64TMnRdcG4VDeutP1l7tNA/12aadff09555d571eb3deb51bbff5e9f/mobile-content-mgmt)

MCM is most effective when incorporated with MAM and MDM to ensure management of each level of the mobile enterprise. Identity management becomes the final component to keeping each level secure as it gives IT control over end-user access to specific apps, content, and sets of data.

### 4. What is Mobile Identity Management?

MIM is designed to ensure that only trusted devices and users can access enterprise data or applications. By authenticating the user’s identity and then tracking their activity, MIM gives IT the tools to manage access across devices and applications beyond the firewall.

Tools like [Auth0](https://auth0.com/), give administrators the ability to implement access security through:

* **Two-factor authentication:** [2FA](https://auth0.com/learn/two-factor-authentication/) provides an extra layer of security if a mobile device is lost or stolen. By asking for a second form of identification such as an SMS code; if credentials are ever compromised, the data is still secure.
* **Behavioral Alerts:** Auth0 provides [custom tools](https://auth0.com/docs/anomaly-detection) to detect anomalies and stop unauthorized access. By tracking behavior and geography, MIM tools will alert IT of suspicious activity and attempts to log in.
* **SSO (single sign-on):** [SSO](https://auth0.com/docs/sso/current) allows users to use one set of credentials to access multiple applications. When enterprises use dozens of apps, SSO gives employees the convenience of access without tedious logins for every app.

![Source](https://images.ctfassets.net/23aumh6u8s0i/27ARow6G5c3pb78x2Aq8H5/de558db7492ffb25b10c820fa9ddaba2/identity-mgmt)

Identity management is the glue that keeps MDM, MAM, and MCM secure. Each of these components serves a specific purpose within the EMM framework, but as they are incorporated into a cohesive system, enterprises are able to gain back control of their digital assets.

## How to Choose an EMM Provider

The technology suite of tools and services needed to deliver a complete EMM solution currently does not exist within one single vendor.

EMM is rapidly evolving, and there is a lack of industry standards and best practices. Like most IT initiatives, start your EMM vendor search by developing a set of objectives and requirements. Define your needs and research vendors based on individual capabilities.

Here are 4 questions to get you started:

1. **Do you offer application, content and identity management?** While most EMM products focus on device management, not all of them cover other aspects of mobile management.
2. **Do you support the platforms and technologies that we use?** Some EMM providers only support certain operating systems and devices. Don't assume they cover everything you need.
3. **What is your security approach for device and data?** Ensure your vendors are using the most advanced encryption and [identity tools](https://auth0.com/security) that comply with your security policies. 
4. **Does the technology integrate with the current infrastructure?** If you have a complex infrastructure, you will want to make sure the EMM solution integrates with your system. 

Choosing the right vendors comes down to analyzing their capabilities within the core competencies of EMM. Take each component and evaluate providers on their capabilities to deliver on these elements.

According to Gartner's Magic Quadrant [report](https://www.air-watch.com/resources/analyst-reports) on EMM:

> There are diverse vendor approaches to managing the mobile lifecycle, with many focusing on identity and access, content security, and containment. To be classified as an EMM suite, Gartner requires inclusion of MDM, MAM and at least one of the following: MIM, MCM or containment technologies. The most advanced suites will include all five technologies.

![gartner-quadrant-report](https://images.ctfassets.net/23aumh6u8s0i/52uhtpHVlYtii773TRiqA3/fcf0154e5fc23e244bc6307a843fd46d/gartner-quadrant-report.png)

While Gartner highlights vendors that try to incorporate several components, finding experts in each area might be a better way to go during the early stages of EMM. Niche providers that focus on one aspect of EMM often develop an expertise and can adapt quickly to the changing market.

Whether you choose an all-encompassing solution or create a suite of niche tools, partner with companies that have a vision for EMM and a roadmap for how their solutions will adapt as mobile matures.

## EMM Solutions Beyond Your Phone or Tablet

<include src="TweetQuote" quoteText="Enterprise mobility management is IT's answer to the employee revolution that forced companies to rethink their technology and data policies."/>

Enterprise mobility management is IT's answer to the employee revolution that forced companies to rethink their technology and data policies. EMM is not retaliation against employee mobility; it is actually the opposite. Companies want to keep their employees mobile and productive.

The future of EMM is going to be exciting as the definition of 'mobile device' expands to other connected devices, such as wearables and personal assistants. When [Alexa](https://en.wikipedia.org/wiki/Amazon_Alexa) starts helping people do their job, EMM will need to be ready.


What is Enterprise Mobile Management (EMM)?

Using multi-tenancy you can cut costs and still allow your customers strict control over their data



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

---

## What Is Multi-Tenancy?

A multi-tenanted software architecture allows you to serve multiple customers from a single application instance running on a single server, or pool of servers. This is in contrast to a single-tenant application where each customer would have a dedicated software instance running on dedicated servers. Thus,

* Multi-tenant: One instance, multiple customers.
* Single-tenant: One instance, one customer.

A tenant is defined as a group of users who share access to that application instance. For instance, this could be a company with multiple employees, all who have access to your SaaS service. In a multi-tenant architecture, a single instance of your application would be shared across multiple companies (tenants), and across multiple employees within those companies.

Every tenant would however have a dedicated share of that instance, and multi-tenant application can then be customized for each specific tenant's need, in particular:

* Branding: Each instance would likely need to be “skinned” to fit with the branding of the organization. This is akin to how [Lock](https://auth0.com/lock) can be customized for each user's login page.
* Functionality: Each tenant may require certain workflow changes that fit better with their business.
* Access Control: Each tenant will want to set the permissions, rights, and roles of their users independently.

## The Benefits of Multi-Tenancy

Building multi-tenant applications conveys a number of benefits for a SaaS company:

**Scalability**: There is overhead associated with spooling up each application instance. Extra processing power and memory is required over and above just that for the single instance. Additionally, resources can be shared across tenants in a multi-tenant architecture.

For example, if a SaaS company had 10 tenants, and each tenant needed just over 1 server to fulfill their requirements (say, 1.1 servers), in a single-tenant architecture this would require 20 servers as each tenant would need dedicated servers. In multi-tenant architectures, only 11 servers are needed, as resources can be shared easier.

**Data Handling:** It is easier for the SaaS company to handle and utilize data when it is aggregated in a single location. In a single-tenant application, data will be spread across multiple databases and will need to be pooled for any further analysis by the SaaS. In multi-tenant, this data is easily available, so running queries across multiple tenants and analyzing trends is simpler.

**Release Management:** In a multi-tenant application, there is just one codebase running on a single server or pool of servers. When a fix has to be implemented to the codebase, it just has to be rolled out to this single instance and there is no need to update multiple servers or locations. For a single-tenant application, each instance will need to be patched independently, and tests run on each.

## Why Multi-Tenancy Is Difficult

Building multi-tenant applications is a challenge as it requires significant planning and forethought to go into the initial coding. As there is no physical separation between different tenants like there would be with single-tenant architectures, all the separation has to be resolved in code. Developers have to:

* determine the tenant a request was intended for
* protect against data leakage
* isolate configurations
* run individual logging and background tasks per tenant

Additionally, as each tenant’s data is stored together, significant security testing is required to make sure each tenant has access to only their data.

## Using Auth0 To Build A Multi-Tenant App

Authentication and authorization are fundamental to multi-tenant architectures. Correctly authenticating individual users within a tenant organization and determining what they are authorized to access are paramount to this software model.

<include src="TweetQuote" quoteText="Authentication and authorization are fundamental to multi-tenant architectures."/>

Learn more about how to use multi-tenant applications within Auth0 in the following link: [Using Auth0 with Multi-tenant Apps](https://auth0.com/docs/saas-apps).

![Creating Auth0 Applications](https://images.ctfassets.net/23aumh6u8s0i/3qddAPTPmpgnrhA484an8Y/fb8914127037a897f112fb041cd7772a/applications)

You can use the [Auth0 API](https://auth0.com/docs/auth-api) to authenticate and authorize users for each application easily:

* **Authenticate** users established by their email address. This could either be through custom email/password combinations with a rule set up to determine the tenant via company email (home realm discovery), or via identity federation such as LDAP, Active Directory, or custom SAML providers.
* **Authorize** users by assigning different roles within the company. This would be managed through metadata.

Metadata in an Auth0 user profile allows you to associate specific information to any authenticated user. In the user profile, Permissions, Groups, and Roles are all special cases of these attributes.

For instance, a user might be authenticated for multiple tenants and have different roles in those tenants:

```json
{
  "email": "matias@auth0.com",
  "app_metadata" : {
    "permissions" : {
      "auth0" : {
        "role" : "admin",
      },
      "sharelock" : {
        "role": "user",
      }
    }
  }
}
```

The logic of the applications can then use this metadata to restrict or allow users access to data and instances as the roles allow.

[Unlock B2B SaaS growth with modern identity management. Download free eBook here.](https://resources.auth0.com/unlock-b2b-saas-growth-iam/)


How To Use Auth0 To Manage Your Multi-Tenant Application

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

Angular 2 forms are powerful and come with many great features. Learn how to create both simple and complex forms, as well as how to do custom form validation.

"control"