Architect identity authentication

A requirement that reads "only authorized staff may reach the payment console" names no factor, no protocol, and no identity provider, and yet every one of those still has to be chosen and defended. This page takes the proofed, provisioned account as given, since establishing and verifying identity, assigning identifiers, and joiner, mover, and leaver provisioning are the work of the identity lifecycle page before it. What is left is the access-time question, and the work here is to turn a requirement like the one above into four decisions you can defend in a design review.

The first decision is the authentication approach: how much assurance the design needs, which factor categories deliver it, and the authenticator and session rules that keep the answer true after the first day. The second is the authentication protocols that carry the authentication event between two parties, such as Kerberos, Remote Authentication Dial-In User Service (RADIUS), Security Assertion Markup Language (SAML), and Open Authorization (OAuth); the objective groups OAuth here, although OAuth delegates access to a resource rather than establishing that a user is present, which its own section takes up. The third is the control protocols that supply identity data and express access policy around the event, namely Lightweight Directory Access Protocol (LDAP) and eXtensible Access Control Markup Language (XACML). The fourth is the trust relationships that decide whose word about an authentication event you are willing to accept. Those four names, in that order, structure the rest of this page, and the published exam outline^[1] uses the same four groupings for this objective.

Three role names carry the discussion. The claimant is the party currently presenting evidence, the subscriber is the account holder that evidence is supposed to belong to, and the verifier is the system checking it; NIST SP 800-63B^[2] uses those terms throughout, and so does this page. Where a federation is involved, the party that performs the authentication is the identity provider (IdP) and the party consuming the result is the relying party (RP).

The figure below groups the four decisions and, in the band beneath them, the adjacent questions that belong to sibling pages rather than this one. Keep that band in view: the single most common design failure in this objective is answering an authorization question with an authentication control, or a proofing question with a stronger authenticator.

Choose the assurance target from the harm of the account being taken over, then choose authenticators that reach it. The authenticator assurance level (AAL) states how much confidence an authentication event provides that the claimant controls an authenticator bound to the subscriber account, and NIST SP 800-63B^[2] defines three of them. AAL1 permits a single factor and provides some confidence; AAL2 requires proof of possession and control of two distinct factors and provides high confidence; AAL3 requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance, and provides very high confidence.

The order in which those two choices happen is what separates a defensible design from a procurement accident. Working forward, transaction and system risk fix the AAL, and the AAL then narrows the eligible authenticator types. Working backward from whatever the organization already owns produces an approach that cannot state why it is sufficient. Fraud indicators and contextual checks can add controls on top, but at AAL1 a single factor is the ceiling of what a single-factor process delivers, and no volume of contextual signal converts it into AAL2.

AAL is not the only scale, and the three do not move together

Three assurance scales appear in digital identity work and each answers a different question. The identity assurance level (IAL) grades how strongly the real person was proofed at enrollment and is selected on the identity lifecycle page. The AAL grades the authentication event and is selected here. The federation assurance level (FAL) grades how strongly an assertion about that event is presented to a relying party, and it is selected as part of the trust relationship decision later on this page. NIST SP 800-63^[3] treats the three as separately selectable components of a digital identity risk assessment, which is why IAL2 proofing does not imply AAL2 authentication and an AAL3 authenticator does not imply anything about proofing rigor.

The figure below shows the three scales side by side with the page that owns each one. Reading them as one scale is the mistake worth naming out loud, because it produces both of the familiar failures: heavy proofing evidence guarding an account that a single reused password opens, and hardware authenticators issued to accounts nobody ever proofed.

Multifactor authentication (MFA) means evidence from distinct categories, not two checks in a row. The categories are conventionally described as something you know, something you have, and something you are, and an MFA process draws on more than one of them. A password paired with a security question is two knowledge secrets, so it is single-factor authentication with extra steps, and two applications on the same handset can both be possession evidence for the same device. Microsoft's description of how MFA works^[4] uses the same three-category test, and the OWASP multifactor authentication guidance^[5] makes the same point from the attacker's side: an attacker who solves one category once should not get the second for free.

That category test is why the composition rules at AAL2 read the way they do. NIST SP 800-63B^[2] permits either a multifactor authenticator, which requires two factors to execute a single authentication event, or a combination of two single-factor authenticators, in which case the combination must include one physical authenticator together with either a password or a biometric comparison. The requirement is structural rather than a matter of counting prompts.

A biometric activates an authenticator; it is not one

A biometric characteristic is not recognized as an authenticator by itself. In the NIST model a physical authenticator is authenticated along with the biometric comparison: the device serves as something you have and the match serves as something you are. Local comparison on the device, where the biometric activates a multifactor authenticator, is preferred over sending a sample to a central verifier for comparison, because a sample that travels can be replayed or substituted, and a face image in particular is not a secret. This is the reason a remotely submitted selfie cannot stand alone as the authenticator for an account, however convincing the liveness tooling around it may be.

Two practical consequences follow for a design review. First, an inventory of authenticators is not evidence of MFA until the categories are named next to them. Second, where a biometric appears in the design, the question to ask is what physical authenticator it is activating, because if the answer is "none", the design has one factor and a comfortable user experience.

