General interview: How do you choose FAL1, FAL2, or FAL3 for federated identity?

Prompt and context

A relying party (RP) integrates several identity providers (IdPs) for public content, employee administration, and high-value transactions. The team treats FAL as “login strength” without defining assertion injection, holder binding, privacy, or recovery. Use NIST SP 800-63C to choose a Federation Assurance Level and explain OIDC validation and operations.

FAL describes how a federation transaction protects and binds an assertion. It does not replace IAL (identity proofing) or AAL (authenticator strength). NIST states that higher levels subsume lower requirements; FAL3 additionally requires the subscriber to present proof of a bound authenticator directly to the RP.

What the interviewer is testing

• Separation of identity proofing, user authentication, and assertion delivery.
• Correct security properties and boundaries of FAL1, FAL2, and FAL3.
• Validation of issuer, audience, signature, nonce, lifetime, and assertion source.
• Handling multiple IdPs, injection, holder binding, privacy, and recovery.
• Turning a level decision into policy, monitoring, migration, and exceptions.

Clarifying questions

1. Is the resource public content, an employee console, or a high-value transaction?
2. Is federation OIDC, SAML, or another protocol, and who issues and validates assertions?
3. Must the design resist assertion injection, token transfer, or replay after theft? Can users present a bound authenticator?
4. How do device changes, recovery, offline use, and shared devices work?
5. How are issuer, audience, JWKS, and tenant mappings maintained across IdPs?

30-second answer

Choose FAL from resource risk, not from the login screen. FAL1 covers basic assertion delivery; FAL2 adds protection against federation attacks such as assertion injection; FAL3 additionally requires a subscriber-bound authenticator proof presented directly to the RP. Track IAL, AAL, and FAL separately. Validate OIDC issuer, audience, signature, nonce, and time. Reserve FAL3 for high-value operations and plan recovery, privacy, key rotation, and rollout costs.

Deep-dive answer

1. Separate IAL, AAL, and FAL

IAL describes identity proofing, AAL describes how a user proves control of an authenticator, and FAL describes protection of an IdP assertion delivered to an RP. A user may have a strong AAL while the federation transaction has insufficient FAL; FAL2 does not prove an identity-proofing level.

For each resource, record all three levels, allowed IdPs, assertion type, recovery path, and audit retention. Do not map “uses OIDC” directly to a FAL.

2. Understand the three FAL levels

FAL1 provides basic federation assertion delivery for lower-risk services, but still requires signature, issuer, audience, lifetime, and session validation.

FAL2 adds stronger assertion-delivery protection against an attacker injecting a valid assertion into another federation transaction. The RP needs explicit transaction context, trusted IdPs, and injection checks.

FAL3 builds on FAL2 and requires a bound authenticator proof presented directly by the subscriber, making assertion transfer harder. It adds device-binding, recovery, availability, and privacy costs, so it should not be a default for every login.

3. Validate an OIDC assertion

Validate the ID Token signature, iss, aud, exp, iat, and nonce. OpenID Connect requires comparing the nonce to the value sent in the authentication request; the path component of an issuer URL is part of its identity.

Fetch JWKS only from an approved issuer and refresh in a controlled manner when a kid is missing. Do not build discovery URLs from user input or treat an email claim as a cross-tenant identity key.

4. Resist assertion injection and transfer

Persist the authorization request, issuer, client ID, redirect URI, state, and nonce server-side. The callback must match the original transaction; unknown issuer, wrong audience, repeated state, or wrong nonce stops the flow.

High-risk resources also bind transaction, resource, and session. FAL2 addresses the core federation assertion-injection problem but does not replace PKCE, issuer identification, token audience, or resource authorization.

5. Design a FAL3 bound authenticator

FAL3 requires the subscriber to present proof of a bound authenticator directly to the RP. The RP registers the binding, checks proof freshness and device status, and handles loss, replacement, revocation, and recovery.

Recovery cannot rely only on an ordinary IdP login, or it may bypass the binding. High-risk recovery may require independent factors, manual review, or delayed activation; product and support teams must accept higher cost and failure rates.

6. Operate with privacy and multiple IdPs

Request only business-necessary claims and limit assertion retention and log fields. Subjects from different IdPs should not be merged into one cross-domain identity without an issuer- and tenant-scoped mapping.

Monitor signature failures, issuer conflicts, nonce replay, JWKS refresh, assertion size, recovery events, and success by FAL. Use overlap during key rotation and keep old issuer configuration verifiable for in-flight session TTLs.

7. Choose, roll out, and handle exceptions

Public content usually needs no high FAL; an employee console may use FAL2; transfers, administrator keys, and irreversible actions deserve a FAL3 assessment. Exceptions record resource, deadline, compensating control, and owner.

Roll out by tenant and resource while comparing completion, recovery, support tickets, and security events. Stop rollout on assertion injection or binding failures; do not silently drop high-risk operations to FAL1 for availability.

Model answer

I would evaluate IAL, AAL, and FAL separately. Use FAL1 for low-risk content, FAL2 for employee and multi-IdP flows with stronger injection defenses, and consider FAL3 for high-value operations such as administrator keys or irreversible transfers, with bound authenticators and recovery designed up front.

Every OIDC callback validates issuer, audience, signature, time, and nonce, binding issuer, client, state, redirect URI, and transaction. JWKS comes only from approved issuers and rotates with overlap. Roll out per tenant, monitor injection, replay, recovery, and completion, and give every exception a deadline and compensating control. High-risk flows fail closed during verification outages.

Common mistakes

• Treating FAL as login strength and ignoring IAL and AAL.
• Assuming OIDC automatically means FAL2 or FAL3.
• Checking only a signature, not issuer, audience, nonce, lifetime, and transaction context.
• Letting a user-supplied issuer or kid trigger arbitrary discovery or key retrieval.
• Claiming FAL3 is one setting without bound-authenticator and recovery design.
• Merging email claims from different IdPs into one identity.
• Silently downgrading high-risk operations to FAL1 for completion rate.

Follow-up questions and answers

How is FAL2 different from AAL2?

AAL2 describes authenticator strength; FAL2 describes protection of federation assertion delivery. They are independent and should be recorded and composed separately.

When is FAL3 worth the cost?

For high-value actions where assertion transfer risk matters and users can present a bound-authenticator proof, such as administrator keys or irreversible transactions. Cost and recovery capacity must be assessed together.

Why does nonce still matter?

Nonce binds an ID Token to this authentication request and reduces replay of an old response. It does not replace issuer, audience, signature, or FAL policy.

What if an IdP's JWKS is unavailable?

Use a controlled short cache. If a high-risk assertion cannot be verified, fail closed and alert; never accept an unknown key or skip verification.

How do you handle a device replacement?

FAL3 requires a new binding and an approved recovery path. Ordinary IdP login may be one recovery factor but cannot silently inherit the old device binding.

How do you explain the FAL choice to product teams?

Explain resource risk, assertion-transfer consequences, user population, recovery cost, and compliance requirements. Record deadlines, metrics, and compensating controls instead of citing a level name alone.