oauth2: Improving the consent flow design

[aeneasr]

As part of our efforts to become OpenID Connect Certified, we are improving the consent flow and working on various issues such as #720 #692 #697. Please engage with this issue and help us find the best solution.

The state of the consent flow as of today

The consent flow's intention is receiving a user's authorization for granting an access token on the user's behalf. The access token has a subset of the user's permissions (scopes). To identify the user, the consent app typically requires prior authentication. So usually, the flow looks like this:

1. Hydra receives an OAuth 2.0 Authorization request
2. Hydra redirects the user agent to the consent app
3. The consent app validates the user's session, or if no session exists requires the user to log in
4. After successful authentication, the consent app asks the user to grant certain permissions to the client that initiated the request
5. After successful consent, the consent app redirects the user back to Hydra
6. Hydra issues the tokens and so on.

This flow has several advantages:

1. The developer is free to implement the login and consent screen with whatever programming language and tools.
2. The identity management is completely left out of Hydra.

But, this flow has several disadvantages as well:

1. The consent app needs to be aware of certain OpenID Connect concepts, such as reserved scopes (email, profile, ...)
2. It is not possible to skip the consent screen in the consent app, as the consent app does not know if the user already authorized this application before - without managing this state itself
3. It is not possible for hydra to just ask for consent (prompt=consent)

While the aforementioned limitations are resolvable by leaving this to the developer, it makes integration harder than it should be, and opens up potential for bugs and vulnerabilities. Here is a (work in progress) state diagram that shows what an industry-standard OpenID Connect consent app would need to do:

While it is possible to disregard some of those features, such as

• Remembering previous consent
• Remembering previous authentication

it results in worse user and developer experience. The diagram for such an app would look like this:

It's less work, but it's still work. It still needs to understand and handle certain scopes, and so on.

We think that the most sane approach, that improves user and developer experience, is to reduce the scope of the consent app. This is outlined in the next section.

Handling consent in ORY Hydra and simplifying the consent flow

The idea of this approach is to keep the core concept of the consent flow, but use it for authentication only. Instead of the consent app needing to handle scopes and authorization, it just needs to tell Hydra who the user is and send some additional user data if OpenID Connect should be implemented. It would also mean that the consent app would be renamed to "Identity Provider", "Login Provider" or "Identity Management".

Let's start off with a bit of terminology:

• Authorization Server (AS): This is ORY Hydra
• Login Provider (LP): This is the consent app, but it is only handling user authentication, not scopes or anything like that.
• Authentication Request (AR): This is what the consent request was previously. It's a unique ID that is generated by ORY Hydra.
• Authentication Flow: This is the consent flow, but renamed to better reflect what is happening.
• Client App: This is some OAuth2 Client App that wants an access token and that performs the authorize code flow, or the implicit flow.

A high level overview of the authentication flow would look like this:

Now, Hydra has all the information required to finish the authorization flow. As a next step, Hydra would show some ui where the user is asked for permission to grant the application access to the set of scopes.

It is obvious, that this is much less work for the developer, it has fewer pieces which can go wrong, and it's much easier to integrate.

Let's come to the tricky parts next. ORY Hydra was originally designed with a "no-ui" mantra. Over the lifespan of the project however, we discovered that it's not that easy. There are certain ui pages that are necessary, such as errors during the authorization flow. While we were able to offset these errors by delegating them to the consent app, it was not a very clean concept.

The core idea behind "no-ui" is to leave the UI implementation 100% to the developer integrating with ORY Hydra. UI can be tricky:

• Typically, the UI should look like every other page on the website - it should integrate in the CI
• UIs need to handle different locales
• Developers may want to display additional things (e.g. data)

Unfortunately, this concept inhibits the ability to be 100% OpenID Connect compliant and complicates the integration of ORY Hydra.

As a result, we are discussing if we should implement the flow shown above, and serve the html ui for the consent screen in ORY Hydra. So far, we have identified the following features that would be required for this to work properly:

• The developer must be able to replace or modify the consent screen HTML template
• The developer must be able to serve custom CSS or even JS for the consent screen.
• The developer must be able to add human-readable titles and descriptions for scopes.
• It must be possible to add translations for scope titles and descriptions and show these translations according to the requested locale.
• It must be possible to translate arbitrary text (e.g. "Authorize Application")
• It must be possible to log out of a session in the consent screen, given that the user changed. Log out should destroy session data and re-initialize the authentication flow

