Authentication Methods Reference (AMR)

What AMR tells a relying party

AMR is useful because it does not just say that authentication happened, it shows which methods were used in the session. That lets a relying party interpret the strength and shape of the proof, for example whether the session came from a password, a one-time code, a biometric, or a federated sign-in.

In practice, AMR sits alongside other OpenID Connect claims that describe the authenticated session. It is not a substitute for policy, but it gives the application a machine-readable signal it can use when deciding whether to allow sensitive actions, step up assurance, or treat a session as lower confidence.

How AMR is used in session and policy decisions

AMR becomes valuable when an application needs more than a yes-or-no login result. A resource server or relying party can use the list of methods to understand whether the user arrived through a stronger path, such as phishing-resistant authentication, or a weaker one that may need additional checks before access is granted.

That makes AMR especially relevant in step-up authentication, transaction approval, and adaptive access logic. If a session was established with a method the application trusts for a given action, the user can move forward more smoothly; if not, the application can ask for stronger proof before continuing.

What AMR does not prove on its own

AMR is descriptive, not magical. It records what the identity provider says was used, but it does not by itself guarantee that every listed method was strong, that the session is still safe, or that the authentication event has not been downgraded by later compromise. It should be read as one input to a wider trust decision, not as a complete security verdict.

That distinction matters because some methods are more resistant to phishing, relay, or token theft than others. A string of method names can support policy, but the relying party still needs to combine it with its own session checks, risk signals, and authorization rules.

AMR in modern authentication architectures

AMR is most useful in architectures that already separate identity proofing, authentication strength, and application authorisation. It helps bridge the identity layer and the application layer by giving downstream systems a standard way to reason about how the user authenticated without hard-coding assumptions into every application.

In OpenID Connect deployments, AMR often works best when paired with related claims and policy enforcement at the identity provider. The result is clearer security decisions, better auditing of authentication context, and less guesswork when an application needs to distinguish a basic sign-in from a stronger session.

Risk and Threat Considerations

AMR can create false confidence if a relying party treats the claim as proof that a session is safe rather than as a reported authentication context. If the upstream authentication flow is weak, or if attackers can influence the session after sign-in, the claim may describe how authentication started without reflecting the real security of the current session.

Failure mechanism: The downstream system trusts the method list without verifying whether the method was sufficiently strong for the action, whether the session has been replayed or stolen, or whether the authentication context has changed since issuance.

Impact: Sensitive actions may be allowed on the basis of weaker proof than the organisation intended, which can increase the chance of account misuse, privilege abuse, or fraudulent transaction approval.

Practitioner Guidance

Why practitioners should care: AMR is most useful when it is tied to an explicit policy decision, not when it is merely logged and ignored. Treat it as a signal for access decisions, step-up prompts, and post-login assurance checks. For implementation context, the Authentication Guide is the best starting point for the wider authentication model.

Common misunderstanding: Many teams assume that a multi-valued AMR claim automatically means a strong session. In reality, the value depends on which methods were used, how they were combined, and whether the application actually enforces a policy based on them.

Related resources from NHI Mgmt Group

• Why is it crucial to adopt new authentication methods in MCP usage?
• Why do modern authentication methods matter for NHI governance?
• Why do fallback authentication methods create so much risk after passkey rollout?
• Why do legacy recovery methods often increase authentication risk?