query over certification test for access tokens being revoked when authorization codes are reused

[Joseph Heenan]

The FAPI certification tests contains a test that tries to reuse an authorization code (which must be rejected) and then checks if the originally issued access token is revoked or not, and raises a warning if it is not revoked.

This comes from https://tools.ietf.org/html/rfc6749#section-4.1.2 :

If an authorization code is used more than
once, the authorization server MUST deny the request and SHOULD
revoke (when possible) all tokens previously issued based on
that authorization code. 

It’s only a warning so doesn’t prevent certification, but this check generates a number of questions and worries. Significant numbers of implementations don’t revoke the access token, in particular (but not limited to) the ones using JWT-style access tokens.

I think it’s worth question whether this check has any real value - given the use of sender constrained tokens, secure client authentication, no public clients, etc, I’m not sure there’s any security issue here and hence we might as well drop this check and give people some happiness, but it would be useful to get opinions from the working group’s security experts.

[Ralph Bragg]

For opaque or resource servers that enforce introspection could you not perhaps change the test.

• An alternative way of interpreting this is to create and exchange the access i.e issue the token. Don’t present it to an RS.
• Then reuse the code, which would revoke the underlying grant in the OP.
• Then try and use the access token from the first attempt, on introspection (at the very least) the gateway on introspection should fail the token validation.

That way you’re not testing RS’s caching strategy but making sure that the token was actually no longer valid from the OP/AS’s point of view. For JWT tokens where no introspection is occurring then this could be made informational? (if there is such a category) instead of a warning.

‌

[Joseph Heenan]

Discussed on today’s call. It seems to still be a useful security feature. We could maybe add extra text to the test saying that for short-lived jwt access tokens it’s a common tradeoff to not revoke.

The tests don’t currently test if refresh tokens (if issued) are revoked and perhaps should (again with a warning).

[Daniel Fett]

Many of the attacks on OAuth/OIDC that we have seen, both in theory and practice, enable an attacker to acquire a code which can then be redeemed for an access token. For example:

• IDP Mix-Up Attack
• Attacks on the redirect_uri
• Attacks on mobile devices (malicious apps getting access to app2app communication)
• Credential Leakage via Referer headers and browser history
• Leakage through log files

Confidential clients are not safe from these attacks, as code injection can enable an attacker to make use of a stolen code. PKCE brings some level of protection, but, just as all security mechanisms, it can be implemented wrong (e.g., static challenge/verifier) and it can be circumvented under certain conditions (PKCE Chosen Challenge attack).

Therefore, despite all the security mechanims we have in FAPI, (attempted) code reuse can still be a problem. Notwithstanding its problems in practice (in particular for JWT tokens), retracting the access token is more secure than not doing it. I therefore think that the warning has its value.

‌

[Dave Tonge]

Leaving open until relevant ticket opened with conformance test suite

[Joseph Heenan]

Ticket opened to add link to this ticket to the relevant conformance suite text: https://gitlab.com/openid/conformance-suite/-/issues/884

[Dave Tonge]

@Joseph Heenan the linked issue in the conformance suite tracker is still open, can we close this here?

[Joseph Heenan]

yeah, let's close it here and track it in the conformance suite tracker. I'm trying to get some of the backlog of conformance suite tickets solved but it's a never ending battle.