FreeExam
A closed notebook, a blank card, and a pencil on a wooden desk.

Identity and authorization

50 cards

Authentication protocols, session boundaries, tenant isolation, permission models, and tests for access-control failures.

Card 1 of 50

Front. Principal. What identity should an authorization decision evaluate?

These cards are original study material. They are not questions from a named employer or a live hiring loop.

All 50 cards in this deck

  1. 1.Principal

    What identity should an authorization decision evaluate?

    The authenticated principal, acting role or delegation, tenant, requested action, and target resource. A username from a request body is not authoritative evidence of who is acting.

  2. 2.Authn Authz

    A signed-in user retrieves another tenant's invoice. Which control failed?

    Resource authorization or tenant isolation, even if authentication worked correctly. Check the principal's permission for the exact invoice and tenant on the server for every read and mutation path.

  3. 3.Deny Default

    What does deny by default mean for a new endpoint?

    An action is unavailable unless an explicit applicable policy permits it. New routes, background jobs, exports, and alternate API versions need coverage; a default in one middleware path does not protect bypass paths.

  4. 4.Rbac

    When does role-based access control become difficult to maintain?

    When combinations of tenant, resource ownership, region, and temporary duties require many nearly identical roles. Keep roles tied to stable responsibilities and use attributes or relationships where those express the policy more directly.

  5. 5.Abac

    What information can an attribute-based policy combine?

    Subject attributes, resource attributes, requested action, and trusted environmental context. Attribute provenance and freshness are critical; a caller-supplied department or tenant must not become an authorization fact without verification.

  6. 6.Rebac

    How can relationship-based access express document access?

    Permission can follow relationships such as member-of-team, team-owns-folder, and document-in-folder. Define inheritance, revocation propagation, and traversal limits so an indirect relationship grants only intended access.

  7. 7.Policy Boundary

    How do a policy decision point and an enforcement point differ?

    The decision point evaluates rules; the enforcement point applies the result at the protected operation. A correct policy is ineffective if a handler skips enforcement or evaluates the wrong resource.

  8. 8.List Filter

    Why is checking permission only after returning a list unsafe?

    Unauthorized resource names, counts, or metadata may already be exposed. Apply access-aware filtering before output, and verify pagination and aggregates follow the same visibility rules.

  9. 9.Bulk Access

    How should a bulk update authorize its items?

    Check each item's action and tenant boundary, then apply the documented atomic or partial-success policy. Permission for one item or the collection endpoint must not imply permission for every supplied ID.

  10. 10.Field Access

    Why can an authorized object response still leak data?

    The caller may be allowed to read the object but not sensitive fields such as payout details or internal notes. Use explicit response projections and field-level rules rather than serializing the whole stored object.

  11. 11.Write Fields

    How do you prevent a profile update from changing account privileges?

    Allowlist writable fields for the specific actor and operation, and reject or ignore protected fields according to the API contract. Generic object binding must not let users assign roles, tenant IDs, or ownership.

  12. 12.Tenant Context

    Why should tenant identity not come only from a URL parameter?

    The caller controls the URL. Derive or validate tenant membership from authenticated context and enforce resource ownership within it; also include tenant scope in caches, search filters, and storage keys.

  13. 13.Cache Authz

    What must an authorization cache key and expiry account for?

    Principal, action, resource, tenant, and policy-relevant context, plus permission changes. Define revocation latency and invalidation; caching an allow decision indefinitely defeats later access removal.

  14. 14.Revocation

    Why can removing a role leave access active for a while?

    Existing tokens, sessions, replicated policy stores, or cached decisions may retain old grants. Set an explicit revocation objective and use short lifetimes, invalidation, or online checks where immediate removal is required.

  15. 15.Toctou

    A user loses approval rights between validation and a transfer. How should the system respond?

    Recheck sensitive preconditions at execution or bind validation and mutation through a suitable transaction/version check. Authorization at form-render time is not enough for a later irreversible action.

  16. 16.Service Identity

    Why use a distinct workload identity for each service?

    It supports scoped permissions, attribution, and independent revocation. A shared production credential lets compromise of one workload impersonate others and makes audit records less informative.

  17. 17.Delegation

    What should a service record when acting on behalf of a user?

    Both the service identity and the originating user or delegation context, with a constrained scope and intended audience. Do not replace all downstream checks with a claim that the upstream service already authenticated someone.

  18. 18.Confused Deputy

    How can a privileged export service become a confused deputy?

    A caller supplies a resource identifier and the service uses its broad credentials without checking the caller's authority. Bind the request to the allowed tenant/resources and restrict the service's own access as well.

  19. 19.Oauth Purpose

    What problem does OAuth address, and what does it not establish alone?

    It delegates access to protected resources through access tokens. It is not by itself a user-login protocol; authentication use cases need a defined identity layer such as OpenID Connect and its validation rules.

  20. 20.Oidc Token

    Why should an API not accept an ID token as if it were an access token?

    An ID token describes authentication for its intended client, while an access token authorizes access to a resource server. Validate token type, audience, issuer, and protocol context instead of treating every signed JWT as interchangeable.

  21. 21.Code Flow

    What is the security purpose of exchanging an authorization code through the token endpoint?

    It separates front-channel authorization from token issuance and permits client authentication and code binding checks. The code must be short-lived, single-use, and tied to the correct client, redirect URI, and PKCE context where used.

  22. 22.Pkce

    What does PKCE protect in an authorization-code flow?

    The client commits to a challenge and later proves possession of its verifier, limiting use of an intercepted or injected code by another party. It does not replace redirect validation, token validation, or secure session handling.

  23. 23.State

    What should an OAuth state value be bound to?

    The initiating browser session and authorization attempt, with unpredictability and single-use validation where it provides CSRF protection. Do not accept an arbitrary echoed value without checking the stored transaction context.

  24. 24.Nonce

    What does an OpenID Connect nonce help bind?

    The ID token to the authentication request that initiated it, helping detect replay or substitution in applicable flows. Verify it against the expected request value along with signature, issuer, audience, and expiry.

  25. 25.Redirect Uri

    Why are broad redirect-URI wildcards risky?

    They can allow an authorization response to reach an attacker-controlled destination. Register and validate exact redirect URIs where required by the flow, with only protocol-defined exceptions such as appropriate native loopback ports.

  26. 26.Public Client

    Why is a secret embedded in a browser or distributed mobile app not a confidential client credential?

    Anyone able to inspect the app can recover it. Use the protocol protections designed for public clients rather than relying on a shared embedded secret to authenticate each installation.

  27. 27.Access Scope

    Why are scopes not a substitute for object-level authorization?

    A scope such as invoices:read describes an allowed action class, not which tenant's invoices belong to the caller. The resource server must still evaluate ownership, relationships, and policy for the requested object.

  28. 28.JWT Validation

    Which checks matter beyond verifying a JWT signature?

    Validate trusted issuer, intended audience, allowed algorithm and key, time constraints, token type, and required claims under the application profile. A valid signature from the wrong issuer or for another API must not grant access.

  29. 29.Key Selection

    Why must a JWT key ID not be treated as an arbitrary file path or URL?

    It is untrusted token metadata. Resolve it only within the issuer's trusted key set and constrain key retrieval; otherwise validation can become file access, SSRF, or attacker-key acceptance.

  30. 30.Key Rotation

    How do you rotate signing keys without accepting retired keys forever?

    Publish the new trusted key, begin signing with it, retain old verification keys for the bounded validity of legitimate tokens, then remove them. Compromise may require immediate revocation and session disruption instead of a routine overlap.

  31. 31.Bearer

    What makes a bearer token sensitive even when its payload is readable?

    Possession is sufficient to use its authority unless additional binding applies. TLS, limited audience/scope, short expiry, and safe storage matter; JWT encoding is not encryption.

  32. 32.Sender Constrained

    What additional check does a sender-constrained access token require?

    The caller must prove possession of a bound key, for example through a supported mTLS or DPoP mechanism. Validate that binding correctly; it reduces replay of a stolen token but not misuse by a compromised authorized client.

  33. 33.Refresh Rotation

    How can refresh-token rotation reveal replay?

    Each successful refresh replaces the token, and reuse of an invalidated predecessor can signal theft. Track token families and define safe handling of concurrent refreshes; rotation without server-side state cannot reliably detect reuse.

  34. 34.Logout

    Why does clearing a browser cookie not necessarily revoke access?

    A stolen session or token may remain valid elsewhere. Invalidate server-side sessions or apply the token revocation strategy, while distinguishing local logout from identity-provider logout and other active devices.

  35. 35.Session Fixation

    Why rotate a session identifier after login?

    It prevents an attacker who arranged or learned a pre-login identifier from retaining the victim's authenticated session. Also rotate at relevant privilege transitions and invalidate the prior identifier.

  36. 36.Session Expiry

    How do idle and absolute session expiry differ?

    Idle expiry limits time since qualifying activity; absolute expiry limits total session age regardless of activity. Enforce both server-side according to risk, and avoid background polling silently extending a session indefinitely.

  37. 37.Step up

    What should a step-up check for changing payout details prove?

    Fresh, appropriate authentication by the authorized actor, tied to the sensitive operation. A confirmation button alone adds no identity assurance; recheck authorization and protect the final action from substitution.

  38. 38.Password Reset

    What properties should a password-reset token have?

    High entropy, narrow account/purpose binding, short expiry, single use, and protected storage and transport. Rate-limit requests and attempts, avoid account enumeration, and decide which existing sessions must be revoked.

  39. 39.Recovery

    Why can weak account recovery undermine strong MFA?

    An attacker may bypass the primary factors through helpdesk, email, or reset flows. Evaluate recovery identity proof, notifications, delays for high-risk changes, and revocation with the same account-takeover threat model.

  40. 40.Webauthn

    Why are WebAuthn credentials resistant to ordinary credential-phishing sites?

    Authentication is bound to the relying-party identity and browser-origin checks, so a lookalike origin cannot request a valid assertion for the legitimate site. Correct server verification and secure registration/recovery remain necessary.

  41. 41.Passkey Server

    What must the server verify on a WebAuthn assertion?

    The challenge, expected origin and RP ID binding, signature using the registered credential, and required user-presence/verification flags. Apply relevant credential and counter policies; do not accept a successful client UI as verification.

  42. 42.Passkey Sync

    What distinction matters between device-bound and synced passkeys?

    Device-bound credentials stay tied to an authenticator, while synced credentials can be restored through a provider's protected sync system. Evaluate recovery, device access, and assurance requirements rather than assuming all passkeys have identical custody.

  43. 43.Mfa Push

    Why can push-based MFA fail under repeated approval prompts?

    Users may approve an unexpected prompt through fatigue or confusion. Use phishing-resistant factors where appropriate, constrain repeated attempts, and provide clear transaction context and reporting rather than treating any second prompt as strong proof.

  44. 44.Service Account

    What lifecycle controls should a service account have?

    An owner, documented purpose, scoped permissions, credential or federation policy, usage monitoring, and a retirement path. Unowned permanent credentials tend to retain access long after the workload disappears.

  45. 45.Jit

    What makes just-in-time privileged access useful?

    It grants scoped privileges only for a bounded task window with identity verification and auditability. Approval, expiry enforcement, session controls, and emergency access must work; a temporary ticket without technical expiry is still standing access.

  46. 46.Break Glass

    How should emergency access remain usable without becoming an unnoticed backdoor?

    Keep narrowly controlled emergency credentials or procedures, test them, alert on use, and review every activation. Ensure they do not depend entirely on the identity system whose outage they are meant to bypass.

  47. 47.Audit Denial

    What should an access-decision log record without leaking credentials?

    Actor, tenant, resource identifier, action, policy/version, decision, reason category, and correlation ID. Protect sensitive identifiers and avoid raw access tokens or secrets; denied decisions are important for investigation too.

  48. 48.Negative Tests

    What tests expose authorization gaps beyond the happy path?

    Try same-role users accessing each other's objects, cross-tenant IDs, forbidden fields, alternate verbs/routes, stale sessions, and bulk requests with mixed permissions. Verify both denial and absence of data or side effects.

  49. 49.Policy Change

    How can a permission-policy change be rolled out safely?

    Test representative allow/deny cases, compare old and new decisions in a controlled shadow evaluation, inspect unexpected grants, and stage enforcement. Define rollback and revocation effects before changing broad roles.

  50. 50.Authorization Review

    What is a useful output of an authorization review?

    A matrix of principals, resources, actions, conditions, and expected decisions, linked to enforcement points and tests. Document unknowns and revocation behavior so the review can be repeated after schema or workflow changes.