Authentication and Authorization Design Considerations for Enterprise Applications

In large organizations, it’s common to run many apps for both employees and external users. As things scale, managing identities through a central Identity Provider (IdP) becomes crucial but it’s not always straightforward or a one-size-fits-all solution. Different user types mean different login flows, user stores, and common traps around tokens and access control.

From this post you can learn how to deal with workforce and external identities, improve the login experience, avoid common mistakes, and make smarter choices around authentication and authorization.

From Internal Systems to Unified Identity Management

In the early days of enterprise software, implementing access control for internal applications was relatively straightforward. Organizations operated in a tightly controlled environment: all users were employees, all applications were internal, and everyone was usually sitting under the same roof or at least connected to the same corporate network. Access control was as simple as assigning roles based on job titles or departments, with minimal need for external integrations or complex identity workflows.

There were no business-to-business (B2B) scenarios, where partners, vendors, or contractors required controlled access to internal systems. There were no business-to-consumer (B2C) concerns involving millions of customers signing in from around the world. Identity federation across different systems or domains wasn’t even known. Each application maintained its own isolated user store, and IT departments had full ownership of user provisioning, access enforcement, and deprovisioning. In short, access control used to live in a closed and predictable world.

However, the modern landscape looks very different. Today’s applications are accessed by a variety of users: internal staff, remote employees, external collaborators, and even customers. These users may authenticate through different identity providers (IdPs), such as Microsoft Entra ID, Okta, Auth0, Google, or even social login systems. Organizations operate in hybrid environments with on-premise and cloud infrastructure, and applications are often spread across regions, clouds, and even vendors. This shift introduces significant complexity in managing access.

From Workforce to External Identity: A Change in Thinking

It is worth starting with the mindset. In many organizations, managing workforce identities has reached a relatively mature stage. Methods, processes, and tools are in place, often backed by years of optimization and iteration. But here’s the catch: the same mindset that works well for internal identity management often fails when extended to external users: customers, partners, contractors, or citizens.

A common mistake organizations make is assuming that the same approaches, frameworks, and governance models for internal users will scale or translate seamlessly to external identity use cases.

The reality is, external users come with very different expectations:

• They don’t want to be onboarded like employees.

• They demand seamless, fast, and self-service access.

• Trust is not implicit, it has to be earned and maintained.

This means organizations need to rethink identity UX, consent management, federation models, and even what “access” means. External identity is not just about security - it’s also about customer experience, brand trust and user isolation.

It also impacts architectural decisions. Workforce IAM tools typically emphasize centralized control, but external identity systems, especially in B2C or B2B2C scenarios, must prioritize scale, flexibility, and decentralization. A common mistake I see is placing all user types into the same directory. Over time, this leads to a situation where employee and external user accounts are mixed together, making access management increasingly difficult and complex to maintain.

So before diving into tech or tooling, pause and reassess your mental model. Managing external identities is not just a variation of workforce IAM. It’s a different discipline altogether.

Common Pitfalls in Authentication Handling and Design

In workforce identity management and enterprise security, the goal is typically to use the most secure authentication methods, ideally avoiding passwords altogether or supplementing them with MFA, preferably using phishing-resistant techniques. However, authentication journeys and methods need to be carefully planned for both employees and external users. These approaches won't be the same, and the right choice depends on a variety of factors. Let's dive into some scenarios here.

Differences in authentication methods for workforce and external identities

Authentication strategies must account for the fundamental differences between workforce and external users. What works well in an enterprise context often doesn’t translate effectively to consumer-facing scenarios.

Take FIDO2 security keys as an example. These are highly secure and effective for workforce users, especially in regulated industries or environments with strict compliance requirements. Employees can be issued physical keys, onboarded with training, and supported by internal IT. But the same model breaks down for customers or partners, it’s unrealistic to expect a casual user or consumer to buy, register, and manage a hardware key just to access your service.