Phishing resistance is a property of the authentication protocol, not a property of a short validity window. NIST SP 800-63B^[2] defines it as the ability of the protocol to prevent disclosure of authentication secrets and valid authenticator outputs, the values an authenticator produces, to an impostor verifier, an attacker fraudulently posing as the verifier, without relying on the vigilance of the claimant. The last clause is the load-bearing one: a control that works only when the user notices the wrong domain name is not phishing resistance. Earlier revisions of the same guidance called this property verifier impersonation resistance, and the two names refer to the same requirement.

Two mechanisms are recognized. Channel binding establishes an authenticated protected channel with the verifier, a connection whose far end is cryptographically identified, and then binds a channel identifier from that channel irreversibly into the authenticator output, for example by signing both values with a private key the claimant controls. Verifier name binding instead ties the output to the verifier's name, so an authenticator will not produce a usable output for a different name. Channel binding is considered the stronger of the two because it survives misissuance or misappropriation of a verifier certificate, and both satisfy the requirement.

Manually entered outputs stay phishable

Any authenticator whose output the claimant types in is excluded, including out-of-band and one-time password (OTP) authenticators, because manual entry does not bind the output to the session being authenticated. An impostor verifier can simply relay the value onward and authenticate. A thirty-second lifetime narrows the window and does nothing about the relay inside it, so "short-lived" and "phishing-resistant" are not synonyms. Time-based OTP still resists simple replay of an old value, which is a real property worth having, and it is a different property from the one this section is about.

The assurance levels then differ in how hard they press. At AAL2 the verifier must offer at least one phishing-resistant option, which is an availability requirement on the verifier rather than a mandate on every subscriber. At AAL3 phishing resistance is required, the cryptographic authenticator must hold a non-exportable private key in a hardware-protected isolated environment, and public-key cryptography must protect authentication secrets from compromise of the verifier. Syncable authenticators, which copy authentication keys to other devices through a synchronization service, require the private key to be exportable and are therefore excluded from AAL3 while remaining perfectly usable at AAL2. The settling question is therefore whether the requirement demands phishing resistance, because only cryptographic binding supplies it.

Authentication intent asks whether the claimant deliberately took part in this particular authentication. NIST SP 800-63B^[2] defines an authentication process as demonstrating intent when it requires the claimant to respond explicitly to each authentication or reauthentication request, and the goal is to make it harder for an authenticator to be used without the subscriber's knowledge, for instance by malware already running on the endpoint. The authenticator itself has to establish intent; a policy statement that users should be attentive does not.

Several mechanisms qualify. Entering an authenticator output is an explicit response. A cryptographic authenticator that requires a claimant action for every operation qualifies, whether that action is pressing a button or reinserting the device. A multifactor authenticator may establish intent by reentry of its activation factor, the evidence that unlocks the authenticator itself. What these share is a per-event action that endpoint software cannot supply on the user's behalf.

Passive capture is the case worth calling out, because it looks like strong authentication and is not. Presentation of a biometric characteristic does not always establish intent: a front-facing camera can reasonably be expected to capture a face while the device is being used for something else entirely, so in that arrangement an explicit mechanism such as tapping a button has to be added. The same reasoning applies to a plugged-in cryptographic authenticator that will answer any request from the host without a fresh touch, since malware on that host can trigger it silently.

Intent is not required uniformly, and knowing where it binds is the architect's part. Authentication at AAL2 should demonstrate intent from at least one authenticator, while at AAL3 every authentication and reauthentication process must demonstrate it. That difference is why an AAL3 design cannot rely on an always-resident authenticator that answers without interaction, and why reauthentication prompts at AAL3 are a design feature rather than an irritation to be engineered away.

Risk-based elevation lets an ordinary session begin at a modest assurance level and demand more evidence when the situation warrants it, and the demand it makes is called step-up authentication. The rule that makes it work is ordering: the elevation happens before the higher-risk action, not after it. A session may be established with one factor for reading a dashboard and then require step-up authentication when the same user asks to change payment details, and the step-up has to deliver assurance sufficient for that operation.

A session never carries more assurance than the authentication event that created it. That is why elevation is an authentication event of its own rather than a flag, and why the elevated state should not outlive its justification. If a payment change needs AAL2 evidence, the design demands AAL2 evidence at that moment and then lets the session fall back to its base level, rather than leaving the whole session permanently elevated because one sensitive action occurred in it. Conditional access session controls in a commercial identity platform work this way as well, tying reauthentication demands to the resource and the risk rather than to the login alone, as Microsoft's session-control documentation^[6] describes for one such implementation among others.

Signals trigger the demand; they are not factors

Device posture, network location, impossible travel, and fraud indicators are inputs to the decision to demand more evidence. They are not authentication factors and they do not raise the AAL by themselves, because none of them is a secret the subscriber controls or an authenticator bound to the account. A design that awards a higher assurance level for arriving from a corporate network has quietly redefined the network as an authenticator.

The other half of the ordering rule is what elevation is not a substitute for. Reviewing transactions for anomalies afterwards is detection, and it is valuable, but it acts after the money moved. If the design's answer to a high-risk operation is a report the next morning, then the operation was authorized at the session's original assurance level, whatever the risk engine concluded later. The figure below traces the flow: current session assurance, comparison against what the operation needs, either proceed or step up first, and expiry of the elevated state afterwards.

Binding is the moment an authenticator becomes able to speak for an account, so it deserves the same scrutiny as the account's strongest login. NIST SP 800-63B^[2] separates binding at enrollment, where authenticators are associated with the newly created subscriber account, from post-enrollment binding, where an additional authenticator is added to an account that already exists. The second case is the one architects underweight, because adding an authenticator permanently widens who can act as the subscriber.

