Quarkus ommits default HTTP port when validating URI in DPoP

[mocenas]

Describe the bug

Problem with quarkus.oidc.token.authorization-scheme=dpop. Quarkus ommits default HTTP port 80 from request's URI, when validating DPoP proof.

When I:

• Create DPoP proof for http://mysite:80/dpop
• Make http request for URI http://mysite:80/dpop (and I checked network traffic, HTTP request actually contains the port number in URI)
• Quarkus will decline the request stating that DPoP proof URI http://mysite:80/dpop does not match request URI http://mysite/dpop

Quarkus drops the default port somewhere during the processing. Explicitly declaring port 80 is not the most common thing, but can easily happen in automation.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @pedroigor (bearer-token,oidc)

[sberyozkin]

Indeed, I'm not sure though we can reach some consistency re the port 80. I'm assuming, in prod, if it is a public website like https://myservice.com, SPAs won't be adding :80 when creating proofs, https://myservice.com:80.
And I doubt Quarkus OIDC should start trying to add :80 in case of the mismatch.

I'm kind of keen to close this issue as won't fix, but indeed, let's get the discussion going for now

[sberyozkin]

@mocenas FYI, it is not Quarkus OIDC which deals with constructing the request URL - whatever RoutingContext reports is used. We can probably determine that the default post is used, but trying to adapt the request URL to match the proof URL can be messy.
All in all, I'm not worried about this issue, let's keep it open, but for now please update the test to avoid setting :80 on the proof itself - it is unlikely that SPA which does it can interoperate with various DPoP aware services.

[sberyozkin]

@mocenas I've assigned to myself, I won't be fixing it right now but will think about it. Thanks for the quality QE

[mocenas]

I'm also unsure how to deal with this, and I'm OK if this is not addressed. At least for now, it's definitely not an urgent problem.

[sberyozkin]

@mocenas https://datatracker.ietf.org/doc/html/rfc9449#section-4.3 says

To reduce the likelihood of false negatives, servers SHOULD employ syntax-based normalization ([Section 6.2.2](https://rfc-editor.org/rfc/rfc3986#section-6.2.2) of [[RFC3986](https://datatracker.ietf.org/doc/html/rfc3986)]) and scheme-based normalization ([Section 6.2.3](https://rfc-editor.org/rfc/rfc3986#section-6.2.3) of [[RFC3986](https://datatracker.ietf.org/doc/html/rfc3986)]) before comparing the htu claim.

and in this case it is https://www.rfc-editor.org/rfc/rfc3986#section-6.2.3, which covers :80 case.

But note it is SHOULD, in practice it means SPAs can't rely upon it to be supported.
But, I think, we can do a basic fallback attempt with :80, so I can have a look a bit later

[geoand]

Is there anything else that needs to be done for this?

[mocenas]

For current snapshot the issue still stands. But as discussed above, it is not needed for this to be fixed.