Authorization systems determine the eligibility of permission via the mutual mechanisms of access control and consent.
Authorization systems control both user and machine-level access, operating under various policies and with varying degrees of granularity.
Hi, I’m Peter Fernandez, and as a CIAM expert, I want to share my experience building modern Authorization (a.k.a. AuthZ) into modern applications.
User Authorization
Typically enabled via some user authentication mechanism, user authorization allows systems to track and determine access based on a combination of Permission and/or Consent.
Client Authorization
Determining access for something other than a user will typically employ client-level authorization, with Client Credentials, a service account, or some other authentication mechanism that provides the context from which Permission(s) should be derived.
Access Control
Access Control refers to what something or someone is permitted to do, and 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); or ReBAC, which offers Relationship-Based Access Control.
Consent
With the rise of the API, Consent was incorporated as a fundamental aspect 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.
Authorization vs Authentication
Whilst determining eligibility for 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 (a.k.a. AuthN). Be it in a user context — via the likes of SAML or OIDC — or in a client one (i.e. using Client Credentials), Authorization invariably requires Authentication as a pre-requisite to securely verify the credentials used for control of access and consent.
Click to follow
Buy vs DIY
You could build an in-house custom solution yourself…it’s certainly an option. Particularly if you have a team with the time, capacity, knowledge, and expertise to develop SSO; deploy and maintain Attack Protection; leverage OIDC and/or SAML for Authentication, Social and/or (Enterprise) Federation; implement Passwordless, Passkeys and/or MFA, and/or optionally OAuth 2.0 for API Authorization.
The alternative is to integrate with a SaaS solution provided by one of the popular vendors, and the cost of subscribing to one of these typically depends on the features you use and the number of active consumer identities you have.
With vendor-based CIAM the cost is typically associated with the platform hosting the backend service(s) that deliver Authentication, Authorization, Management and Protection from attack. With consumer-oriented software, much of this infrastructure is already in place: cloud-based “compute”, database, network resources, etc. could be a necessity for your solution, and delivering these at scale may be something you also need to do.
Deploying a standards-based open-source DIY solution within your existing infrastructure might provide a more cost-effective approach — delivering secure and robust CIAM without the need to build everything yourself and with the added benefit of more flexibility and control.
Got questions?
Feel free to reach out!
