Software organizations have come to rely heavily on identity providers (IdPs) like Okta and Azure AD for their authentication and authorization needs. However, while these tools are often used for both purposes, they were actually designed with a primary focus on authentication. So, what's the difference between authentication and authorization? And more importantly, is there a way to utilize an IdP that results in your organization having a better security posture?
We'll explore how software organizations are currently using their IdPs and why the difference between authentication and authorization is so critical when it comes to IdP solutions.
Laying the groundwork: authorization vs. authentication
Understanding how to utilize an IdP tool correctly and securely means first understanding the differences between authorization and authentication. You also need to grasp why it's best from a security and management perspective to have distinct implementations of each.
Authentication, or AuthN, entails the verification of a user or entity’s identity. This involves providing credentials, such as a username and password, digital certificate, or multi-factor authentication (MFA) code, to prove that the user or identity is who they claim to be. The authentication process typically compares the provided credentials with a stored database of authorized entities to confirm the identity of the user. Once authentication is complete, the user is granted access to the system or resource.
Authorization, or AuthZ, on the other hand, entails granting or denying access to resources based on the authenticated user's level of permission or privilege. Authorization involves determining what actions a user is allowed to perform and what data they are allowed to access within the system. This is typically based on a set of rules or policies that define the level of access granted to different users or groups of users. The typical components of authorization include policy documents, general security configuration, and ephemeral access tokens.
In the modern landscape, IdP solutions are commonly used for both AuthN and AuthZ. However, relying solely on IdP isn’t an optimal solution, and it means an organization isn’t as secure as they could be.
Why IdPs weren’t built for AuthZ
In the modern landscape, IdP solutions are often employed to provide both mechanisms, but that might not be the ideal approach. Using an IdP tool as a "one-stop shop" for AuthN and AuthZ is just one of many anti-patterns when it comes to handling identity security on a modern cloud platform.
IdPs don’t keep up with dynamic authorization
SAML-based systems like IdP aren't designed to handle cloud authorization; cloud platforms are dynamic, shifting environments where the resource landscape is constantly in flux. Greenfield resource provisioning usually results in administrators being forced to use the logical organization mechanism of AuthN, the group, to handle permissioning for the resources themselves, which isn’t ideal. Larger cloud deployments will force these administrators into constantly changing and growing group policies to account for an expanding footprint, inevitably leading to sprawl and overlapping policies.
Ineffective for monitoring access changes
Getting AuthN and AuthZ infrastructure set up is only part of the story. The visibility IdPs provide is very limited. You may know which groups an individual belongs to, but it’s very difficult to determine which permissions a person has. This makes monitoring and auditing access-related changes extremely difficult. Much of the data does is not being tracked, for example, who has access? why was it given? Who approved it? Are elevated privileges being tracked and explicitly flagged for analysis and potential alerts? What about compliance/auditing?
In the midst of a SOC2 audit, having identity behavior logged in an easy-to-access and parse format is a massive advantage; otherwise, precious engineering cycles are spent hastily scraping and collating this data to meet auditor deadlines.
IdPs are designed for identities and groups, not permissions and resources
Using Okta, Google, or even AD to manage permissions is a red flag. An IdP is structured in a way that supports the concept of groups to organize and assign permissions to IAM identities. While this can be useful and lets you avoid having to individually assign permissions, it falls short when it tries to play the same role for dynamic authorizations.
Group permissions are static and not a result of an elevation mechanism; if a user joins a group with elevated permissions, they will always have those permissions until they leave the group, regardless of need or context. Groups also don't scale well with granular resource usage.
Different resources may require different permission models based on the use case, even for IAM identities within the same group context. This results in multiple groups being assigned with slightly different policies, adding to complexity, leading to a role explosion ,and the likelihood of over-permissioning.
A better way to manage authorizations
Splitting the AuthZ component off from the IdP, leaving it to handle AuthN creates a separation of concerns, which improves security posture and enables engineering teams to choose the best tools for each component of their IAM infrastructure.
Implementing the correct IAM infrastructure requires making pragmatic choices about tooling. You also need dedicated cycles to design the system alongside planned and existing application infrastructure. If IAM is treated as an afterthought to other systems, security will suffer. The right AuthZ solution needs to provide intuitive features and enable IAM engineers to implement systems and processes that will provide a secure identity infrastructure that scales in concert with the applications and staff it supports.
Proactive policy definitions
If IAM engineers are constantly crafting bespoke AuthZ policy documents, the process is broken. New resources should have context-focused and least-privilege policies by default. As the organization grows and more software developers are added, the need for policy implementation will only get more demanding.
Without scalable mechanisms in place, IAM engineers will inevitably become overwhelmed and held responsible for blocking feature work. What happens then? The dreaded "admin-for-everything."
Automate access provisioning
Automated provisioning of IAM policies based on dynamic resources offers a more flexible and efficient approach compared to static user/group associations mentioned in the previous section. This method enables automatic adjustments to access rights as resources and user needs change, reducing the administrative burden and minimizing the risk of outdated permissions. As an added benefit, dynamic and just-in-time provisioning enhances security by ensuring that users only have the necessary access at any given time, which reduces the potential attack surface and helps prevent unauthorized access to sensitive data or systems.
Make permissions a frictionless process
Users that need elevated permissions should have access to a simple self-service platform. Approvers and administrators should be able to easily evaluate whether permission should be granted based on the relevant information provided in the request. The request also needs to be visible and easily accessible. Having to comb through multiple admin dashboards to address a request represents friction in the system.
It should also be a simple proposition to provide auditors and analysts with needed information on historical requests for elevated privilege, including relevant metadata that can identify the "who," "what," and "where" of the request.
Be able to monitor authorizations
Security operations staff should have real-time visibility into identity behavior inside a cloud environment. Role-assumption, elevated access, and service-account behavior are some items you should monitor. Configure active detection of anomalous/outlier behavior, as this often provides the earliest tell-tale signs of a potential compromise.
Good tooling provides intuitive dashboards that surface the right information at the right time, as well as integrations with other industry-standard monitoring solutions. For example, when access changes are tracked, security teams can receive SIEM alerts upon users obtaining access to sensitive resources or roles.
Treat your IdP like It’s part of the customer-facing application
Organizations should design IAM architecture to scale with the applications it supports. If developers can’t easily get the permissions they need, or policies become brittle and complex, software delivery slows down and the security posture ultimately gets worse. User-friendliness should be a key feature for both users and administrators. IAM architecture should be looked at as a first-class system and a "Tier-0" dependency for every other system and service in the stack.
The right tool for the job
Your IdP platform shouldn't be a fire-and-forget, all-in-one solution for IAM. IdP and AuthN should be one component of a larger, holistic identity infrastructure with a separate tool for AuthZ. Understanding common implementation mistakes means knowing how to avoid them and achieving a better security posture. Investing time in the proper design and deployment of strong IAM solutions from the beginning will pay for itself many times over as your software organization scales.