Another example is multi-factor authentication (MFA). Within an organization, it’s reasonable to expect employees to use an authenticator app, or even push-based MFA via a mobile device. These methods are secure and scalable in an enterprise environment. However, for external users, especially in a B2C context, these same methods can be a barrier. Many customers prefer simpler approaches, like receiving a one-time password (OTP) via SMS or email, even though these are less secure. In these cases, convenience and usability often outweigh absolute security.

Context and risk also play a big role. For internal users, authentication methods can be tightly controlled and tailored to role-based access or device compliance. For external users, the experience must be designed for scale, diversity of devices, and minimal friction. You may not control the devices customers use, nor can you assume a consistent level of technical literacy.

In short, authentication strategies must be adapted to the audience. Internal identity is about managing known users in controlled environments. External identity, on the other hand, is about enabling access for unknown or semi-known users in a way that balances security, usability, and trust.

Target user store and profile isolation

A common identity architecture mistake is failing to separate internal and external user accounts. Often, the same Identity Provider (IdP) and directory are used for both internal applications (for employees) and external ones (for customers, partners, or contractors). While this may seem efficient, it often leads to long-term challenges.

When all accounts are stored in the same directory, issues quickly arise:

• Security: Internal directories often connect to privileged systems. Extending access to external users increases risk. A compromised customer account should never impact core infrastructure.

• Compliance: Customer data may be subject to different regulations (e.g., GDPR). Mixing it with workforce data complicates consent management and data handling policies.

• Management complexity: Access policies, roles, and entitlements become harder to manage when all users share the same identity plane. This often requires complex rules and workarounds.

A better strategy is to isolate identities, either logically or physically. This could mean using separate directories or tenants, or adopting a dedicated CIAM platform for external users. It’s also critical to define how applications will be accessed and how user profiles will be managed. External users often need self-service tools and consent flows, while internal users are usually provisioned through HR systems. In short, mixing user types in one system can create friction, risk, and overhead. Early planning for identity isolation helps ensure a more secure, scalable approach.

There is another important scenario to consider. When an application needs to be accessed by both workforce and external users. In these cases, it’s essential to support authentication for both user types. One common approach is to set up federation between the workforce identity provider and the external identity provider (CIAM solution). This allows both internal and external users to sign in and access the application through their respective identity systems.

Data in the ID Tokens

Once a user is successfully authenticated, the application receives an ID Token (in the case of OpenID Connect). This token contains basic information about the authenticated user, such as their email address, unique identifier (sub), first name, and last name. In addition to these standard attributes, the ID Token can also include custom claims, such as user roles.

This is where Role-Based Access Control (RBAC) often comes into play. In many enterprise environments, users are assigned to specific roles, and those roles determine what actions or resources the user can access. It's a widely adopted model because it simplifies permission management at scale. However, there are a few common pitfalls:

• Hardcoding roles in tokens can lead to stale data if roles change but the token hasn’t expired.

• Overloading roles with too many permissions can reduce granularity and create security risks.

• Reusing roles across internal and external users can blur access boundaries and lead to unintended privilege escalation.

In short, while including roles in ID Tokens can be powerful, it’s important to carefully design and manage RBAC to avoid common security and operational issues.

When designing authentication and authorization flows, especially in systems that rely on ID tokens (such as those following OpenID Connect), it’s easy to fall into a subtle but problematic trap: embedding application-specific roles into the ID token. At first glance, it might seem like a convenient solution. After all, if an application needs certain roles to manage access internally, why not just include them directly in the ID token? This way, everything is bundled together and ready to use as soon as the token is issued. However, there is one important thing to take under consideration: roles tightly coupled with application-specific logic often don’t belong in a shared or reusable token. Let’s break this down.

Sometimes, roles are defined that only make sense within the context of a particular application roles like ReportViewer, InvoiceApprover, or CMSContentEditor. These roles reflect very specific business logic or UI-level responsibilities that don’t have relevance outside of that individual app. When these roles are included in an ID token, especially one intended for use across multiple services or systems we run into a few problems:

• Lack of Reusability: These roles aren’t valid or meaningful in other applications. Including them in a token that’s consumed across a broader ecosystem leads to unnecessary coupling between systems.

• Token Bloat: ID tokens become larger and cluttered with information that some consuming applications don’t need or understand.