The requirement is that binding happens through an authenticated, protected process at an assurance appropriate to the account, followed by notification to the subscriber. An active session is not automatically that process. A session established at AAL1 is thin authority for enrolling an unrestricted new authenticator on an account whose ordinary authentication is AAL2, and treating "the user is logged in" as sufficient proof is how an attacker who captured one password turns a temporary foothold into a durable one. Notification matters for the same reason: it gives the legitimate subscriber the one signal that would expose a binding they did not perform.

Where the account holder cannot authenticate at the needed level, the guidance offers structured alternatives rather than an exception. Binding across endpoints covers the case where the new authenticator is on a different device than the session, and binding to a subscriber-provided authenticator covers a device the subscriber already owns. Each of those paths carries its own evidence requirements, and each ends in the same place: a record of which authenticators are bound to this account, at what assurance, established when.

Two design habits follow. First, treat the binding inventory as part of the account's security state, since an account authenticating at AAL3 with a forgotten AAL1 authenticator still bound to it authenticates at AAL1 whenever an attacker prefers. Second, make notification and the ability to review bound authenticators a product requirement, not an operational nicety, because the subscriber is the only party positioned to notice a binding that should not exist.

Account recovery is authentication under a different name, and it is where otherwise strong designs are usually defeated. When a subscriber loses their authenticator, the recovery path ends with someone holding working credentials for the account, so the evidence it demands, the notifications it sends, the delays it imposes, and the fraud controls around it all have to match the risk of the account rather than the convenience of the help desk. Strong daily authentication is worth exactly as much as the weakest path that can replace it.

NIST SP 800-63B^[2] treats recovery as a set of named methods with requirements attached: saved recovery codes generated in advance, issued recovery codes sent to an address of record, recovery contacts who vouch through their own authenticated session, and repeated identity proofing when nothing else remains. It also sets requirements by assurance level, so recovery at AAL2 and recovery at AAL3 are not free-form, and it requires the subscriber to be notified when recovery occurs. Notification is the control that turns a silent takeover into a reported incident.

Knowledge-based reset questions are the classic failure

Personal history questions, such as a first school or a mother's maiden name, fail on two counts: the answers are often researchable or already breached, and they are reusable across every service that asks the same short list. The OWASP guidance on forgotten-password flows^[7] recommends against relying on them and describes side-channel delivery to an address of record plus rate limiting and consistent responses instead. A design that authenticates administrators with hardware keys and resets them with three trivia questions has an effective assurance level set by the trivia.

The architectural takeaway is to draw the recovery path on the same diagram as the login path and compare their strengths deliberately. Where recovery cannot be made proportionate, the honest options are to add delay and out-of-band notification so an illegitimate recovery is visible and reversible, or to route high-impact accounts to repeated identity proofing rather than to a self-service flow. What is not an option is leaving the strongest and weakest path undocumented in the same design.

When an authenticator is lost, stolen, damaged, or suspected of compromise, the design's job is to invalidate its binding promptly and establish a replacement through an approved process. NIST SP 800-63B^[2] puts that duty on the credential service provider (CSP), the party that manages authenticators and subscriber accounts, and pairs it with the subscriber's duty to report. Invalidation can take several forms depending on the authenticator: revoking a public-key infrastructure (PKI) based authenticator, or removing the authenticator from the subscriber account.

The word to hold onto is binding. Compromise response acts on the association between an authenticator and the account, not on cosmetic properties of the account. Renaming an account, disabling a display name, or resetting the directory password leaves an independently issued certificate or hardware token exactly as valid as it was that morning, because none of those actions touched the binding that certificate relies on. This is the most frequently mishandled case in incident work, and it is worth rehearsing in a design review with the question: for each authenticator type in this design, what specific action removes it, and who can perform that action at three in the morning?

Related events share the same machinery and are worth distinguishing so a design does not conflate them. Expiration ends an authenticator's usable life on a schedule. Invalidation ends it on an event, including the case where rate limiting has disabled an authenticator after excessive failed attempts, in which case it must be rebound before it can be used again. Renewal replaces an authenticator that is still trustworthy, before it expires, without treating it as compromised.

Two design consequences follow. First, revocation must be reachable independently of the authenticator being revoked, since a subscriber whose only authenticator was stolen cannot authenticate to report it. Second, the replacement path is the recovery path from the previous section, so its strength is part of the compromise response rather than a separate concern.

Where the design still uses passwords, the verifier's storage choice decides what a stolen database is worth. NIST SP 800-63B^[2] requires verifiers to store passwords in a form that is resistant to offline attacks: salted and hashed with a suitable password hashing scheme, which takes a password, a salt, and a cost factor and produces a hash whose purpose is to make each guess expensive for an attacker holding the file. The salt must be at least 32 bits and chosen to minimize collisions between stored hashes, and both the salt and the hash are stored per password.

The cost factor is the part that ages. It should be as high as practical without hurting verifier performance and should be raised over time as computing performance improves, which is why storing a reference to the scheme and cost factor alongside each hash matters: it is what lets a verifier migrate to stronger parameters without locking everyone out. The OWASP password storage guidance^[8] reaches the same conclusions and names current schemes and parameter choices for implementers.

