Identity & Access Management

An open authorisation framework that allows a third-party application to obtain limited access to a resource on behalf of a user — without the user sharing their credentials. The user grants the app a scoped access token through an authorisation server.

"We use OAuth 2.0 so users can log in with their Google account without sharing their Google password with us. The authorisation server issues a short-lived access token scoped to read:email, which our API validates on every request."

The most secure OAuth 2.0 grant type for server-side web apps and SPAs. The authorisation server returns a short-lived code to the redirect URI; the backend exchanges it for tokens. Prevents tokens from appearing in the browser URL.

"The SPA uses Authorization Code Flow with PKCE — the code verifier and challenge prevent code interception attacks. When the user approves, we receive a code in the redirect, exchange it server-side for an access token and refresh token, and store the refresh token in an httpOnly cookie."

An extension to the Authorization Code Flow that prevents code interception attacks in public clients (SPAs, mobile apps). The client generates a code verifier and sends a hash (code challenge) with the request; the verifier is sent with the token exchange.

"Mobile apps must use PKCE because they can’t securely store a client secret. The app generates a random code verifier, hashes it as the code challenge, and includes it in the authorisation request. When exchanging the code, it sends the original verifier — the server verifies the hash matches."

An identity layer built on top of OAuth 2.0 that adds authentication. Returns an ID token (a JWT containing user identity claims) in addition to the OAuth access token. Enables SSO and federated identity.

"We use OIDC for user login. The ID token contains the user’s sub (unique identifier), email, and name claims. We validate the token signature against the IdP’s JWKS endpoint and extract the claims to create the user session. The access token is for our API; the ID token is for the user’s identity."

A compact, URL-safe token format containing a header (algorithm), payload (claims), and signature — base64url-encoded and dot-separated. Used as access tokens and ID tokens. Claims include sub (subject), iss (issuer), exp (expiry), iat (issued-at).

"The JWT expires in 15 minutes — we check the exp claim before trusting it. The signature is verified against the IdP’s public key from the JWKS endpoint. Never trust a JWT without verifying the signature and checking iss, aud, and exp — an unsigned none-algorithm JWT is a known attack vector."

An XML-based standard for exchanging authentication and authorisation data between an identity provider (IdP) and a service provider (SP). Widely used for enterprise SSO. The IdP issues a signed XML assertion that the SP validates.

"Enterprise customers require SAML SSO — their IT team configures their Okta instance as the IdP and registers our service as an SP. When a user logs in, Okta issues a signed SAML assertion containing their email and role attributes. Our SP validates the assertion signature against Okta’s certificate."

An access control model where permissions are assigned to roles, and users are assigned to roles. A user’s permissions are determined by their roles, not directly. Easier to manage at scale than per-user permissions.

"We use RBAC with three roles: viewer (read-only), editor (read + write), and admin (full access including user management). A new team member is assigned the editor role — they get the exact permissions needed without custom configuration. Role changes take effect immediately across all services."

An access control model that grants access based on attributes of the user, resource, and environment. More flexible than RBAC — policies can express rules like “allow if user.department == resource.owner_department and environment.time is business_hours.”

"RBAC couldn’t express our policy: ‘engineers can only access customer data from their assigned region.’ We switched to ABAC — the policy engine evaluates user.region and resource.data_region at request time. More complex to implement but handles the fine-grained access rules our compliance requires."

A service that authenticates users and issues identity assertions. In OIDC/SAML it is the authoritative source of user identity — it verifies credentials and issues tokens or assertions that service providers trust.

"Okta is our IdP. When a user logs into any internal tool, the tool redirects to Okta for authentication. After successful MFA, Okta issues tokens that the tools accept — no individual tool needs to verify credentials. Changing a user’s access in Okta instantly affects all connected tools."

Access token: short-lived credential for API calls (5–60 minutes). Refresh token: long-lived credential (days/weeks) stored securely, used to obtain new access tokens without re-authentication. Separation limits the blast radius of a leaked access token.

"Our access tokens expire in 15 minutes — APIs validate them without a database lookup (JWT). The refresh token is stored in an httpOnly cookie and lasts 30 days. When the access token expires, the browser silently calls /auth/refresh — the server validates the refresh token and issues a new access token."

Strings that define the permissions an access token grants. Requested during authorisation and approved by the user or resource owner. Narrow scopes limit what a compromised token can do.

"The third-party integration requests scopes: read:profile, read:calendar. It does not request write:calendar or read:email — following the principle of least privilege. We show users exactly which scopes are requested before they approve. The issued token can only call endpoints matching the granted scopes."

Authentication requiring proof from two or more independent factors: something you know (password), something you have (TOTP, hardware key), or something you are (biometric). Prevents credential-only attacks.

"After the phishing incident we made MFA mandatory for all employees. We use TOTP (authenticator apps) as the second factor for most users and FIDO2/WebAuthn hardware keys for privileged access (production systems, admin panels). Password-only login is disabled in the IdP."