This is what we have so far. Please add your comments, ideas, and alternatives below.

[rjw57]

Thanks for writing this up. Some comments based on our (University of Cambridge) experiences with Hydra.

We're moving forward with deploying hydra in production for an internal service. Although an internal service, we have in the 10s of thousands of users and a mature SSO web UI solution. For us, the UI-less nature of hydra is an absolute god send since it lets us make the plumbing used by the OAuth2 provider invisible to the user.

As a secondary advantage, we are finding the option to be a little non-conformant with the consent app is useful for our initial roll-out where the use of an OAuth2 server is essentially an implementation detail. (Having a single "token" allows us to pass user authentication around our various backend services using hydra as a single point of validation.) For this case we appreciate the option of making the user experience just like our other web SSO based services where the user is re-directed to our login portal and then back to the webapp. "Consent", in these applications, is inferred from the user being willing to provide authorisation credentials. (This would not, of course, be true in general but a) this service is for internal users only and b) we have a controlled set of OAuth2 clients.)

We very much appreciate the clear desire to be standards compliant and the attention to detail provided within hydra which is why we're willing to move forward with an internal production deployment at this stage.

We find the current consent flow to provide a good amount of control over the consent process in a place we would like it: our consent app. It also has the advantage of being very quick and easy to implement.

From our perspective we'd like to retain the UI-less option and have the flow diagram in the issue replicated in the hydra docs as a example of how to interpret the mustAuthenticateUser, etc options hydra would provide.

So, as a concrete suggestion, perhaps a good mid-ground would be to have a "blessed" UI-containing consent app implementation which redirects to the LP? Maybe as a separate container or as a configuration option? Then one has the two options:

1. If you just want to integrate an existing identity provider, use "hydra" + "hydra consent" app. Blessed consent app uses existing consent flow but redirects to user-provided LP for authentication and LP redirects back to consent app as in the final diagram. This would be the OpenID Connect-friendly way.

2. If you have more subtle needs, you have the option of implementing your own consent app using something like the existing consent flow.

This way hydra proper can remain UI-less, the consent flow can remain similar to how it is at the moment (which I find to be a sweet-spot on the complex/powerful axis). The combination of "hydra" + "hydra consent" is then OpenID Connect Certifiable but power-users can opt to implement their own consent app.

Thanks once again for hydra. We evaluated a number of options internally before settling on hydra and the fact that it did everything but the UI for us was one of the strongest selling points.

[aeneasr]

Thank you for your feedback, it is much appreciated! I am not sure if this got through, so I quickly want to reiterate on something:

The login / authentication piece (which is part of the consent flow) would not be replaced. Only the consent screen where the resource owner grants scopes would be moved out of the consent app. It should be possible to make this template customizable, with the usual downsides (not your favorite template language, no css/js toolchains, simple markup). It would still be possible to skip consent with a special scope (e.g. force-consent) issued to first-party clients.

From our perspective we'd like to retain the UI-less option and have the flow diagram in the issue replicated in the hydra docs as a example of how to interpret the mustAuthenticateUser, etc options hydra would provide.

It doesn't really end there, unfortunately. There are many different use cases and some of them are not implementable using the current consent flow. These use cases have various primitives, namely:

1. User is not authenticated at Hydra
2. User is not authenticated at Consent App
3. User is authenticated at Hydra
4. User is authenticated at Consent App
5. User has not authorized app before
6. User has authorized app with specified scopes (or subset of those) before
7. User has authorized app, but app needs more scopes now

Additionally, we have OIDC prompts:

1. prompt=none fails if user does not have a session at Hydra.
2. prompt=consent must show consent screen, does not require authentication.
3. prompt=login must (re-)authenticate user, consent screen is optional (and based on previous consent).

For the consent app it is currently impossible to check if a user has previously granted access to an application or not. This implies that with any (re-)authentication, the user must also re-authorize the app. While this doesn't really bother OIDC compliance, it does bother user experience. While it would be possible to fix that using another API call, it adds another layer of complexity.

The consent app is also not capable of just handling consent without prior authentication if the user is authenticated in Hydra but the client app is lacking authorization.