• Maintenance Burden: Over time, keeping track of which roles belong to which applications and where they should or shouldn’t appear becomes a maintenance nightmare.

• Security Risks: Leaking unnecessary information across service boundaries increases the potential attack surface and can reveal implementation details unintentionally.

Instead of pushing application-specific roles into the ID token, consider a cleaner separation of concerns:

• Use claims in the ID token to indicate general-purpose access rights (e.g., admin, user, editor) that are meaningful across your ecosystem.

• Delegate application-specific role logic to the application itself, or to a dedicated authorization service that the application can query when needed.

This approach keeps your tokens lean, your systems decoupled, and your architecture more adaptable to change. Here we naturally come across authorization topic and its challenges.

Authorization Design Flaws: Considerations and Tight Coupling Risks

Once proper authentication is in place, the next critical step in securing your application is designing and implementing authorization. In the early days of web development, Role-Based Access Control (RBAC) was the go-to solution. It was simple, familiar, and most importantly, got the job done for many common use cases. Traditionally, RBAC meant assigning users to roles like admin, editor, or viewer, and then embedding that information directly in authentication tokens, whether in ID tokens (used by client applications) or Access tokens (used by APIs). This approach worked reasonably well in smaller systems or where roles were consistent across applications and rarely changed. But enterprise systems today are far more complex and this older model doesn’t always scale.

Let’s be fair: including roles in tokens can still be a valid approach under certain conditions. For example:

• The system has a small number of clearly defined roles.

• Those roles are shared and meaningful across the entire ecosystem (e.g., employee, manager, admin).

• Roles don’t change frequently, or the system can tolerate a delay in reflecting changes (e.g., when a new token is issued).

• The roles map cleanly to authorization logic that doesn’t need context about the application's internal behavior.

If all of those boxes are checked, using RBAC with roles embedded in tokens might be good enough. But let’s be honest. Most real-world systems don’t look like that anymore.

In modern enterprise systems, we often encounter dynamic and fine-grained authorization requirements:

• A user might have different levels of access depending on context (e.g., which department, resource, or customer account they’re interacting with).

• Roles might need to reflect temporary permissions, like access granted through delegation or approval workflows.

• Authorization data is often tightly coupled to application logic, making it hard to define global roles that make sense across multiple services.

Even if we try to move some of that data into the Access Token instead of the ID Token, we hit a similar wall. The Access Token might carry specific claims or permissions that only make sense to a particular application. But here’s the catch: The API (or protected resource) consuming that Access Token does not understand application-level logic. An API should be able to make authorization decisions independently of any specific client. It shouldn't need to decode roles that were defined in a frontend app or depend on assumptions baked into another service’s design.

To address this, many organizations are moving beyond RBAC and adopting more flexible approaches such as:

• Attribute-Based Access Control (ABAC): Decisions are made based on attributes of the user, the resource, and the request context.

• Policy-Based Access Control (PBAC): Centralized policies (often using languages like Rego with Open Policy Agent) define what is allowed and why.

• Externalized Authorization Services: APIs call out to a dedicated authorization service that evaluates the current context and returns a decision.

This shift allows for more dynamic, context-aware decisions without overloading tokens or coupling systems too tightly. It also makes it easier to update rules without needing to re-issue tokens or change Identity Provider configuration. Embedding roles or permissions in tokens may seem convenient, and in some cases, it’s a workable solution. But as systems grow in complexity, this approach starts to show its limitations. Authorization logic becomes harder to manage, tokens become bloated or stale, and responsibilities become blurred between clients and APIs. Modern systems demand more flexible, decoupled, and dynamic authorization models - models where APIs are in control of their own decisions, and where identity is just one input into a larger, more thoughtful process.

If you would like to learn more specifically about authorization design, I encourage you to read my another post: Authorization - what, how, and why?

Summary

Managing identities in large organizations is complex, especially when supporting both internal and external users. In this post, we discussed key considerations for using a central Identity Provider (IdP), highlighted common challenges with authentication methods and token handling, and provided practical guidance for improving authentication and authorization strategies in modern enterprise applications.