Identity and access management · reference sheet

IAM Concepts Across Okta, Entra and AWS

This study guide features:

  • Logical vocabulary: a working vocabulary for drawing identity into logical architecture diagrams
  • Patterns: identity, authentication, authorization and related cryptography patterns that recur in most systems
  • In practice: how three common ecosystems implement the same ideas
AuthenticationWho are you?Prove an identity with credentials and factors.
AuthorizationWhat may you do?Decide which actions on which resources are allowed.
EnforcementWhere is it checked?The point in the system that blocks or allows the request.
AccountabilityWhat happened?Evidence of who did what, when, and under which authority.
01

Conceptual Vocabulary for Logical Diagrams

Consider using some of these vendor-neutral labels on components and arrows.

02

Standards that carry across ecosystems

Open specifications every major identity platform implements. Learn these once and they apply wherever you work.

OAuth 2.0Authorization framework

Lets a client obtain a scoped, time-limited access token to call an API on a user's or its own behalf, without handling the user's password. It grants access; on its own it does not say who the user is.

AnswersWhat may this client do?Seen inAPI access, partner integrations, consent screens
OIDCOpenID Connect

An identity layer built on OAuth 2.0. Adds an ID token that tells the application who signed in, how and when.

AnswersWho is this user?Seen inModern web and mobile sign-in, "Sign in with" buttons
SAML 2.0Security Assertion Markup Language

An XML-based federation standard. The IdP sends a signed assertion through the user's browser to the service provider, which then grants a session.

AnswersWho is this user?Seen inEnterprise single sign-on into SaaS applications
SCIM 2.0System for Cross-domain Identity Management

A REST API standard for creating, updating and deactivating user accounts and groups across systems, so applications stay in step with the source of truth.

AnswersShould this account exist, and with what attributes?Seen inJoiner, mover, leaver and rejoiner provisioning
FIDO2WebAuthn + CTAP

Public-key authentication where the private key stays on the user's device and only works for the site it was registered to, which makes it resistant to phishing. Passkeys are FIDO credentials that can sync across a person's devices.

AnswersIs this really the user?Seen inPasswordless sign-in, phishing-resistant MFA, security keys
JWTJSON Web Token: compact, signed token format used for ID tokens and many access tokens.
PKCEProof Key for Code Exchange: protects the OAuth sign-in code from interception; required for browser and mobile apps.
mTLSMutual TLS: both sides present certificates, giving strong client authentication for APIs.
LDAP and KerberosOlder directory and sign-in protocols behind Active Directory; still common on premises.
03

Cryptographic building blocks

Identity systems rest on a small set of cryptographic tools. Each card says what the tool does and where it appears in IAM.

Hashing

A one-way fingerprint of data. The same input always gives the same output, and the input cannot be recovered from it.

In IAMPasswords are stored as salted, deliberately slow hashes (bcrypt, scrypt, Argon2) so a stolen database does not reveal them.

Symmetric encryption

One shared key both encrypts and decrypts. Fast and suited to large volumes of data (AES is the common standard).

In IAMProtects stored data and the bulk traffic inside a TLS connection. The hard part is sharing and protecting the key.

Public-key cryptography

A key pair: the public key can be shared with anyone, the private key never leaves its owner. What one key does, only the other can undo (RSA, elliptic curve).

In IAMUnderpins signatures, certificates, TLS key exchange and FIDO2 passkeys.

Digital signature

The private key signs; anyone with the public key can verify. Proves who created the data and that it was not altered. It does not hide the contents.

In IAMSAML assertions and JWTs are signed by the IdP. The relying party must verify the signature before trusting any claim.

MAC and HMAC

An integrity check using a shared secret key. Proves the sender knew the key and the message was not changed.

In IAMAWS request signing (SigV4) uses HMAC. Some tokens and webhooks are protected the same way.

Certificates and PKI

A certificate binds a public key to a name and is signed by a certificate authority. Trust flows down a chain from a root; certificates expire and can be revoked.

In IAMTLS server identity, mTLS client authentication, SAML signing certificates, smart cards and device trust.

TLS and mTLS

TLS encrypts a connection and proves the server's identity with its certificate. Mutual TLS also requires a client certificate.

In IAMEvery token and credential travels inside TLS. mTLS gives APIs strong machine-to-machine authentication.

Key management

Generating, storing, rotating and retiring keys. Key management services and hardware security modules (HSMs) keep keys from ever leaving protected hardware.

In IAMIdPs rotate token signing keys and publish the public halves at a JWKS endpoint so apps can verify tokens.

Envelope encryption

Data is encrypted with a data key, and the data key is encrypted with a master key held in a KMS or HSM.

In IAMAccess to the master key becomes an authorization decision: whoever can call decrypt can read the data.
Encoding is not encryptionBase64 makes data portable; anyone can decode it. A JWT's body is only encoded.
Hashing is not encryptionEncryption is reversible with the key; hashing is designed to be irreversible.
Signed is not secretA signed token proves origin and integrity; its contents remain readable.
Keys are the assetEncryption is only as strong as control over who can use the key.
04

Reference diagram

A minimal product showing where identity components sit and how credentials travel.

trust boundary · your product User principal · browser Partner API client Identity provider IdP · authorization server Web app relying party · PEP API gateway PEP · rate limits API service resource server · PEP Policy engine PDP Data store Audit log append-only sign in OIDC redirect · tokens access token client credentials allow? workload role events
Solid boxComponent you build or operate
Grey boxExternal party or service you trust
Dashed boundaryTrust changes when crossed
Labeled arrowName the credential or token it carries

Every arrow that crosses a boundary should name what proves identity on that hop.

05

Recurring identity patterns

Most systems combine a handful of these. Each step names the components from the vocabulary above.

06

Patterns in 3 Major Ecosystems

Okta and Microsoft Entra are identity providers first. AWS IAM is an authorization engine for cloud resources first, and usually receives people from an external IdP.

Shared standards underneathAll three speak OAuth 2.0, OIDC, SAML 2.0, SCIM and FIDO2. Product names differ; protocols carry over.
Shared building blocksEach has a tenant boundary, a directory, groups, policies, MFA, short-lived credentials, machine identities and an audit log.
Different defaultsPolicy evaluation, what "role" means and where sign-in rules live differ most. Check those first when moving between platforms.
Concept
Okta
Microsoft Entra / Azure
AWS
Key difference
07

Takeaways that outlast any product

Product names reflect vendor documentation as of fall 2026. Feature availability often depends on license tier.