Identity and Permission Architecture
Identity and permission architecture separates proof of identity from the policies that determine what a person or service may do, within which organization or resource scope, and under what auditable conditions.
Key takeaways
- Authentication, federation, delegated access, and authorization solve different problems.
- Interface hiding is not authorization; every protected operation needs server-side enforcement.
- Simple roles are preferable until real policy requires attributes, relationships, approvals, or contextual rules.
Four boundaries that should not be conflated
Authentication establishes an identity. Single sign-on federates that process through an identity provider. OAuth authorizes delegated access to an API. Application authorization evaluates permissions for the requested action and resource.
A product may use all four, but adopting one does not supply the others. Claims, tokens, sessions, memberships, and local permissions require explicit mapping.
- Authentication and session lifecycle
- Federated sign-in through SSO
- Delegated API access through OAuth
- Application authorization and resource scope
Model permissions around actions and scope
Permissions should describe protected actions, while roles group permissions for understandable responsibilities. In multi-tenant systems, membership and role scope belong to an organization rather than to the user globally.
When decisions depend heavily on ownership, record relationships, transaction state, risk, or time, pure RBAC may need contextual policy. Complexity should follow demonstrated rules rather than speculative flexibility.
- Resource and action permissions
- Tenant or project scope
- Role assignment authority
- Approvals and separation of duties
Enforcement and security consequences
Authorization should execute at a trusted server or service boundary and default to denial when policy is absent. Tokens need issuer, audience, signature, time, and required-claim validation according to the selected protocol.
Account recovery, deprovisioning, session revocation, emergency access, service identities, credential storage, and audit history are part of the architecture—not later interface details.
Testing, operations, and maintenance
Tests should cover allowed and denied paths, tenant boundaries, role changes, stale sessions, deactivated accounts, administrative overrides, and direct API requests. Permission changes need review because broadening a role can alter many workflows at once.
SSO also introduces identity-provider configuration, certificate or key rotation, outage behavior, support procedures, and customer-specific mapping work.
Decision checklist
Define identity sources, account linking, session lifetime, tenant membership, permissions, roles, scopes, assignment authority, deprovisioning, support access, service identities, audit events, and recovery before choosing implementation details.
Decision factors
- Workforce, customer, partner, and service identities
- Tenant membership and role scope
- Session and token lifecycle
- SSO protocol and account linking
- Audit and access-review needs
- Emergency and support access
Common mistakes
- Calling OAuth authentication
- Using interface visibility as authorization
- Assigning tenant access globally
- Creating a unique role for every user
- Ignoring deprovisioning and stale sessions
Cost considerations
Identity cost follows the number of identity sources, roles, scopes, customer-specific SSO connections, lifecycle automation, audit requirements, administrative tools, and security review—not merely the sign-in screen.
View planning rangesTimeline considerations
Basic authentication can be bounded early. Enterprise SSO, migration, account linking, complex policy, access review, and customer acceptance introduce external dependencies and testing stages.
Apply the framework to a real system decision.
If the workflow, constraints, or integration boundaries are unclear, a focused scope review can identify what needs technical validation before a build or purchase decision.