Enterprise Identity & Security

5 articles · ~4 hours · Security engineers, architects

This path is designed for engineers responsible for securing distributed enterprise systems. It builds a complete mental model of identity and access management — starting from the HTTP foundation that all security protocols run on, through delegated authorization, enterprise-grade federated identity, and applied cryptography. Each step is a prerequisite for the next.

Prerequisites

Before starting this path, you should be comfortable with:

Basic HTTP: request/response, headers, and status codes
The general concept of authentication (who are you?) vs. authorization (what can you do?)
Working with APIs or distributed services in a professional context

You do not need prior knowledge of OAuth specifications, AWS services, or cryptographic algorithms. Those are covered in the articles themselves.

The Path

Step 1: REST & HTTP Fundamentals

Article: REST & HTTP Foundations

Why this matters for enterprise security Every security protocol in this path — OAuth, SAML, OIDC, TLS — runs over HTTP. If you don't have a precise understanding of HTTP semantics, the security specifications built on top of it will feel arbitrary. This article ensures you can read an HTTP exchange and understand exactly what is happening: which headers carry credentials, how redirects work in OAuth flows, and why statelessness matters for token-based authentication.

Key concepts for security-focused readers

HTTP headers relevant to security: Authorization, WWW-Authenticate, Set-Cookie, Strict-Transport-Security
The mechanics of the redirect — critical for understanding OAuth authorization code flows
Statelessness and why it makes bearer token authentication the natural fit for REST APIs
HTTPS vs. HTTP: what TLS adds to the transport layer

What to learn next With a solid HTTP foundation, you're ready to understand how OAuth uses HTTP redirects and bearer tokens to implement delegated authorization without sharing credentials.

Step 2: OAuth 2.0 & Delegated Authorization

Article: OAuth 2.0

Why this matters for enterprise security OAuth 2.0 is the authorization framework underlying most enterprise API security today. It also forms the foundation of OpenID Connect (OIDC), which extends OAuth for authentication. Understanding OAuth at the specification level — not just how to configure a library — allows you to evaluate whether an implementation is secure, audit access token handling, and design appropriate scopes and consent flows for sensitive APIs.

Key concepts for security-focused readers

The distinction between authorization (OAuth 2.0) and authentication (OIDC built on OAuth 2.0)
Authorization Code flow with PKCE: why PKCE is mandatory for public clients
Token endpoint security: client authentication methods and their relative strength
Scope design: principle of least privilege applied to API access delegation
Refresh token rotation and binding to prevent token exfiltration
Common OAuth attack vectors: authorization code interception, open redirectors, token leakage via referrer

What to learn next OAuth secures individual API interactions. Step 3 addresses how enterprises manage identity at scale — centralized identity, federated SSO, and fine-grained access policies across many accounts.

Step 3: AWS SSO & Enterprise Identity

Article: AWS SSO & Enterprise Identity

Why this matters for enterprise security Most enterprises run workloads across multiple AWS accounts, often hundreds. Managing IAM users per account is operationally untenable and a security liability. AWS IAM Identity Center (formerly AWS SSO) provides centralized identity, federated login from corporate directories (Active Directory, Okta, Azure AD), and attribute-based access control across every account in an AWS Organization. This article covers the architecture that makes large-scale cloud access governance practical.

Key concepts for security-focused readers

SAML 2.0 federation: how your corporate identity provider (IdP) integrates with AWS
Just-in-time provisioning vs. pre-provisioned users: trade-offs for large organizations
Permission sets: how IAM policies are packaged and assigned at scale
Attribute-based access control (ABAC) with IAM Identity Center tags
Separation of duties: using AWS Organizations SCPs alongside Identity Center permission sets
Audit trail: CloudTrail integration and what events to monitor for identity abuse

What to learn next You now understand how identities are established and federated. The final step covers the cryptographic mechanisms that protect those identities and the data they authorize access to.

Step 4: Applied Cryptography

Article: Cryptography

Why this matters for enterprise security Cryptography is the mathematical foundation every identity and security protocol ultimately rests on. OAuth tokens are signed with asymmetric keys. SAML assertions are signed and optionally encrypted. TLS uses a combination of asymmetric key exchange and symmetric encryption. Understanding what these operations actually do — and what assumptions they rely on — is essential for evaluating the security of a system, choosing the right algorithms, and avoiding common implementation mistakes.

Key concepts for security-focused readers

Asymmetric cryptography: RSA and EC key pairs, public key distribution, and trust anchors
Digital signatures: how JWT signing (RS256, ES256) provides integrity and non-repudiation
TLS certificate chains: CA trust, certificate pinning, and mTLS for service-to-service authentication
Key management in the enterprise: AWS KMS, hardware security modules (HSMs), and key rotation policies
Common cryptographic failures: weak algorithms, improper IV reuse, missing certificate validation
Envelope encryption for secrets management at scale

Step 5: Transport Layer Security (TLS)

Article: Transport Layer Security (TLS)

Why this matters for enterprise security Every protocol covered in this path — OAuth 2.0 redirects, SAML assertions, OIDC tokens, AWS API calls — travels over TLS. Understanding TLS moves you from trusting that "HTTPS is secure" to knowing exactly what that means: which handshake happens, which cipher suite is negotiated, what the certificate chain proves, and where the guarantees break down. mTLS is also the standard mechanism for service-to-service authentication in zero-trust enterprise architectures.

Key concepts for security-focused readers

TLS 1.2 vs. TLS 1.3: handshake round trips, removed legacy algorithms, and why 1.3 is preferred
Forward secrecy: why ECDHE key exchange ensures past sessions survive a private key compromise
Certificate chain of trust: Root CA → Intermediate CA → Leaf, and what each link proves
Mutual TLS (mTLS): bidirectional certificate authentication for service-to-service security
Certificate pinning: binding a known certificate to a host to prevent rogue-CA attacks
Cipher suite selection: what TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 actually means

After This Path

Having completed this sequence, you will be able to:

Read and evaluate the security of an OAuth 2.0 implementation at the specification level
Design federated identity architectures for multi-account cloud environments
Assess the cryptographic controls protecting tokens, API traffic, and stored secrets
Identify common attack vectors in enterprise identity systems and the controls that mitigate them
Configure and evaluate TLS deployments, cipher suites, and certificate management strategies
Conduct or contribute to a security review of an API or cloud access management design

If you work primarily on backend APIs and want to deepen your understanding of scalability alongside security, the Building Scalable APIs path covers overlapping ground from an engineering design perspective.

← Writing Quality Code · All Learning Paths