Reversible encryption is the failure mode to reject

Encrypting every password under one database key is not equivalent to hashing. The distinction is that a hash has no inverse, while an encrypted store has a key that exists somewhere and can be stolen, borrowed by an insider, or backed up to a place nobody remembered. A single recoverable key over the whole store converts one compromise into every subscriber's plaintext password, and because subscribers reuse passwords, the damage reaches services this design does not own. Transport protection is unrelated to this risk: an authenticated protected channel between claimant and verifier does nothing about theft of the verifier's own data at rest.

For architecture work the checkable items are short. Passwords are salted and hashed with a named scheme, never reversibly encrypted and never stored in plaintext; the cost factor is recorded and revisable; and the design says who could obtain the verifier database and what they would hold if they did. If the answer to that last question is "the passwords", the storage decision has not been made yet.

Online guessing is defeated by limiting attempts, not by demanding more complex secrets. A verifier that accepts unlimited tries against an account invites an attacker to work through a list at leisure, and no composition rule survives enough attempts. NIST SP 800-63B^[2] requires verifiers to implement controls against online guessing and, unless a specific authenticator description says otherwise, to limit consecutive failed attempts with a single authenticator on one subscriber account to no more than 100, disabling that authenticator at the limit. That figure is an upper bound rather than a target, and organizations may set lower limits; where more than one authenticator is involved in an excessive number of attempts, both are disabled, and a disabled authenticator has to be rebound before it can be used again.

Rate limiting has to be designed against two failure modes at once, which is why the naive control is the wrong one. Irreversible account lockout stops guessing and hands the attacker a denial-of-service tool: a script that submits a few wrong passwords per account can lock out a workforce without ever guessing anything. Guidance therefore pairs the attempt limit with techniques that reduce the chance an attacker locks out the legitimate claimant, including bot detection challenges before an attempt is accepted and progressive delays between attempts, among other measures. The OWASP authentication guidance^[9] similarly recommends login throttling, including account lockout.

What the control protects, and what it does not

Attempt limiting is about the online channel, where every guess passes through the verifier and can be counted. It does nothing about offline guessing against a stolen verifier database, which is the previous section's job. Presenting the two as interchangeable is a common design error: throttling with a plaintext password store is still one theft away from total loss, and strong hashing with unlimited online attempts is still guessable at leisure.

The design questions are therefore concrete. What is the consecutive-failure limit per authenticator, what happens when it is reached, how does a legitimate subscriber get back in, and what stops that recovery path from becoming the cheaper attack? A design that answers the first and skips the rest has moved the problem into the recovery flow rather than solving it. Related control expectations appear in NIST SP 800-53^[10] as the unsuccessful-logon-attempt control, which is useful when a compliance baseline has to be cited alongside the design.

An authenticated session is a convenience built on one past event, and its rules decide how long that event keeps paying. Two properties matter. First, the session inherits the assurance of the authentication event that created it and never exceeds it, so a session begun with one factor remains an AAL1 session however long it lasts. Second, continuity is maintained by a session secret established at authentication and protected in transit and at rest, which is what the verifier actually checks on each subsequent request; NIST SP 800-63B^[2] treats browser cookies and access tokens as two forms of that secret, and the OWASP session management guidance^[11] covers the implementation properties in more depth.

Two timeouts bound the session, and they answer different questions. An overall timeout limits the total duration of a session following authentication or the last reauthentication. An inactivity timeout terminates a session with no subscriber activity for a set period. Both drive either reauthentication or termination, and successful reauthentication resets the timeouts that applied. The published values illustrate how the levels differ: SP 800-63B sets a reauthentication overall timeout that should be no more than 30 days at AAL1, no more than 24 hours with an inactivity timeout of no more than 1 hour at AAL2, and no more than 12 hours with an inactivity timeout of no more than 15 minutes at AAL3, where reauthentication requirements match initial authentication. Those are the values in that guidance for the systems it governs, not universal constants; an architecture sets its own from risk and cites its basis.

Ending a session has to end the binding

Logout or expiry invalidates the session binding, which means the session secret stops being accepted rather than merely disappearing from the browser. A design that clears a cookie on the client while leaving the server-side session valid has produced the appearance of logout, and any copy of that secret still works. The same reasoning applies to the AAL2 convenience where, after an inactivity timeout but before the overall timeout, the verifier may allow reauthentication with a single factor in conjunction with the still-valid session secret: that only holds because the session secret is itself evidence, so it must be genuinely protected for the concession to be sound.

The figure below traces the lifecycle: the authentication event fixes the session's assurance, the protected session secret carries continuity, activity resets the inactivity timeout, the two timeouts force reauthentication or termination, and logout or expiry invalidates the binding. The decision behind all of it is how long one authentication event should keep paying, and an honest design writes that down as two timeout values with a reason attached.

You have settled an assurance target for a workforce that signs in to a domain-joined workstation, connects over a virtual private network, and reaches a dozen external applications in a browser. No single protocol serves all three, and the decision becomes straightforward once you ask which two parties each authentication event has to connect. That question, rather than any ranking of the protocols by strength, is what selects among them.

The four protocols named in this objective sit inside decision 2 of the page model, so the table below zooms into that one decision rather than adding a new axis to the page. It is deliberately organized by party pair, the same criterion the sections after it use.

