vertx-auth icon indicating copy to clipboard operation
vertx-auth copied to clipboard

OpenID Connect: Respect the configured flow types if the server sends none

Open Traderjoe95 opened this issue 4 months ago • 4 comments

Motivation:

The OpenIDConnectAuth unconditionally resets the supportedGrantTypes of OAuth2Options to null. Therefore, the previously configured grant types are ignored and replaced by the default (implicit, auth_code). This triggers a configuration validation exception if no clientId is configured. In use cases that only need OAuth token validation functionality, this behavior is undesired, as they might never need a client ID.

This is fixed by only resetting supportedGrantTypes when the authentication server sends grant_types_supported on its own.

Fixes #729

Conformance:

You should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

Traderjoe95 avatar Sep 04 '25 12:09 Traderjoe95

@Traderjoe95 can you add a test for this?

vietj avatar Sep 04 '25 15:09 vietj

@vietj sure, I'm working on it. It's been a bit of a hassle, but I'm getting to it.

There's one thing that just came to my mind, and I would like to get your opinion on this: When the user configures a set of supported flow types, and the server also sends a set, wouldn't it be better to use the intersection of both instead of overriding the previous configuration?

In this scenario, setting the supportedGrantTypes means "My application supports the following grant types". The server may specify which grant types it supports, so the resulting set of grant types agreed on by both parties would be the intersection. If it is empty, that would be an error.

If the user or server doesn't set any supported grant types, that means "I support all grant types", if both don't set anything, we fall back to the default.

What do you think? In my opinion that would allow more flexibility than just having the server override everything

Traderjoe95 avatar Sep 05 '25 10:09 Traderjoe95

I will first push my tests for the original implementation, then in a second commit, I will update to my suggestion so it can be easily reverted if you don't like it

Traderjoe95 avatar Sep 05 '25 10:09 Traderjoe95

I updated the code to the alternative solution I proposed earlier. Let me know what you think!

Traderjoe95 avatar Sep 05 '25 10:09 Traderjoe95