In any case, the question I have for you is the following:

Do you want to implement the consent screen, where you select the scopes, yourself - or is it ok if Hydra handles that. Again, the log in screen will not be touched.

[aeneasr]

Oh and a last one, we definitely want to have a reference implementation for the consent app. The unfortunate issue is though, that we won't support login there, so there's still stuff that developers need to adapt / change, and the more complex this flow gets, the less secure it becomes.

[rjw57]

Do you want to implement the consent screen, where you select the scopes, yourself - or is it ok if Hydra handles that. Again, the log in screen will not be touched.

Usual caveats aside, I think we would like to implement the display and selection of scopes ourselves. Some scope grants may be implied or mandated by a subject's role within the organisation, for example, which is probably not capturable in a template based workflow.

So, if I understand correctly and this change were to become something like splitting what is now called a "consent app" into a "show and select scopes" app and a, possibly, separate "login provider app", I think that could work for us. Presumably hydra would take care of tracking whether the token subject logged in before and what scopes have and have not been previously granted for the client?

[rjw57]

While we're at it, I suppose there could also be a dedicated error reporting endpoint. So the hydra configuration now contains URLs pointing to a "select and show scopes" endpoint, a "perform user login" endpoint and a "display error" endpoint. The select and show scopes and error endpoints could default to UI apps provided by hydra.

[rjw57]

But advanced users can provide their own endpoints for all three. (Sorry, on mobile and hit "submit" a bit early.)

[aeneasr]

Some scope grants may be implied or mandated by a subject's role within the organisation, for example, which is probably not capturable in a template based workflow.

If you were to do this, it would be a security issue - and our OAuth 2 authorization framework is designed in a way that this isn't possible either! Scopes are not what a user can do in a system, scopes are what you allow a certain application to do on a user's behalf. It doesn't say what the actual user is allowed to do or not. We might add the possibility to auto-grant certain scopes (e.g. offline) but it's not clear yet.

So, if I understand correctly and this change were to become something like splitting what is now called a "consent app" into a "show and select scopes" app and a, possibly, separate "login provider app", I think that could work for us.

Yes

Presumably hydra would take care of tracking whether the token subject logged in before and what scopes have and have not been previously granted for the client?

That's basically the idea behind this issue. #720 already takes care of some pieces here but while developing it I noticed that there are certain inconsistencies which are not resolvable with the current flow.

While we're at it, I suppose there could also be a dedicated error reporting endpoint. So the hydra configuration now contains URLs pointing to a "select and show scopes" endpoint, a "perform user login" endpoint and a "display error" endpoint. The select and show scopes and error endpoints could default to UI apps provided by hydra.

That was one of the ideas how to modify those pages. It would probably not make it in to 1.0.0 because it would require significant work in order to make this bombshell secure. For the error endpoint, it would be easier because it's not that of a security issue.

But advanced users can provide their own endpoints for all three. (Sorry, on mobile and hit "submit" a bit early.)

We definitely want to have an option to extend the UI. Either directly via Hydra (which is as you pointed out not perfect) or through some other means.

In conclusion: Now that you have a better understanding, what's your take at this? I really see that the no-ui approach is something that propelled Hydra to what it is today and also to what it sets apart from the competition. I am actually sort of drifting in direction of having separate login, consent, and error endpoints (with default state of the art apps), but the flow has to be air tight.

I might draft something today or in the coming weeks, and would really appreciate 👀 to make sure it's headed in the right direction.

[rjw57]

In conclusion: Now that you have a better understanding, what's your take at this? I really see that the no-ui approach is something that propelled Hydra to what it is today and also to what it sets apart from the competition. I am actually sort of drifting in direction of having separate login, consent, and error endpoints (with default state of the art apps), but the flow has to be air tight.

If it took the form outlined in this discussion, then I quite like the idea of the separate login, consent (aka show and select scopes) and error endpoints. It seems a neat way of delegating the UI while retaining control over the logic. The UI-less nature of Hydra really is a USP in some quarters, including ours.

[aeneasr]

Ok, so let's define this a bit.

Terminology