Protocol	Parties it connects	What it establishes	Where it fits
Kerberos	Client and service inside a realm, through a key distribution center	Mutual authentication using tickets, without the user's password reaching each service	Service and host access inside a managed realm
RADIUS	Network access server and a central authentication server	Centralized authentication and authorization for access requests, with accounting as a companion function	Network, wireless, and remote access infrastructure
SAML	Identity provider and relying party, through the subscriber's browser	A signed assertion that an authentication event happened, plus attributes	Browser-based federation to enterprise applications
OAuth	Client and protected resource, authorized by a resource owner or by the client itself	Delegated authorization to call a resource, carried by an access token	Application access to data on someone's behalf

Read the last column as a fit statement, not an exclusivity claim: these are the deployments each protocol was designed around, and real environments layer them, for example using Kerberos on the internal network while federating browser access with SAML. What the table does rule out is using one where its party pair does not exist. Proposing Kerberos as the native authentication protocol for a dial-in or network access server misreads the pair, because the network access server needs to consult a central authority about a request it is relaying, which is the pair RADIUS was built for.

The remaining sections take the four in the order of the table, then turn to the control protocols that support them and to the trust relationships that decide whose assertions you accept in the first place.

Kerberos is a trusted-third-party protocol: instead of proving itself separately to every service, a client proves itself once to a key distribution center (KDC) and then collects tickets for the services it wants. The KDC runs two logical services, an authentication service that issues a ticket-granting ticket and a ticket-granting service that exchanges that ticket for service tickets, and it shares a long-term key with every principal registered in its realm, a principal being any client, service, or host identity it knows. Microsoft's Kerberos overview^[12] describes this exchange for one widely deployed implementation among others.

The property that matters architecturally is that the user's password never travels to the individual services. Each service validates the ticket it receives using its own key, which is why compromise of one application server does not hand an attacker reusable user credentials, and why a design that replaces Kerberos with password replay to each service loses a protection it may not have noticed it had. The figure below traces the five steps and, beneath them, the dependencies the design inherits: protected principal keys, sufficiently synchronized clocks between participants, and an available KDC, since new tickets cannot be issued without one.

Cross-realm paths

Access beyond one realm rests on inter-realm keys established between realms, and a ticket obtained across realms records the realms it passed through. Two consequences follow for the architecture. First, a service should accept only the transited paths that policy permits, because accepting any path means trusting every realm along it to have authenticated the user honestly; Microsoft's account of forest trust^[13] shows how one product family exposes those relationships and their direction. Second, the trust boundary is the whole path rather than the pair at its ends, so compromise of any realm's KDC compromises authentication for the principals registered in it and for the relying services that accept its word.

The takeaway for a design review is that Kerberos moves the trust problem rather than removing it. It concentrates authentication into a service you must keep available, protect at the key level, and keep time-synchronized, and it converts every cross-realm decision into an explicit policy statement about which paths are acceptable.

Remote Authentication Dial-In User Service (RADIUS) exists because the device a user connects to is rarely the right place to keep credentials or policy. A network access server, such as a wireless controller, switch, or virtual private network concentrator, receives a connection attempt and relays it as an access request to a central authentication server, which answers with an accept, a reject, or a challenge, and returns authorization attributes alongside an accept. Those attributes are what turn one yes into a specific level of access, for example the network segment a session lands in. A commercial implementation of that server role is documented in Microsoft's network policy server material^[14], and it is one implementation among several.

Centralization is the design win. Credentials, policy, and logging live in one place rather than being replicated onto every access device, which is why RADIUS is the native choice here and why proposing a ticket-based protocol built for client-to-service authentication inside a realm misses what the access device actually needs. Accounting is a companion function of the same protocol family, carrying start, stop, and interim records for a session, which is where the record of who was connected and for how long comes from; the accounting data itself is the subject of the identity accounting page in this domain.

Know what the base protocol does not protect

RADIUS by itself does not provide end-to-end confidentiality for every attribute in its messages, and its historical shared-secret mechanism is not equivalent to a modern authenticated protected channel. Carrying the exchange inside such a channel is what a protected RADIUS transport means, and that protection does not itself require an inner authentication method, the method that runs inside the exchange to authenticate the user; which method to use remains a separate site-local choice. In wireless and wired designs that use the 802.1X port-based network access control model, one documented arrangement pairs the Extensible Authentication Protocol (EAP) with a RADIUS back end: the network access server forwards EAP packets in EAP-Message attributes, while the EAP method supplies the authentication mechanism.

For architecture work, three questions settle the RADIUS part of a design: which network access servers act as the RADIUS clients, what protects the exchange between those devices and the authentication server, and which authorization attributes the accept response is expected to carry. A design that answers only the first has centralized the credential store and left the transport unstated.

SAML suits the case where a browser sits between two organizations and neither wants to hold the other's credentials. The identity provider authenticates the subscriber and issues a signed assertion stating that the authentication happened, together with attributes about the subject, and the relying party consumes that assertion and creates its own session. SAML's own vocabulary calls the consuming party a service provider; this page keeps saying relying party, since that is the name used across the rest of the federation material here. Microsoft's SAML protocol documentation^[15] walks the message exchange for one implementation among others.

An assertion is a bearer token in the ordinary case, which means whoever presents it gets its benefit. That single sentence generates the entire validation duty: expected issuer, signature, audience and recipient, validity window, and replay detection, each of which the later section on validating an assertion takes in turn. Trusting an assertion because it is well-formed XML, or because it carries a valid signature from someone, is the failure the OWASP SAML security guidance^[16] spends most of its length on.

