Recently, one of my colleagues invited me to an AWS live stream talk she was giving about building secure GraphQL APIs, using Auth0. She’s been… Read More »Discover secure access for GraphQL APIs: an AWS live-stream
Role Based Access Control
Role Based Access Control – more commonly known as RBAC – is a widely used access control method that provides for restriction based on the Role assigned to a user. An RBAC model is typically utilized as a general purpose mechanism for defining the permissions required to enable access authorization.
Hi, I’m Peter Fernandez, an Innovator, Architect, Consultant, Engineer, and Principal Developer Advocate at Auth0 by Okta, and I’m here to tell you more about the Role Based Access Control functionality provided by Auth0.
In the context of RBAC, a Role describes something that a user is part of – such as the Role a user is assigned as part of the organization they work for. In other words, RBAC refers to the assigning of permission(s) based on the more manageable idea of a Role – which may have more than one user as a member – rather than the frequently error prone approach of assigning permission(s) to users individually.
The paper entitled NIST Model for Role-Based Access Control: Towards a Unified Standard, defines four levels that are organized in sequence of increasing functional capabilities: Flat RBAC – where users are assigned to one or more roles and, by virtue, acquire the permission(s) belonging each; Hierarchical RBAC – which adds the dimension of role hierarchies; Constrained RBAC – which further adds the notion of enforcement by separation of duty; and Symmetric RBAC – which adds a requirement for the periodic review of role permission and user role assignment.
Role Explosion happens when the level of granularity needed for access control is too detailed; essentially, where multiple Roles need to be modelled in order to satisfy fine-grained access requirements. It’s one of the most common problems associated with RBAC, and – together with the complexities often encountered when translating enterprise organizational structures into an RBAC model – is considered to be one of the main drawbacks of using the RBAC approach.
Arguably, Role Explosion is best managed by ascertaining the suitability of using an RBAC model in the first instance. Of course, that’s not always possible to do, and a seemingly simple set of access control requirements can easily get more complex over time. Having the ability to easily leverage an alternative model – such as ReBAC – either wholly or in part and without needing to make massive changes to your code, can offer an effective solution to the problem.
You could build support in-house, yourself. That’s true. Click on the image to read more about doing just that, and watch the recording of my related webinar here. If your team has the resources, time, capacity, knowledge, and expertise in developing SSO; deploying Attack Protection; leveraging OIDC and/or SAML for Authentication, Social and/or Enterprise Federation; implementing Passwordless and/or MFA, and/or (optionally) OAuth 2.0 for API Authorization – then it’s definitely an option. But what if there was a better way?
With Auth0, utilize a pre-built comprehensive mechanism for creating RBAC policies that can be leveraged in the applications and APIs you provide. Enabled by Auth0 Universal Login, easily define Roles and Permissions, whilst leveraging additional features for user authentication like SSO, Social, Enterprise Federation and MFA.
Whether you’re building for B2C, B2B, or some combination, Auth0 RBAC gives you complete control out-of-the-box. And via the Authentication API, you can build workflows for solutions that tackle the more complex use case scenarios – all whilst leveraging the full power of the platform at the same time.
Employ Adaptive MFA to add additional authentication factor(s), using intelligent MFA that dynamically fits to customer behaviors. All whilst satisfying your business needs.
Add Flat RBAC permissions as custom Claims to the JWT format tokens used as part of Auth0’s support for OIDC and OAuth 2.0. Or as custom Attributes when using Auth0 SAML assertions.
With a variety of out-of-box options provided by a wide range of SDKs, you can build an initial integration with Auth0, written in any programming language and supporting any technology stack, in a matter of hours. Click on the image to visit the Auth0 SDK website and discover how to integrate with ease.
Read the Auth0 Blog, and follow the example provided to learn more about integrating Auth0 RBAC in your Ruby API.
Helpful Identity & Access Management articles that are timely and relevant, whatever your level of experience. Whether you prefer to learn by reading, listening, watching videos, cloning repos, copying code, or attending a workshop or conference: content is everywhere and made for developers like you. Click on the image to subscribe to the newsletter today!
Sign up here, and create a free Auth0 Tenant to begin your journey. Play with prototyping an integration of your existing code – or develop something new; experience the Okta Customer Identity Cloud, powered by Auth0, in a way that best suits you.
If you’re looking for some inspiration, why not take a look at some of the pre-build demos at demo.okta.com – where you can test-drive sample integrations for both the Okta Customer Identity Cloud and the Okta Workforce Identity Cloud too!
The mechanism of determining eligibility of access to a system is typically referred to as Authorization – a.k.a Authz. Most authorization systems typically provide for the control of both user and machine-level access, which can operate under various policies and with varying degrees of granularity.
Hi, I’m Peter Fernandez, an Innovator, Architect, Consultant, Engineer, and Principal Developer Advocate at Auth0 by Okta. I want to share with you some of my experience building Authorization (a.k.a. AuthZ) workflows into modern applications and how easy it is to do that using the Auth0 platform.
Accessing a system in a user context provides the ability to manage and track permission(s), as well as consent, at a user level. Typically enabled via the use of user authentication, it allows systems to perform a determination of permission based on a particular user – or where something is acting on behalf of that user.
Whilst determining eligibility of access is typically referred to as Authorization, the process of identifying who (or what) has access to a system is typically referred to as Authentication. Be it user authentication or machine authentication – via the likes of SAML or OIDC – Authorization invariable requires Authentication as a pre-requisite to securely verify the credentials used for access.
Access to a system from something other than a user will typically employ the use of machine-level authorization. Whether via the use of some service account or some other device-level credentials, in this case, machine authentication would normally be used to perform credential verification – establishing a security context from which permission(s) can then be derived.
The permission(s) assigned to a user or a machine will typically play a part in determining the level of access. For a user, this may have a bearing on what is available via any user interface experience and will ultimately impact the functions(s) the user can perform. For a machine – i.e. an account in a non-user context – permission will determine what functionality is available and, by virtue, the operations that can be performed.
With the rise of the API fueling growth in resource services across the internet, the notion of Consent was created as a fundamental part of the OAuth 2.0 specification. An integral part of Delegated Authorization, Consent gives a user the ability to authorize the scope of operation(s) an application can perform when it’s accessing their resources whilst acting on their behalf.
Authorized access is largely a factor of the Permission(s) and Consent defined. Typically known as Access Control, it is most commonly categorized into one of the following: Role Based Access Control – usually referred to as RBAC; Attribute Based Access Control – more commonly known as ABAC; ReBAC, which offers Relationship Based Access Control; or any one of the other models defined. Though less common, more than one of these models can be employed in a system simultaneously.
Access Control is also commonly associated with what is known as an Authorization Policy. An Authorization Policy is typically comprised of a number of distinct parts – usually referred to as “points”: a Policy Decision Point (a.k.a. PDP), a Policy Enforcement Point (a.k.a. PEP), and a Policy Information Point (a.k.a. PIP) to name but a few. Which of these are implemented is typically determined by the Access Control model(s) employed.
Granularity typically relates to the enforcement of Access Control – usually enacted by the PEP – and, by virtue, the degree of access control precision required. Fine Grained Authorization, for example, is typically the province of a PEP employing access control at a level nearest to the protected resource itself. And will typically leverage a PDP with corresponding capability. In short, the lower (or finer) the granularity, the more precise you can be about exactly what access is controlled…and how.
You could build support in-house, yourself. That’s true. Click on the image to read more about doing just that, and watch the recording of my related webinar here. If your team has the resources, time, capacity, knowledge, and expertise in developing SSO; deploying Attack Protection; leveraging OIDC and/or SAML for Authentication, Social and/or Enterprise Federation; implementing Passwordless and/or MFA, and/or (optionally) OAuth 2.0 for API Authorization – then it’s definitely an option. But what if there was a better way?
It all starts with Authentication, and for user authentication, Auth0 Universal Login is the key to unlocking the plethora of capabilities provided by Auth0. From out-of-the-box RBAC, to customized Access Control via Extensibility and the scalable service of FGA, Universal Login provides the required first steps as part of the user login process.
But User Authentication is just a part of the story! Whether you’re building for B2C, B2B, or some combination, the Auth0 Authentication API also provides full access to all of Auth0’s Authentication capabilities – making it easy to leverage machine authentication or other custom authentication use cases as part of authorization.
Leverage the power of OAuth 2.0 to protect your APIs, using the extensive Authorization Server capabilities delivered by Auth0.
With FGA, take access control to a whole new level, and build complex ReBAC (Relationship-based Access Control), ABAC, or custom strategies using a powerful SaaS based API secured by Auth0.
Perform Role Based Access Control out-of-the-box, and discover how Auth0 can help you to implement an RBAC strategy with minimal effort.
Customize identity flows with visual drag and drop Actions to build functionality that will address your unique requirements.
With a variety of out-of-box options provided by a wide range of SDKs, you can build an initial integration with Auth0, written in any programming language and supporting any technology stack, in a matter of hours. Click on the image to visit the Auth0 SDK website and discover how to integrate with ease.
Read the Auth0 Blog, and learn more about integrating Authorization within your application using Auth0.
Okta provide a wide-range of courses to help you level-up your skills. Why not click on the image to see what you can discover with Okta Training today!
Whatever scenario you’re building for, Auth0 has comprehensive guidance to help you navigate through the design decisions often faced when building a Customer Identity & Access Management solution. Let our architecture scenario guidance for both B2C and B2B help you prepare for any eventuality.
Helpful Identity & Access Management articles that are timely and relevant, whatever your level of experience. Whether you prefer to learn by reading, listening, watching videos, cloning repos, copying code, or attending a workshop or conference: content is everywhere and made for developers like you. Click on the image to subscribe to the newsletter today!
Sign up here, and create a free Auth0 Tenant to begin your journey. Play with prototyping an integration of your existing code – or develop something new; experience the Okta Customer Identity Cloud, powered by Auth0, in a way that best suits you.
If you’re looking for some inspiration, why not take a look at some of the pre-build demos at demo.okta.com – where you can test-drive sample integrations for both the Okta Customer Identity Cloud and the Okta Workforce Identity Cloud too!
Delegated Authorization
Today’s rich applications support system expansion at an unprecedented rate. Resource servers, more commonly known as APIs (Application Program Interfaces), do away with many of the development requirements needed to build the more traditional web applications and enable the likes of Mobile Apps, SPAs (Single Page Applications), etc.
Hi, I’m Peter Fernandez, an Innovator, Architect, Consultant, Engineer, and Principal Developer Advocate at Auth0 by Okta. Here, I want to share with you some of my experience building APIs that allow safe, secure and consented access to resources using the Auth0 platform.
Basic Authentication is a method whereby an HTTP user agent – e.g. a web browser – can provide explicit UserID and Password credentials when making an API request. Typically encoded as a string, this information is passed in the (HTTP) Authorization header of each API request. Basic Authentication typically requires explicit verification of UserID and/or Password credentials – so it doesn’t work well for the likes of Social or Enterprise Federation authentication scenarios.
An API key is typically a unique identifier used to authorize access to an API. Whilst an API Key can be used as part of access based on a user context, they’re typically used to perform authentication and authorization where there is no human interaction at all; an API Key is a fixed credential that is usually context agnostic. This essentially precludes the ability to leverage a context that is user-specific and user-consented, let alone making them fundamentally insecure in cases where public clients, such as Mobile Apps or SPAs, are used.
Implementing user context authorization using the likes of Basic Authentication or an API Key is problematic for the reasons previously described. The solution to the problem is to use Delegated Authorization. As defined by the OAuth 2.0 protocol, Delegated Authorization delivers what is typically referred to as a Bearer Token. A Bearer Token is a type of secure, dynamically generated security artefact that is based upon a user-specific context, and leverages user authentication typically provided by some (independent) IdP.
In OAuth 2.0, a Bearer Token is typically called an Access Token and is generated by an (OAuth 2.0) Authorization Server based on an authenticated user context. What an Access Token token looks like is not specifically defined by the protocol. And whilst OAuth 2.0 is typically easy to manage – requiring minimal configuration – there’s much to understand when it comes to integrating the protocol; despite being an industry standard, there are many workflow options that implementers can omit.
The notion of Consent is a fundamental part of the OAuth 2.0 specification, and gives a user the ability to authorize the Scope of operation(s) an application can perform when it’s accessing their resources whilst acting on their behalf.
Scope is the mechanism in OAuth 2.0 whereby an application defines the access desired. An application can request user consent to one or more scopes, and the Access Token issued will be limited to the scopes granted by the consent provided by the user (typically via some interactive UI).
Arguably, OAuth 2.0 was initially developed to provide Access Tokens – a.k.a. Bearer Tokens – that could be used by applications making calls to APIs developed by third-party vendors. As this allowed applications to access user-specific, third-party resources on behalf of a user, the notion of consent was always a first-class citizen.
However, as OAuth2.0 gained in popularity, more and more application developers discovered the value of using the protocol for accessing (web-based) APIs that they themselves provided – i.e. first-party APIs provided in support of their own applications – as well as for third-party consumption. This meant that consent was no longer something that necessarily needed to be explicitly provided but instead could be something that was implied (i.e. dependent on what was accessing the API).
You could build support in-house, yourself. That’s true. Click on the image to read more about doing just that, and watch the recording of my related webinar here. If your team has the resources, time, capacity, knowledge, and expertise in developing SSO; deploying Attack Protection; leveraging OIDC and/or SAML for Authentication, Social and/or Enterprise Federation; implementing Passwordless and/or MFA, and/or (optionally) OAuth 2.0 for API Authorization – then it’s definitely an option. But what if there was a better way?
With Auth0, say hello to a fully featured Authorization Server that provides APIs with the ability to support user resources accessed securely on behalf of a user and with that user’s consent. Starting with Auth0 Universal Login, easily leverage features for user authentication like SSO, Social, Enterprise Federation and MFA before generating Access Tokens using OAuth 2.0.
Whether you’re building for B2C, B2B, or some combination, the Auth0 Authorization Server delivers OAuth 2.0 functionality at scale. Via the Authentication API, you can also access OAuth 2.0 workflows, such as Device Authorization Flow – that provide solutions when tackling the more complex use case scenarios involving the use of input-constrained devices. All whilst leveraging the full power of the platform at the same time.
With Auth0, Access Tokens are consistently expressed in the self-contained, industry standard, secure JSON Web Token (JWT) format.
Provide additional levels of security on the OAuth 2.0 Refresh Token standard, with Refresh Tokens Rotation provided by Auth0.
Employ Adaptive MFA and deploy fine-tuned Step-Up Authentication using intelligent MFA that dynamically fits customer behaviours. All whilst satisfying your business needs.
Customize identity flows with visual drag-and-drop Actions to build functionality that will address your unique requirements.
With a variety of out-of-box options provided by a wide range of SDKs, you can build an initial integration with Auth0, written in any programming language and supporting any technology stack, in a matter of hours. Click on the image to visit the Auth0 SDK website and discover how to integrate with ease.
Read the Auth0 Blog, and learn more about integrating Authorization within your APIs, leveraging Access Tokens generated by Auth0.
Okta provide a wide-range of courses to help you level-up your skills. Why not click on the logo to see what you can discover with Okta Training today!
Helpful Identity & Access Management articles that are timely and relevant, whatever your level of experience. Whether you prefer to learn by reading, listening, watching videos, cloning repos, copying code, or attending a workshop or conference: content is everywhere and made for developers like you. Click on the image to subscribe to the newsletter today!
Sign up here, and create a free Auth0 Tenant to begin your journey. Play with prototyping an integration of your existing code – or develop something new; experience the Okta Customer Identity Cloud, powered by Auth0, in a way that best suits you.
If you’re looking for some inspiration, why not take a look at some of the pre-build demos at demo.okta.com – where you can test-drive sample integrations for both the Okta Customer Identity Cloud and the Okta Workforce Identity Cloud too!
Relationship Based Access Control
Relationship Based Access Control – more commonly known as ReBAC – is a popularized access control method that provides for restriction based on relationships. Typically implemented at a level closest to the protected object (i.e. the protected API route or particular Application UX), a ReBAC model can be used to define the permissions required to enable authorized access at a fine granularity.
Hi, I’m Peter Fernandez, an Innovator, Architect, Consultant, Engineer, and Principal Developer Advocate at Auth0 by Okta, and I’m here to tell you more about Relationship Based Access Control provided by Auth0.
A relationship is a connection between a subject – typically a user – and the object being protected (such as a protected API route or a particular Application UX). Multiple, interconnected relationships can be built, allowing a fine definition of access control granularity to be modelled.
At the other end of the scale are models that don’t typically allow for such fine granularity. RBAC, for example, though initially often easier to build and deploy, typically offers far precision over exactly what is access controlled, and how.
ReBAC will typically allow for the modelling of other paradigms – such as RBAC and/or ABAC – and offers granularity of access that scales to allow a system to control exactly how many authorization checks need to be performed, when, and how. Irrespective of whether that resource is some Application UX, or some resource accessed via an API.
You could build support in-house, yourself. That’s true. Click on the image to read more about doing just that, and watch the recording of my related webinar here. If your team has the resources, time, capacity, knowledge, and expertise in developing SSO; deploying Attack Protection; leveraging OIDC and/or SAML for Authentication, Social and/or Enterprise Federation; implementing Passwordless and/or MFA, and/or (optionally) OAuth 2.0 for API Authorization – then it’s definitely an option. But what if there was a better way?
FGA is Auth0’s ReBAC – i.e. Relationship Based Access Control – SaaS system that’s based on Google Zanzibar. Available for self-hosting via OpenFGA – or currently available as a hosted Developer Preview – Auth0 makes it easy to enable collaborative relationships, going far beyond the typical Role-Based Access Control (a.k.a. RBAC) model. The more we’ve spoken to developers just like you, the more we’ve learned just how many use cases it can solve.
Auth0 FGA makes fine-grained authorization fast, scalable, and easy to use. It also supports building customized control, empowering new perspectives on how to manage access. A developer-friendly, API-first solution, FGA offers a way to enable highly secure collaborative and granular access control at any level, anywhere in your application(s). Leveraging Authorization powered by Auth0, build granular access control using an easy-to-read modelling language and friendly APIs.
Build customized models to handle complex scenarios and emulate the likes of RBAC, ABAC or any other system of access control with Auth0 FGA. Click on the image to check out the handy modelling guides provided right out of the box.
With Auth0 FGA, take access control to a whole new level! Build complex hierarchies and leverage object-level atomicity using a powerful SaaS-based API. Click on the image to learn more.
Configure the Auth0 FGA API to leverage OAuth 2.0 utilizing Authorization provided by Auth0 and take full advantage of all the features offered by the Auth0 platform as standard.
With the Auth0 FGA SDK, you can start building an initial integration in a matter of hours. Click on the image to visit the website and discover how to integrate with ease.
User collaboration and granular access control are enabled in your applications and resource servers using the developer-friendly SDKs and APIs provided by Auth0’s FGA. With full-featured auditing capabilities included as standard, FGA provides the fundamental building blocks for implementing authorization at scale. Visit openfga.dev and try it out for yourself, or sign up for the Developer Preview at auth0.com/fine-grained-authorization!
Take a look at the Auth0 Blog, and learn how integrating a fine-grained model can help you streamline implementation when it comes to Authorization.
Helpful Identity & Access Management articles that are timely and relevant, whatever your level of experience. Whether you prefer to learn by reading, listening, watching videos, cloning repos, copying code, or attending a workshop or conference: content is everywhere and made for developers like you. Click on the image to subscribe to the newsletter today!
Sign up here, and create a free Auth0 Tenant to begin your journey. Play with prototyping an integration of your existing code – or develop something new; experience the Okta Customer Identity Cloud, powered by Auth0, in a way that best suits you.
If you’re looking for some inspiration, why not take a look at some of the pre-build demos at demo.okta.com – where you can test-drive sample integrations for both the Okta Customer Identity Cloud and the Okta Workforce Identity Cloud too!
Hi 👋 I’m an Identity and Access Management specialist and ex Principal Developer Advocate at Auth0 by Okta. As an Innovator, Architect, Consultant and Engineer, I have have more than 30 years of experience designing and developing secure and robust software solutions. And when I’m not helping folks with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.