• Authorization Server (AS): That's Hydra
• User Authentication (UA): The process where the end user inputs username and password (or other types of credentials like biometric data) into a UI.
• App Authorization (AA): The process where the end user explicitly allows an OAuth2 client to perform certain actions on his/her behalf. Typically a UI where the user ticks some boxes ("Allow access to my profile data").
• Error Handling (EH): When clients make invalid requests that must not be handled by the client itself - for example when the redirect URL is invalid - must be shown to the end user.

Motivation

The current consent flow inhibits Hydra's ability to properly handle previous user authentication and app authorization. This does not certainly contradict OIDC certification, but it reduces user experience. Our motivation is to find a highly customizable and secure flow for resolving this issue, with keeping implementation as easy as possible.

How it works today

The current consent flow consists of two pieces:

1. User Authentication
2. App Authorization

These two are combined into one flow - namely the consent flow. Due to this it is not possible to separate User Authentication from App Authorization which causes the issues described in motivation.

How it should work in the future

We will explore different ideas in the following sections.

Three endpoints for User Authentication, App Authorization, and Error Handling

One idea is to have four separate endpoints for AS, UA, AA, EH:

• AS: https://hydra.mydomain.com/
• UA: https://auth.mydomain.com/login
• AA: https://auth.mydomain.com/consent
• EH: https://auth.mydomain.com/error

There are four possible environments in which an authorization request exists:

1. The end user is not authenticated and has never authorized the application with the requested set of scopes.
2. The end user is not authenticated and has authorized the application previously with the requested set of scopes.
3. The end user is authenticated but has never authorized the application with the requested set of scopes.
4. The end user is authenticated and has authorized the application previously with the requested set of scopes.

Use cases

Use case 1

1. User Authentication
   1. App initiates OAuth2 Authorize Code / Implicit flow.
   • Hydra requires authentication, redirects to UA.
   • UA authenticates end user with some credentials. UA MUST ALWAYS authenticate the user - disable session management!
   • UA notifies Hydra of user authentication and transmits user data (Hydra will filter out data based on OIDC defined scopes)
   • UA redirects user to Hydra
2. Application Authorization
   1. App has never been authorized by the user with the requested set of scopes.
   • Hydra redirects to AA
   • AA fetches information about this authorization request (like requested scopes) and asks for authorization
   • AA pushes authorization details (accepted / rejected + granted scopes) to hydra
   • AA redirects to hydra
3. Hydra continues with OAuth2 flow

Use case 2

1. Same as use case 2.1
2. Application Authorization
   1. Because application has been authorized previously with the requested scopes, the requested scopes are auto granted and no user interaction is required.
3. Hydra continues with OAuth2 flow

Use case 3

1. User Authenticatoin
   1. Because user is authenticated already, Hydra goes straight to handling application authorization. Note that user data (eg email claim in ID token) can not be updated in this case.
2. Same as use case 1.2
3. Hydra continues with OAuth2 flow

Use case 4

1. Same as use case 3.1
2. Same as use case 2.2
3. Hydra continues with OAuth2 flow

Discussion

Let's take a look at advantages / disadvantages:

• Advantages:
  • It is possible to properly hand previous AA and UA in Hydra, greatling reducing adoption complexity.
  • We would probably ship a default application for handling AA so all devs need to do really is implement UA.
• Disadvantages:
  • It is not possible to update user data when authentication is "cached" in Hydra. This includes any data in access and id tokens, as well as Hydra's built-in /userinfo endpoint.
  • From our perspective, the flow is quite complicated with many moving parts. We have to be especially careful when designing it and it would take an extended period of time before this can be declared stable.

Hydra handles app authorization

In this case, Hydra would handle AA with a built-in UI, while delegating UA to the customizable login endpoint.

• Advantages:
  • Devs don't need to think about AA
  • The flow is easier to implement (on our side) and has less surface for vulnerabilities
  • We can standardise the AA and it will be really easy to integrate, because all a dev needs to do is implement UA
• Disadvantages:
  • UI customization can only go so far - CSS and JS options are limited and Go's HTML template language is terrible IMO
  • No business logic customization. While it would probably cover 80% of use cases, it wouldn't cover the 20%. From what we've heard, full customization of the ui flow is why this project stands out.
  • i18n is not pretty with Go's current ecosystem - no good solution exists and no stdlib either

Final Note