The figure below traces a relying-party-initiated exchange: the relying party redirects the browser to the identity provider, the identity provider authenticates the subscriber and returns a signed assertion through the browser, and the relying party validates it before creating a session. Note where the messages travel. Because the browser carries them, the design has to assume a party that can see and attempt to modify what passes through, which is what makes the validation gates and the protections against assertion injection, where an attacker inserts an assertion of their own into a federation transaction someone else started, load-bearing rather than optional hardening.

For the architect, SAML is a choice about where the authentication event happens, not a security level in itself. It removes duplicate credential stores across applications and concentrates the authentication decision in the identity provider, which is a benefit and a dependency at the same time, and the strength of the resulting design comes from the trust terms and validation rules covered in the sections that follow.

OAuth answers a different question from the other three protocols: how can an application be allowed to use a resource on someone's behalf without being handed that person's credentials. A client obtains an access token from an authorization server and presents it to a protected resource, and the token represents a bounded permission rather than a person's presence. Microsoft's protocol overview^[17] draws the same line, describing OAuth 2.0 as the authorization protocol and OpenID Connect as the identity layer built on top of it; the vendor documentation cited in this section describes one implementation of these standard flows among several.

That distinction is worth stating plainly because the misreading is so common: possession of an access token proves that some client was authorized to call some resource, not that a particular human is at the keyboard right now. A design that accepts a bare authorization response as proof of user identity has an authentication gap dressed as a login. Where the application genuinely needs to know who the user is, an identity layer such as OpenID Connect supplies a token intended for that purpose, with its own validation rules.

The grant follows the authorizing actor

Grant selection is not a matter of taste, and the figure below shows the split. When a resource owner has to approve delegated access to their own resources, use an authorization-code pattern: the authorization server mediates that approval and the client never sees the owner's credentials, as the authorization-code flow documentation^[18] describes. When the acting party is a confidential client operating on its own resources or under prearranged authority, with no user present to consult, use client credentials, where the client's own authentication is the grant, as the client-credentials flow documentation^[19] describes. A confidential client here means one that can keep a secret, which a server-side service can and a public single-page application cannot.

Two design errors follow from getting this backwards. Using client credentials where a resource owner should have approved removes the owner from a decision about their own data, and the access is then bounded only by whatever the client was granted globally. Using a user-approval flow for a background job creates a dependency on some individual's continued consent and account status for a system function, which is how a batch process quietly stops working the week someone leaves.

Suppose a design review asks which protocol will make the access decision for a set of services, and someone answers "LDAP, because that is where the accounts are". The accounts are indeed there, and the answer is still wrong, because the objective separates the protocols that carry an authentication event from the control protocols that supply identity data and express access policy around it. Naming the second group correctly is the whole content of this decision.

LDAP defines operations for accessing and modifying entries in a distributed directory: bind, search, compare, add, modify, and delete, among others. A directory reached this way is an excellent source of the attributes an access decision needs, and an LDAP bind operation does verify a supplied password against a directory entry, which is exactly why the confusion persists. What LDAP does not supply is the authentication architecture: no assurance level, no phishing resistance, no ticketing or assertion model, no multifactor composition. It is a directory access protocol whose bind happens to check a password, and treating it as the answer to "how will people authenticate" leaves every question from the first half of this page unanswered. The OWASP guidance on LDAP injection^[20] is a useful reminder that the directory query itself is an attack surface once user input reaches it.

XACML is the other half of this pair and is a policy language, not a directory or an authentication protocol. It expresses attribute-based access control rules and defines a request and response model in which a decision point evaluates a request against policy and returns a decision, which NIST SP 800-162^[21] describes in its treatment of attribute-based access control. XACML is therefore the natural answer to "how will centralized authorization policy be expressed", and never to "how will this user authenticate".

Both belong in an access control architecture and neither is interchangeable with the protocols in the previous sections. The practical test for a design document is to point at each protocol and name what it produces: a ticket, an assertion, an access token, a directory entry, or a policy decision. If nothing in the list produces the first three, the design has data and policy but no authentication event.

The last of the four decisions starts with a straight either-or: does this system authenticate its own subscribers, or does it accept another party's word that they authenticated? Federation moves the authentication event to an identity provider and hands the relying party an assertion about it. That removes duplicate credential stores, gives subscribers one authentication experience, and takes password handling out of every application, which is a real reduction in attack surface.

It also creates a dependency, and naming both sides of the trade is the point of making this decision explicitly. The relying party depends on the identity provider's authentication and assertion handling, while the relying party determines the minimum IAL, AAL, and FAL it will accept before granting access. The reasoning that "federation must reduce risk because it reduces the number of password stores" counts one side of the ledger only.

When a stand-alone store is the right answer

A stand-alone identity store remains justified where isolation or autonomy outweighs the operational gain. Typical cases include a system that must keep authenticating during an outage of the corporate identity service, an environment deliberately separated from the enterprise network, and a service under a regulatory or contractual regime that will not accept an external party in its authentication path. The cost is real and should be written down: a separate credential lifecycle to provision and de-provision, its own recovery and revocation paths, and its own monitoring, all of which the identity lifecycle page covers as work that does not disappear because a system is small.

