consent: Obtain previously selected scopes

[androbi-com]

Do you want to request a feature or report a bug?
feature

What is the current behavior?
In the login-consent app, The scope(s) selected (granted) by the user are passed as GrantScope in the AcceptConsentRequest back to hydra. So hydra has them.

What is the expected behavior?
After selecting some scopes and being redirected to the client, the user wants to change his selection and comes back to the consent dialog using an oauth link with prompt=consent. Now I would like to pre-select the previously selected items in the dialog (so the user only has to mark the changes), but it seems I can't obtain them from hydra. I should be able to get a hand on them.

Which version of the software is affected?
latest beta

[aeneasr]

Due to the current implementation of the consent strategy this is actually not that easy to add. The complexity involved is that this can only work in certain circumstances where prompt=consent and where a previous consent exists that has been remembered and which has not expired yet. The reason for the latter is that we're actually not returning uninteresting (expired/not remembered) consent requests from the store.

Changing this would require some overhaul of the affected codebase and more or less a redesign of the strategy and storage implementation.

As the complexity for this change is rather high but the gain is rather low (as it would only work under certain circumstances), and because one could argue that prompt=consent should leave the user with the conscious decision to re-grant the requested permissions, this feature request will not be implemented for now. It might be revisited at a later point, but I'll close this issue in the meanwhile.

Thank you for your contribution!

[androbi-com]

I understand this might not be of highest priority right now, but it might even have legal issues. With the new GDPR, a user should have the right to know what permissions he gave to a certain app. Right now I don't see a way to implement this. Or can I query the last consent attributes somehow? (without prompt=consent?)

Also, have in mind that the certain circumstances you mention usually are the most probable situation, api permissions in most cases are very long lived and consent is given on first use of the app. So after the very first visit to the app the certain circumstances almost always are given.

[aeneasr]

but it might even have legal issues. With the new GDPR, a user should have the right to know what permissions he gave to a certain app.

Each user authorization (and thus access/refresh pair) may have different permissions. One flow might only need scope email, another might need email and photos, the next might only need address - and so on. It's not straight forward to tell (on the authorization server side) which scopes have been granted apart maybe from trying to go through the whole history and accumulating that data.

I think the legal argument under GDPR might hold, but this wouldn't be during the consent flow for me. Instead, this could be an endpoint where you can query for that data with the intent of making a detailed report which scopes have been granted before and which have not.

Also, have in mind that the certain circumstances you mention usually are the most probable situation, api permissions in most cases are very long lived and consent is given on first use of the app. So after the very first visit to the app the certain circumstances almost always are given.

That's true.

I'll reopen this so it won't get lost.

[androbi-com]

An endpoint to query the users current active (or last active) consent would solve the problem, as we could access this endpoint before showing the consent UI. Something like this will also be necessary if I want to display a list of all apps that the user gave permissions to, in this case as a UI the API service offers to the user.

[aeneasr]

Something like this will also be necessary if I want to display a list of all apps that the user gave permissions to, in this case as a UI the API service offers to the user.

I agree!

[davidf-uc3m]

What's happen when the user opens the app from mobile and choose some scopes, and at the same time open same app on desktop and select different ones?

How can you identify both flows to show different custom consent pages? Is there a way to identify which flow are tied to each scope selection? Does what I'm saying make sense?

Thanks!

[aeneasr]

Does what I'm saying make sense?

It does and it's actually a bit difficult to tell given that both apps (mobile and desktop) use the same OAuth 2.0 Client ID. Maybe we could simply return all the accepted consent requests in the API and you decide what to do with it?

[androbi-com]

Would it be possible to associate some user data to the login and/or consent requests? I guess the use case proposed by @davidf-uc3m would need something like that so he could identify where the consent request came from.

[davidf-uc3m]

We have a use case where we should identify at login time if the user is impersonated (and by whom) in order to detect if is a real user or not. This information is needed at consent time to build the id_token with this extra information. As @clausdenk suggested, remote ip, user agent, etc. would be enough in order to trace the users and their requests.
I think it would be enough and 'ext' field to add custom properties to the message accepting the login, in order to recover it when requesting consent challenge data.

[aeneasr]

As @clausdenk suggested, remote ip, user agent, etc. would be enough in order to trace the users and their requests.

As the user is accessing the consent and login endpoint using his/her browser, this information should be available to you without hydra relaying it, right?

[androbi-com]

Maybe my suggestion was not explained well enough. I suggested to introduce a user defined (unique) key, which can be associated with the consent request. Then, when retrieving all consent requests I also would get my keys so that I can identify each consent request:

• key1 -> consent data 1
• key2 -> consent data 2

Of course, the user could use remote ip, user agent etc. to construct this key (and thus "recover" the desired consent) but this is not hydra's task. The key should just not be too short and the user puts what he wants (even empty key) in it.

[aeneasr]

I see. Isn't that already possible by using the challenge? It's unique for each request and you can associate it in the consent app with the data you need. Or am I missing something?

[androbi-com]

Yes, this would be possible, but it would require persistence for the consent app. As all requests are stored within hydra, it would be nice to be able to attach some user data, this would make the consent app much simpler to implement. And it should be easy to implement in hydra (add an extra optional "user" parameter to the AcceptConsentRequest structure which will be handed back with the consent requests?).

Note that for my use case this is not necessary, I would only need a list of not expired consents. Even the last not expired consent would do.

[aeneasr]

I see, so something like login_metadata or consent_metadata right?

[androbi-com]

Exactly!

[davidf-uc3m]

Even both :-)

[aeneasr]

The OP issue was resolved by #953

If you're still up for login_metadata etc feel free to open a new issue so we can track it separately!