OIDC acr downgrade

[elarlang]

Should we have a requirement, that a malicious user can not downgrade acr=high to acr=low?

issue was raised by @silviavali

[elarlang]

ping @randomstuff @TobiasAhnoff

[randomstuff]

Yes, indeed, if the RP requests a given set of ACR (acr_values=…), it should make sure that a suitable acr was indeed used to authenticate the user (acr claim). This might be redundant with similar requirements. A similar concern is enforcing max_age (using auth_time claim).

See RFC9470, Step Up Authentication.

Would this fit into some existing requirement? (I'll check that later on).

[elarlang]

My initial reason to open the issue was id token validation
https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics

So, it must be checked from id-token and from access token. I don't think it is something to hide into a general requirement.

[randomstuff]

@elarlang, shall we include something about max_age/auth_time as well? In the same requirement? In a separate requirement?

[elarlang]

shall we include something about max_age/auth_time as well? In the same requirement? In a separate requirement?

I think we need to cover them both, and in case we don't want to use different levels from those, they can be in one requirement.

From: https://datatracker.ietf.org/doc/html/rfc9470#section-2-3.2

2. The resource server determines that the circumstances in which
   the presented access token was obtained offer insufficient
   authentication strength and/or recentness; hence, it denies the
   request and returns a challenge describing (using a combination
   of acr_values and max_age) what authentication requirements must
   be met for the resource server to authorize a request.

Attempt to convert it into a requirement:

Verify that the resource server validates that the presented access token was obtained with the required authentication strength and recentness by checking acr_values and max_age.

[randomstuff]

For "recentness", I think "freshness" is the word usually used?

max_age is part of the authorization request and 403 response. The resource server must not check mage_age but choose a max_age (if required) and then check auth_time. I would say something:

Verify that, if the resource server requires specific authentication strength and/and recentness using the acr_values and max_age parameters, it verifies that the presented access token satisfies these constraints (for example using the acr and auth_time claims respectively).

Also, this wording does not support OIDC (ID tokens). Shall we include a related requirement for OIDC?

[TobiasAhnoff]

To me, 51.3.3 should cover this for the resource server, perhaps add acr and max_age to the list of claims?

Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', 'authorization_details' or 'acr' are present, they should be part of the decision.

And add a requirement for the OIDC RP?

Verify that, if specific authentication strength or recentness are required using the acr_values and max_age parameters, the OIDC RP verifies that the presented ID Token satisfies these constraints (for example using the acr and auth_time claims respectively).

[elarlang]

I can see the logic behind using V51.3.3, but I also think it makes sense to keep "delegated authorization" and "confidence on the authentication" separately. Levels are not decided for those yet, but it may also be situation, that current V51.3.3 is L1 and acr/max_age is L2 requirement.

[TobiasAhnoff]

@elarlang good point, then maybe have something like this for the resource server?

Verify that, if specific user authentication strength or recentness are required , the resource server enforces authorization decisions based on claims from the access token that originates from the user authentication event. For example, if present, using OIDC claims such as 'acr' or 'auth_time'.

[elarlang]

I don't think the requirement should talk or mention "authorization decisions" anyhow. It's validating the confidence in authentication. I think we should develop a proposal from @randomstuff (#2543 (comment)).

The question here is, should we ask in the requirement, that the application send the user to re-authenticate the user to have the expected authentication level or just disallowing id-tokens and access tokens with an expected authentication level is enough?

[randomstuff]

The question here is, should we ask in the requirement, that the application send the user to re-authenticate the user to have the expected authentication level or just disallowing id-tokens and access tokens with an expected authentication level is enough?

I think the idea that we want to convey if that if the application requires a certain ACR (in general or for some specific operations), it must not just include it in the authorization request but must also check it in the access token / ID token / etc.

The application SHOULD try to reauthenticate the user (OIDC) or include a 403 with the requested ACR when the ACR is not enough but I don't think we must have this as a requirement. From a security point of view, rejecting the token is enough.

[elarlang]

The question here is, should we ask in the requirement, that the application send the user to re-authenticate the user to have the expected authentication level or just disallowing id-tokens and access tokens with an expected authentication level is enough?

I clarify this to:

The question here is, after the RS detected that the expected authentication level is not enough - should we ask in the requirement, that the application send the user to re-authenticate the user to have the expected authentication level or just disallowing id-tokens and access tokens with an expected authentication level is enough?

---

From #2543 (comment)

Verify that, if the resource server requires specific authentication strength and/and recentness using the acr_values and max_age parameters, it verifies that the presented access token satisfies these constraints (for example using the acr and auth_time claims respectively).

Updated proposal:

Verify that, if the resource server requires specific authentication strength (using the 'acr_values' parameter) or recentness (using the 'max_age' parameter), it verifies that the presented access token satisfies these constraints (for example using the 'acr' and 'auth_time' claims respectively).