Federation also does not have to be all or nothing. A common arrangement federates ordinary application access while keeping a small number of break-glass administrative accounts local, precisely so the recovery path for an identity-provider outage does not run through the identity provider. Whichever way the decision goes, record it with the reason, and the section that follows sets out the terms that make a federated relationship trustworthy once it exists.

Protocol interoperability is not trust. Two parties that both implement the same federation protocol can exchange messages, and that says nothing about whether either should believe the other. NIST SP 800-63C^[22] makes the trust agreement an explicit artifact: the parties establish, in advance for the higher levels, who may assert what, at which assurance levels, using which keys and identifiers.

A workable agreement covers at least the following items, among others, and each one has a failure mode when it is left out. The assurance levels the identity provider will assert and the relying party requires, so neither side discovers at runtime that AAL1 sessions are being accepted for high-impact functions. The attributes the identity provider will release and the relying party may rely on. The keys and identifiers each party uses, along with how they are established, rotated, and revoked, since at the highest level identifiers are configured manually and each is uniquely associated with the verification keys for the party it represents. Incident handling duties, so a compromise at one party reaches the other in time to matter. And lifecycle duties, so that an account de-provisioned at the identity provider does not keep working at the relying party.

Approved providers, not any provider

The technical counterpart of the agreement is that a relying party accepts assertions only from identity providers it has approved, and an identity provider releases attributes only to relying parties it has approved. The guidance describes both directions, including allowlists, blocklists, and runtime decisions, on each side. This is what stops the failure of accepting a correctly signed assertion from a provider that happens to speak the protocol, which is a live risk in any environment where adding a federation partner is a self-service configuration change.

Assurance-level requests are part of these terms rather than a runtime afterthought. A relying party specifies a minimum acceptable set of levels in the agreement and may request a stricter set at runtime, and the identity provider indicates the resulting level in the assertion whether or not the request was met. That last detail is the one to design around: an identity provider that cannot meet a requested AAL still returns an assertion saying what it did achieve, so a relying party that never reads the returned level has effectively no assurance requirement at all.

An assertion is evidence, and evidence gets checked before it is acted on. A relying party validates every assertion it receives, and the checks are ordered so that cheap and decisive ones come first: the assertion is from the expected issuer, its signature verifies with that issuer's verification key, the audience and recipient identify this relying party, its validity window has not passed, and it has not been presented before. The figure below traces those gates and the single rule that governs all of them, which is that any failure ends in rejection rather than in a session.

Two of the gates are worth dwelling on because a signature check invites the reader to think the work is done. A signature proves integrity and proves the issuer produced the assertion; it says nothing about whether this relying party is the intended consumer. Audience and recipient restrictions are what supply that, which is why NIST SP 800-63C^[22] requires the assertion to be audience-restricted and the relying party to confirm it is among the targeted parties, and why the requirement tightens to a single relying party per assertion at FAL2. Without it, an assertion legitimately issued for one service can be presented to another and accepted on the strength of a signature that was never a statement about the second service at all.

Bounded lifetime and replay

Because a bearer assertion benefits whoever holds it, its window of usefulness has to be short and its reuse has to be detected. The guidance requires each relying party in the audience to enforce replay protection so that the same assertion is not accepted twice by that party, and an assertion with several audiences may be accepted once by each. Transport encryption is not a substitute here: it protects the assertion in flight and does nothing after a copy has been obtained at either end, which is the scenario replay defense exists for.

The stronger arrangements change the nature of the evidence rather than shortening its life further. A holder-of-key assertion identifies an authenticator the subscriber must demonstrate control of, and a bound authenticator does the same job by prior arrangement at the relying party, so a stolen assertion alone stops being sufficient. Both are what FAL3 adds, as the next section sets out, and both are the honest answer when the risk analysis says a bearer token is too much to lose.

Federation carries attributes as well as authentication results, and the decision about which attributes travel is a security and privacy decision rather than an integration convenience. The identity provider and relying party agree on the minimum set of attributes needed for the transaction and the purposes they serve, and that agreement is part of the trust terms rather than a property of the directory schema.

Releasing the full directory record because it is easier than filtering has three costs and no authentication benefit. It widens the privacy exposure at every relying party, since attributes the application never needed now sit in its logs and databases. It raises the impact of a breach at any of those parties, because the copy they hold is richer than their function required. And it grows the blast radius of the federation itself, converting one integration into a distribution channel for the whole employee record. None of that buys a stronger authentication event, because assurance comes from the authenticators and the assertion protections, not from the number of fields in the payload.

There are quieter design points in the same area. NIST SP 800-63C^[22] advises against putting plaintext personal information such as usernames, email addresses, or employee numbers in federated identifiers, and makes that a requirement at FAL2, so the identifier that links the two systems should be an opaque value rather than a readable one. Where a relying party genuinely needs more than the agreed set, the guidance also describes collecting additional attributes at the relying party and synchronizing attributes over time, both of which are explicit mechanisms with their own rules, which is preferable to widening the assertion until it covers every future need.

For design work the useful habit is to write the attribute list next to the function each attribute serves and delete the rows where that column is empty. A relying party that cannot name what it does with an attribute does not need it released, and a federation whose attribute list has never been revisited since the integration went live is carrying exposure it stopped paying for long ago.

