spring-authorization-server icon indicating copy to clipboard operation
spring-authorization-server copied to clipboard

Being able to decide which scopes require the consent page

Open merxos opened this issue 1 year ago • 15 comments

Expected Behavior I'm able to select which scopes require the consent page. Probably in the OAuth2 client registration

Current Behavior Right now it is possible to require the consent page for every scope or never show it

Context I got a business requirement where one of the scopes that we provide should not display consent page. I was able to make a workaround which is not optimal. I have made a copy of the OAuth2AuthorizationCodeRequestAuthenticationProvider and adjusted the method requireAuthorizationConsent

merxos avatar Sep 15 '23 13:09 merxos

@merxos

I got a business requirement where one of the scopes that we provide should not display consent page.

Could you not configure a RegisteredClient that requests that scope and ensure the RegisteredClient.clientSettings.isRequireAuthorizationConsent() is set to false? This should fulfill your requirement?

If it doesn't, please provide more detailed information for your use case so I can better understand.

jgrandja avatar Sep 15 '23 21:09 jgrandja

It unfortunately won't solve my requirement, because we have multiple scopes available, and it only depends on the client which scopes they choose. So I need more like a scope level definition on whether to show the consent page or not.

merxos avatar Sep 18 '23 15:09 merxos

@merxos

If it doesn't, please provide more detailed information for your use case so I can better understand.

I still do not understand your use case. Please provide much more details on your use case scenarios otherwise I won't be able to help and this issue will get closed.

jgrandja avatar Oct 11 '23 20:10 jgrandja

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

spring-projects-issues avatar Oct 18 '23 20:10 spring-projects-issues

We would like to have the following setup: (I'm with @merxos)

  • scopeA: does not require consent
  • scopeB: requires consent

Right now it is only possible to have either:

  • scopeA: does not require consent
  • scopeB: does not require consent

or

  • scopeA: requires consent
  • scopeB: requires consent

But you cannot combine those two 🙂

PunchyRascal avatar Oct 19 '23 07:10 PunchyRascal

Overall situation of what we would like to have:

  • scopeA does not require consent page
  • scopeB requires consent page
|  Who    |  Action                          | Expected  behavior      |  Current behavior      | 
----------------------------------------------------------------------------------------------- | 
| Client1 |  requests scopeA + scopeB        | consent page is shown   |  consent page is shown | 
| Client2 |  requests scopeA                 | no consent page         |  consent page is shown | 
| Client3 |  requests scopeB                 | consent page shown      |  consent page is shown | 

Please let us know if this explains it, thanks :)

PunchyRascal avatar Oct 19 '23 08:10 PunchyRascal

@PunchyRascal

Given the 3x client flows described above, the following 3x RegisteredClient's would fulfill the 3x flows. Makes sense?

RegisteredClient client1 = RegisteredClient.withId(UUID.randomUUID().toString())
		.clientId("client-1")
		.clientSecret("{noop}secret")
		.clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
		.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
		.redirectUri("http://127.0.0.1:8080/authorized")
		.scope("scope-a")
		.scope("scope-b")
		.clientSettings(ClientSettings.builder().requireAuthorizationConsent(true).build())
		.build();

RegisteredClient client2 = RegisteredClient.withId(UUID.randomUUID().toString())
		.clientId("client-2")
		.clientSecret("{noop}secret")
		.clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
		.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
		.redirectUri("http://127.0.0.1:8080/authorized")
		.scope("scope-a")
		.clientSettings(ClientSettings.builder().requireAuthorizationConsent(false).build())
		.build();

RegisteredClient client3 = RegisteredClient.withId(UUID.randomUUID().toString())
		.clientId("client-3")
		.clientSecret("{noop}secret")
		.clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
		.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
		.redirectUri("http://127.0.0.1:8080/authorized")
		.scope("scope-b")
		.clientSettings(ClientSettings.builder().requireAuthorizationConsent(true).build())
		.build();

jgrandja avatar Oct 19 '23 14:10 jgrandja

That's pretty nice, but the problem is that the clients can later switch what scopes they want - it's up to them. The scopes are not predefined at registration time. One day they only want scopeA, the next day they also want scopeB.

This points us to the idea where consent page on/off is also bound to scope rather than just client.

PunchyRascal avatar Oct 19 '23 14:10 PunchyRascal

@PunchyRascal

but the problem is that the clients can later switch what scopes they want - it's up to them. The scopes are not predefined at registration time. One day they only want scopeA, the next day they also want scopeB

I need more details on how you implemented dynamic scope configuration for the clients? Because with the default configuration, if client2 requested scope-b the request would be rejected since it's only configured to request scope-a.

jgrandja avatar Oct 19 '23 15:10 jgrandja

To answer your question:

We have a system where we are able to dynamically change the registered scopes. By implementing a custom RegisteredClientRepository.

But I just realized that what we mean was not clear from my previous comments. The dynamic client scopes are a distraction - it is not important for this.

Here is an updated example (with just 1 client)

  • scopeA does not require consent page
  • scopeB requires consent page
|  Who    |  Action                    | Expected  behavior      |  Current behavior      | 
----------------------------------------------------------------------------------------- | 
| Client1 |  requests scopeA           | no consent page         |  consent page is shown | 
| Client1 |  requests scopeB           | consent page is shown   |  consent page is shown | 
| Client1 |  requests scopeA + scopeB  | consent page is shown   |  consent page is shown | 

Here is an (example) implementation @merxos put together: https://github.com/merxos/spring-authorization-server/pull/1

Sorry for the confusion. Thanks :)

PunchyRascal avatar Oct 20 '23 15:10 PunchyRascal

@PunchyRascal

We have a system where we are able to dynamically change the registered scopes. By implementing a custom RegisteredClientRepository.

If you're able to dynamically change the registered scopes then why can't you also update to .clientSettings(ClientSettings.builder().requireAuthorizationConsent(false).build()) for the first example shown? Where Client1 requests scopeA.

jgrandja avatar Oct 24 '23 15:10 jgrandja

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

spring-projects-issues avatar Nov 02 '23 20:11 spring-projects-issues

The RegisteredClientRepository with it's clients is built at the startup of the app. The client has both of the scopes available and it is up to him which scopes he chooses to use.

So we need to decide to show the consent page or not right in the authentication request that the client does where the RegisteredClientRepository is already built.

merxos avatar Nov 03 '23 14:11 merxos

@merxos I now understand your use case.

Client1 is configured with scopeA (consent not required) and scopeB (consent required).

Flow 1: Client1 requests scopeA and consent should not display. Flow 2: Client1 requests scopeB and consent should display.

I see now that the ClientSettings.builder().requireAuthorizationConsent(true) will not work for both flows.

We'll keep this issue open and see if there is demand from other users for this capability.

jgrandja avatar Nov 07 '23 15:11 jgrandja

@jgrandja Yes, this indeed is something we would find useful - with some scopes, clients do not need to go through the hassle of granting consent.

petrdvorak avatar Feb 20 '24 00:02 petrdvorak