Please let me know which direction you think is the right one. I will draft up some charts for the solution which gets people more excited.

[aeneasr]

Here are some high level squence diagrams for the aforementioned issues.

Three endpoints for User Authentication, App Authorization, and Error Handling

The error endpoint is not really included here because it's an edge case with almost no implication to security

Hydra handles app authorization

[rjw57]

I think the three endpoint (AS, AE, CE) case seems superior. Especially if Hydra implements or provides a default CE implementation. The default CE implementation can then be "lightly" template-able for simple use cases but still provides flexibility for advanced users. This reduces the likely pressure on the default CE endpoint to implement feature X or template hook Y.

The three endpoint case is also conceptually simpler since OAuth is essentially "authentication", "authorisation" and "plumbing to allow said". Hydra then neatly fits as the "plumbing".

The two endpoint case (AS, AE) is also workable but is likely to open some flood gates w.r.t. feature requests for improvements to templating/customisation/etc which might dilute hydra's "small, simple, easy to grok" nature.

[aeneasr]

The two endpoint case (AS, AE) is also workable but is likely to open some flood gates w.r.t. feature requests for improvements to templating/customisation/etc which might dilute hydra's "small, simple, easy to grok" nature.

I agree. You convinced me (95%), thank you very much for your valuable input! I would really appreciate your take on the redirect flows and stuff like that which I will post in this issue soon.

[rjw57]

No probs. I'm subscribed to the issue but also feel free to @-tag me if I seem to have missed it.

[aeneasr]

Ok, so there are multiple moving parts where we need to be sure that no attacker is able to swoop in. We would rely on the same measures like OAuth2 for protecting the total flow which is TLS must be enforced everywhere.

Attack Scenarios

Tricking Bob to authenticate

Scenario:

• Malice initiates an OAuth2 flow by clicking "Authorize". Malice is redirected to the authentication endpoint login.com/login?login_challenge=1234
• Malice convinces Bob to open login.com/login?login_challenge=1234 and authenticate
• Now that login_challenge=1234 is associated with Bob, Malice could trick the Authorization Server to issue tokens on Bob's behalf.

Mitigation:

1. The Authorization Server issues a login verifier which is only visible to the person that performed the login. In this case, Malice would not know what the verifier is because only Bob sees it, and because it is protected via TLS.
2. The Authorization Server issues a CSRF session to the person initially requesting the OAuth2 flow. In that case it would be Malice. If a verifier is received that does not match the CSRF session, the request is blocked and the challenge/verifier banned.
3. If a verifier is used twice, all access and refresh tokens associated with it are revoked and the challenge/verifier is banned

Tricking Bob to consent

Scenario:

Assuming that Bob authenticated and is now asked to grant permission using a consent_challenge, and that Malice is able of reading consent_challenge, Malice would be able to grant permission for the app on Bob's behalf and optionally receive the authorize code.

Mitigation:

Issuing the consent_challenge requires prior authentication, either through a session cookie or through performing the authentication flow. Thus, Malice could only have access to a consent_challenge for his own authenticated session, unless he is able to MITM the consent_challenge somewhere, or Bob's session cookie.

Tricking Bob to disclose sensitive information

Scenario:

Malice authenticates with his account and authorizes the requested scopes. He is now in possession of the consent_verifier and tricks Bob into using that verifier at Hydra. Now, Bob is authorized as Malice and Malice could trick Bob into submitting confidential data to Malice's accounts (e.g. passwords, credit cards, ...).

Mitigation:

Because Bob does not have a valid CSRF session (Malice initiated the flow and only Malice has the CSRF cookie in the user agent9, the consent_verifier request will fail. It's thus not possible to trick Bob.

Flow overview

With the above scenarios and mitigations, I established a flow that would look like the following graph. A flow diagram will follow as well to properly document decisions with regards to these scenarios.

[pnicolcev-tulipretail]

I'm late to the party. Great discussion, thank you for being so open about your goals and asking for feedback. It's greatly appreciated so we can scope our project accordingly.

I'm in agreement with rjw57. The consent app flow has been perfect for us because it's so powerful. Leveraging Hydra without a UI has distinct advantages in terms of flexibility. I also understand that the number of cases that need to be accounted for, especially once you support prompt, can have us shoot ourselves in the foot. This is something we're willing to tackle, but not everyone will get it right.

I strongly prefer the 3 endpoints solution. It seems like an elegant compromise if it helps you to handle the burden of user state complexity without sacrificing the power we have. If you were to offload display and consent logic to hydra, I'm sure there would be many feature requests to reintroduce things people have done. For instance: we would like to run Hydra in a multi-tenant environment, meaning different styles for each tenant. We'd also like programmatic customization of login (and consent) pages in the long run.

Furthermore, rjw57 mentioned that consent is implied for certain applications in their system. Ours is the same. For now all our apps are trusted and we skip the consent step, going forward we plan to make this configurable.

I see the collection of services as an events system. Each endpoint can trigger any business logic needed on our end. On that note, a logout endpoint would also be useful for us, depending on how you go forward supporting logouts.

The only potential concern I can think of is that you state: "UA authenticates end user with some credentials. UA MUST ALWAYS authenticate the user - disable session management!"
We actually have incorporated a SAML authentication endpoint for a 3rd party (a-la Dex) and they're in charge of sessions, as opposed to our consent app. I believe we can force a login with them with our authN assertion, so hopefully this is something we can work around.

[rjw57]

With the above scenarios and mitigations, I established a flow that would look like the following graph. A flow diagram will follow as well to properly document decisions with regards to these scenarios.

I've not properly had a change to think about the flow from a security perspective but from a functionality perspective this looks to be the right shape of things for us.

[aeneasr]

Thank you for your feedback @pnicolcev-tulipretail - your points are very sensible and you draw some good conclusions which push me further in the direction of the 2-legged auth/consent flow.

The only potential concern I can think of is that you state: "UA authenticates end user with some credentials. UA MUST ALWAYS authenticate the user - disable session management!"
We actually have incorporated a SAML authentication endpoint for a 3rd party (a-la Dex) and they're in charge of sessions, as opposed to our consent app. I believe we can force a login with them with our authN assertion, so hopefully this is something we can work around.

This is a must for OIDC compliance!

I've not properly had a change to think about the flow from a security perspective but from a functionality perspective this looks to be the right shape of things for us.

@rjw57 I'm looking forward to your feedback wrt this.

[dtt101]

@arekkas - thanks for sharing this process - very valuable to read your thoughts, and the contributions from other users (especially @rjw57 - we are also based in Cambridge, UK!)

Firstly a 👍 on the UI-less nature of hydra at the moment - building our own consent app has enabled us to implement many features that would be very complex to support if Hydra was responsible for serving the UI, custom messaging, branding (including serving different messaging for different client applications) and being able to present something 100% consistent with the rest of our web estate, (I am basically restating the case that @rjw57 and @pnicolcev-tulipretail have made).

I also prefer the three endpoints approach - our current approach of bundling the consent flow and user auth into one application has introduced a degree of complexity.

A couple of things would be useful if hydra is responsible for maintaining previous app authorization:

• A way to present back to a user what applications they have previously consented to, and to revoke consent on a per application basis
• A way to revoke all application consents at once (for example if we believe a user account has been compromised)

Finally - for developers new to the Hydra project a 'blessed' implementation (similar to the existing express and go consent example apps) for all endpoints would allow people to get up and running with Hydra with minimal effort. We would be happy to contribute.

[rjw57]

So I've had time to have a look at the flow proposed above. It seems sensible but, of course, the proof is in the implementation. I see that lessons from issues discovered in the current consent flow have been folded in which is good.

It looks like the consensus is falling on the three-endpoint solution and I'm going to echo @pnicolcev-tulipretail and @dtt101's enthusiasm for it from a UI-less perspective. (And, @dtt101, waves at Pi towers.)

Thanks, once again, @arekkas for engaging on this issue.

[aeneasr]

• A way to present back to a user what applications they have previously consented to, and to revoke consent on a per application basis
• A way to revoke all application consents at once (for example if we believe a user account has been compromised)
• Finally - for developers new to the Hydra project a 'blessed' implementation (similar to the existing express and go consent example apps) for all endpoints would allow people to get up and running with Hydra with minimal effort. We would be happy to contribute.

All three are very sensible feature request!

So I've had time to have a look at the flow proposed above. It seems sensible but, of course, the proof is in the implementation. I see that lessons from issues discovered in the current consent flow have been folded in which is good.

Thank you! If it's ok, I'll request your review when the PR is up. Obviously, it will be a larger one because there are a couple of things that will change.

It looks like the consensus is falling on the three-endpoint solution and I'm going to echo @pnicolcev-tulipretail and @dtt101's enthusiasm for it from a UI-less perspective. (And, @dtt101, waves at Pi towers.)

I embrace the consensus, I think it's a good middle-ground for what we need to achieve!

[sandrom]

Did you consider a use case, that giving consent to certain scopes or even everytime getting another token might require a second factor of a user or even a fresh login in this concept? currently integrating a 2dn factor at least for consent on specific scopes is easy, but it would not be that easy anymore with this change. is it thinkable to make an optional consent app possible anyway? Otherwise very specific requirements might make hydra harder to use or you'll have to integrate 2nd factor logic stuff into hydra (which might be different very often)

let me be more precise: we would need 2nd factor after a successful login to give consent, meaning it has to be something possible "in the middle or as a requirement for consent". splitting identity provider and consent app up would be ok, but it would still need to support that way of handling it for us

[aeneasr]

Did you consider a use case, that giving consent to certain scopes or even everytime getting another token might require a second factor of a user or even a fresh login in this concept?

1. 2FA on certain scopes: That's still possible. We can include the scope information in the authentication request so it should not be a big deal.
2. 2FA on token re-issuance: Not sure what you mean here? Are you talking about refresh tokens or performing the authorize code flow a second time?

In general, 2FA should be requested by the client app using things such as acr. We could add an option to the API to mark the session unsticky, implying that no session cookie will be stored and that the consent can not be reused, and must instead be regained.

It would generally be possible to do both - having auth and consent endpoint and also allow consent apps to do everything. But we're adding a ton of complexity and difficulty for implementation here, which leads to potentially insecure behavior and overall bad design. I'd like to keep it as simple as possible (having two endpoints is already complex enough) and don't think all flows will be supported. But we can definitely try to find a solution for edge cases, as long as the complexity is justifiable.

[sandrom]

@arekkas
Yes it sounds reasonable. Actually if we could have the session optionally not-sticky and with a rather low timeout (important to distinguish between maximum lifetime and idletimeout though) we could implement all the necessary workflows. only a small percentage of users would ever have an issue with that, and that would be fine :)

