What is Authorization?

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.

User Authorization

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.

Authorization vs Authentication

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.

Machine Authorization

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.

Permission…

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.

….vs Consent

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.

Access Control

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.

Policy

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

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.

Build it yourself?

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?

Start with Universal Login…

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.

…or use the Authentication API

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.

Integrate with ease

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 more about it on the Auth0 Blog

Read the Auth0 Blog, and learn more about integrating Authorization within your application using Auth0.

Want to learn more?

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!

Architected Scenario Guidance

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.

Begin the journey…

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.

…or try a Demo.

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!