When a federated identifier arrives for the first time, the relying party has to decide which local account it belongs to, and getting that wrong hands one person another person's access. Resolution comes before linking: the relying party uses enough of the asserted attributes to identify the subscriber uniquely, and if the available attributes cannot do that, the correct outcome is to stop rather than to guess at the closest match.

The attribute usually reached for is the one least suited to the job. Email addresses and usernames are mutable, are reassigned when people leave, and are sometimes shared across shells of the same organization, so matching on them alone can associate a new federated identifier with an account that belongs to someone else. That is why federated identifiers should be opaque values, as the previous section noted, and why the local account record should store the identifier it was linked to rather than re-deriving the match from a display attribute on every visit.

Linking another identifier needs an authenticated session

Adding a second federated identifier to an existing local account is the same class of event as binding an additional authenticator, and it gets the same treatment: it happens inside a session already authenticated through an existing identifier, not on the strength of a matching attribute in an incoming assertion. NIST SP 800-63C^[22] describes the provisioning models for relying-party subscriber accounts and the account-linking expectations that go with them, including notification and the ability to unlink. Without that rule, anyone who can arrange for an assertion carrying a chosen email address can attach themselves to whichever account already uses it.

Two operational details complete the picture. De-provisioning has to reach the link, since an account that survives at the relying party after the identity provider removed the subscriber is exactly the orphan the identity lifecycle page's joiner, mover, and leaver work exists to prevent, and shared signaling between the parties is the mechanism that carries such changes. And the link record is worth treating as security-relevant state in its own right, because a quiet change to which federated identifier a privileged local account trusts is an access grant that no entitlement review would show.

The federation assurance level (FAL) grades how strongly an assertion is presented and validated, and it is selected separately from the AAL, as the assurance-level section set out for all three scales. That separation is what the third scale buys: a subscriber can authenticate to an identity provider with a hardware-protected authenticator and still have the resulting assertion delivered in a way that an attacker can inject, and the reverse is equally possible. NIST SP 800-63C^[22] defines the three levels as cumulative requirement sets, and the figure below shows the deltas between them.

FAL1 provides basic protection and allows a wide range of deployments. The assertion is signed with approved cryptography, the relying party validates the signature against the expected issuer's verification key, the assertion is audience-restricted and replay-protected, and bearer assertions are permitted. Trust may be pre-established or established by the subscriber during the transaction, and injection protection and relying-party initiation are recommended rather than required.

FAL2 keeps the bearer model and closes the flexibility. The transaction must be initiated by the relying party, the assertion must be strongly protected against injection attacks, the audience must be a single relying party, and the trust agreement must be pre-established. Federated identifiers must not contain plaintext personal information. In short, FAL2 is FAL1 with the optional protections made mandatory and the ad-hoc trust path removed.

FAL3 changes the evidence rather than tightening the same evidence further. The relying party must verify that the subscriber controls an authenticator in addition to validating the assertion, either one named in a holder-of-key assertion or one bound at the relying party beforehand, and party identifiers are established manually with each uniquely associated with its verification keys. The consequence is the reason FAL3 exists: because the subscriber demonstrates something at the relying party directly, a compromised identity provider that forges an assertion still does not gain access. Selecting FAL is therefore a question about what you are unwilling to lose if the identity provider or the assertion channel misbehaves, and it is answered independently of how the subscriber authenticated.

For questions on this objective, first identify which of the four decisions in the outline the situation is asking about. Reading the stem, the situation the question describes, with that question in mind saves most of the work, because the wrong answers are typically correct statements about a different decision.

A stem that describes the consequences of an account being taken over is an approach question, and the answer names an assurance target and a factor composition rather than a product. Watch for two traps in this family. Options that pair two knowledge secrets, such as a password and a security question, do not meet the requirement for two distinct authentication factors however many prompts they involve. Options that offer a time-limited one-time password as the phishing-resistant choice are relying on the reader treating a short window as cryptographic binding; the phishing-resistant answer binds the authenticator output to the legitimate verifier, and where the stem also demands the highest assurance, it additionally implies a non-exportable key in hardware, which excludes authenticators that sync keys between devices.

A stem that names the two parties, such as a network access server consulting a central server, or a browser reaching an external application, is a protocol question. Match the pair rather than ranking the protocols: a central authority answering relayed access requests is RADIUS, a client collecting tickets for services in a realm is Kerberos, a browser carrying a signed statement between organizations is SAML, and an application acting on a user's behalf against an interface is OAuth. Keep two protocol distinctions clear here. One option offers LDAP because the accounts are in a directory, or as the language for centralized policy, when LDAP accesses directory entries and XACML expresses policy decisions. The other treats an OAuth access token as proof of who the user is, when it evidences authorization to call a resource and needs an identity layer to answer the identity question.

A stem about accepting another organization's word is a trust question, and the strongest-looking wrong answer (the distractor) is usually a correctly signed assertion. Signature validation proves integrity and issuer; audience and recipient restrictions, a bounded validity window, and replay detection are what make an assertion acceptable to this particular relying party, an approved-provider list and a written agreement are what make the relationship trustworthy at all, and verification that the subscriber controls a bound or holder-of-key authenticator is what survives a compromised identity provider. Finally, watch for stems that quietly test scale independence: proofing rigor, authentication strength, and assertion presentation are selected separately, so an option that raises one because the stem raised another is testing exactly that confusion. The four groupings used throughout this page are the ones in the published exam outline^[1], which makes them a reliable way to sort the options before comparing them.