[p-bakker]

Very interesting read this topic, clarifies a bunch of things for me, while currently trying to figure out whether Hydra fits our needs or not.

One thing I'll add to the discussion that having good documentation & samples would be a must, regardless of the approach taken. Am currently finding it quite hard to figure out exactly how to get Hydra and the consent flow going: documentation seems a bit scattered and out of date or requires you to anylise the NodeJS/Go code

@arekkas any approximate timeline for having the stuff discussed in this issue available in the product? As I mentioned we're evaluating whether Hydra fits our needs (seems so). If the whole consent flow will be replaced with the approach outlined in this case, depending on the timeline, it might be better for us to hold off on implementing Hydra with the current consent flow and wait for the new approach to be available

[pnicolcev-tulipretail]

I do agree with the comments on the documentation. I think that some parts regarding the relationship between client scopes, user scopes, and policies can get pretty confusing. Part of this is just the nature of OIDC/OAuth2 but I think a breakdown of exactly what components need what perms would make it easier.

[aeneasr]

One thing I'll add to the discussion that having good documentation & samples would be a must, regardless of the approach taken. Am currently finding it quite hard to figure out exactly how to get Hydra and the consent flow going: documentation seems a bit scattered and out of date or requires you to anylise the NodeJS/Go code

Absolutely, it would be also great if you (the readers) could help improve the documentation, or at least identify the issues and create issues in the repo with questions / ideas / improvements. It would help tremendously, because I know the technology and software so I can't say what's explained well and what isn't. Also, not an english native speaker :(

@arekkas any approximate timeline for having the stuff discussed in this issue available in the product? As I mentioned we're evaluating whether Hydra fits our needs (seems so). If the whole consent flow will be replaced with the approach outlined in this case, depending on the timeline, it might be better for us to hold off on implementing Hydra with the current consent flow and wait for the new approach to be available

