Authentication context and methods

Naming the strength of a sign-in

acr stands for authentication context class reference. Its value names a class of authentication: a set of rules that the sign-in satisfied, defined by whoever runs the identity provider. Lantern defines two classes and publishes what they mean to the teams that build its applications:

Each value is a case-sensitive string. The specification recommends an absolute URI, like these, or a name from a public registry of assurance profiles. The string itself means nothing to OpenID Connect. Its meaning comes entirely from Lantern's definition, which is why the portal's developers read that definition rather than the name. A value containing a reassuring word such as "strong" says only what its publisher decided it says.

A class names an outcome, not a procedure. Lantern's identity provider decides which methods satisfy urn:lantern:acr:phishing-resistant. If Lantern later supports a new kind of security key, the portal does not change: it asks for the same class and receives the same value.

The two values are not points on a scale, either. The portal cannot compare them as larger or smaller. It keeps its own list of the values it accepts for each action. Ordinary pages accept either value, and the raw shoot download accepts only the phishing-resistant one. That list follows Lantern's definitions, which say that a phishing-resistant sign-in also meets the MFA rules.

Requesting a context

Lantern's identity provider lists the classes it supports in its discovery document. This excerpt shows the fields that matter here:

{
  "issuer": "https://idp.lantern.example",
  "authorization_endpoint": "https://idp.lantern.example/authorize",
  "acr_values_supported": [
    "urn:lantern:acr:mfa",
    "urn:lantern:acr:phishing-resistant"
  ],
  "claims_parameter_supported": true
}

acr_values_supported names the classes, not their meanings. Those still come from Lantern's documentation.

The simplest way to ask for a class is the acr_values parameter, which the Step-up authentication challenges lessons in Advanced OAuth used when an API asked for more. It is a space-separated list in order of preference, added to the authentication request:

&acr_values=urn%3Alantern%3Aacr%3Aphishing-resistant

This asks Lantern's identity provider to use that class, and to report the class it achieved in the acr claim. It is a request for a voluntary claim. If the provider cannot satisfy it, for example because the designer has no security key, it may still complete the sign-in and report the class the session does have, such as urn:lantern:acr:mfa, or leave the claim out. The specification's minimum for a provider is only that using the parameter does not cause an error. A response to acr_values therefore always needs checking.

The stricter form uses the claims parameter from Scopes and the claims parameter, marking acr as essential for the ID token and listing the acceptable values:

{
  "id_token": {
    "acr": {
      "essential": true,
      "values": ["urn:lantern:acr:phishing-resistant"]
    }
  }
}

Sent URL-encoded as the claims parameter, this asks for more than a preference. A provider that supports the claims parameter, as Lantern's says it does, must return an acr that matches one of the listed values, and it may ask the designer for additional factors to get there. If it cannot meet the requirement, it must treat the attempt as a failed authentication instead of returning a weaker sign-in. Requesting stronger authentication follows what the portal receives in that case.

Use one form or the other, not both. The specification leaves the outcome undefined when a request carries acr_values together with an acr claim request that lists specific values.

A registration can supply a default as well. Lantern registered the portal with default_acr_values set to ["urn:lantern:acr:mfa"], so every ordinary sign-in asks for the MFA class without the portal adding a parameter. A request in either form overrides the default, and like acr_values, the default asks for a voluntary claim.

Whichever form the request took, the portal compares the acr in the validated ID token with its list for the action. A missing acr meets no requirement. Lantern's policy says every sign-in uses MFA, but a token without the claim is not evidence that this sign-in did, so the portal treats it like a sign-in that fell short.

Reading amr

At 08:30 UTC on 2 October, designer-42 signed in with a password and an authenticator app code. The portal's ID token from that sign-in reads:

{
  "iss": "https://idp.lantern.example",
  "sub": "designer-42",
  "aud": "lantern-portal",
  "iat": 1790929805,
  "exp": 1790930105,
  "auth_time": 1790929800,
  "nonce": "demo-portal-nonce-1",
  "acr": "urn:lantern:acr:mfa",
  "amr": ["pwd", "otp", "mfa"]
}

amr, the authentication methods references, lists the methods used in the sign-in. RFC 8176 registers common values so that providers can use the same names:

Here pwd and otp name the two methods, and mfa says they counted as more than one factor. The portal stores the list with the session and shows it in the designer's sign-in history as "password and authenticator app", which also helps Lantern's support staff when a designer asks why a download was refused.

What the portal does not do is build access decisions on this list. Method lists are harder to rely on than they look. Providers describe the same sign-in differently: one may report a passkey as hwk, another as swk, and some use names of their own that are not in the registry. None of the registered values says whether a method resisted phishing, because that depends on how the method was used, which is what Lantern's class definition captures. RFC 8176 itself describes method lists as more brittle than context classes, since the methods suited to a task change as attacks and technology change.

A missing claim proves nothing either. Authentication policy and SSO warned that an absent method claim is not proof of MFA, and it is no proof of a single factor: the provider may simply not report methods. The list also reveals how a person signs in, so the portal keeps it with the session and the sign-in history rather than copying it into ordinary logs.

At 10:15, designer-42 selects Download raw files on a client's project. The session's class is urn:lantern:acr:mfa, and the download accepts only the phishing-resistant one. Requesting stronger authentication follows what happens next.