There's currently a sprint planned in late April which will tacle this. I'll be working on docs before that, basically streamlining everything etc.

[p-bakker]

@arekkas

Tnx for the update on planning.

As for docs: will share my findings/thoughts on how to improve the docs

[kavuri]

I agree with @p-bakker on a sample app for consent flow (with a reference UI) for a quick start will immensely help to get a grasp of the internal details. Are these API end-points available now? I am looking at hydra-consent-app-express for a quick start

[aeneasr]

No, it's still in development

[rjw57]

No, it's still in development

And that's absolutely fine. It's great that the design work is being done in such an open way. Am I right in thinking that anyone interested in getting a "sneak peek" at this should be looking for commits landing in the 1.0.x branch?

[aeneasr]

Yes, that's the branch!

[genesis32]

Super late to the party but I'll throw my 2 cents in here. We are currently going live with a number of large customers. The consent app has been great because we control all of the authentication/authorization logic and hydra is basically just a trusted bridge between our IDP and our API's.

There was a note back when 0.10 was released that said "We know that these are a lot of changes, but we highly recommend upgrading to this version. It will be the last before releasing 1.0.0." We did the work to upgrade to the new consent flow (well worth it in my opinion).

Making breaking changes at this point in time could push us behind other product timelines and we have more important things to be doing.

I'm all for improvement but there needs to be some backwards compatibility or an extended timeline for support on the functionality that constitutes the 0.11 branch. I would prefer to not fork this project and have to apply any bug fixes there.

Great work on this by the way! It's been awesome to use.

[aeneasr]

You can stay at the 0.11 branch until you're ready to move on. The new changes are important to get OpenID Connect Certification which is an important goal for 1.0.0. It's unfortunately not (easily) possible to keep both BC and achieve OIDC Certification. We were not aware of the wide scope the OIDC Certification process has, which is why we had to break the promise made in 0.10.0. But it's better to have secure, reliable software, than to keep BC at all cost.

We do not support outdated version as part of our open source work (we are very limited in resources), but we do have paid support plans if you wish to have an older version supported by the core maintainers.

If you do have an idea on how to improve the new flow and make it backwards compatible, it would be immensely helpful.

[aeneasr]

Oh and we can, of course, help you adapt to the new changes if you need dedicated help from core devs/maintainers! Just write an email to hi@ory.am or ping me in the chat.

[mderazon]

What an awesome open discussion. Helped me a lot understanding the changes coming in 1.0.
Thanks for all the participants.

2 pieces that are still missing for me are user registration and logout.

I guess registration is no different than login from Hydra's point of view ? UA tells Hydra there's a new user and sends the details just like it would have on login. But still, a session might need to be saved on the UA when the user navigates from login page to sign up page ?

And regarding logout, would that be done via calling Hydra's /oauth2/revoke endpoint ?

[aeneasr]

2 pieces that are still missing for me is user registration and logout.

I guess registration is no different than login from Hydra's point of view ? UA tells Hydra there's a new user and sends the details just like it would have on login.

Registration does indeed not concern this at all. The only process we're interested in is authentication. Whether or not you want to have a registration process prior to that is up to you.

But still, a session might need to be saved on the UA when the user navigates from login page to sign up page ?

Do you mean in the case where the user does not have a valid user account and must register one first? In this case, you'd want to redirect the user back to either the original request URL (/oauth2/auth) or to the login url with the login_challenge (/login?login_challenge=...)

[Detrous]

@arekkas hello!
Can i skip screen "An application requests access to your data!" ? I need only authorize user and use his token to requesting API through Oathkeeper+Keto. App have't scopes, only rules and roles in Oathkeeper+Keto

[aeneasr]

You may skip this for first-parties (skip as in always grant the requested scopes) but you shouldn't do so for 3rd party apps (apps written by developers other than you / your company)

[Detrous]

@arekkas how I can do this "skip" ?

[aeneasr]

Since you implement the app, it's up to you and your business logic. Not sure what you want to hear here ;)

Please refrain from asking further questions in this issue as it's closed, not on topic, and doesn't meet the issue guidelines and unnecessarily spams the inboxes of everyone that has participated in helping hammer out the design of the new consent flow.

You can always ask questions on implementation details in our chat or the forums.

Thank you for understanding.