Consent App Flow

I have asked a question about consent flow before, but wasn’t specific enough.
Hydra has two sample consent app implemented in javascript and Go. Our company decides to use Java/Kotlin so I had to implement the Consent App from scratch. I translated the consent flow from Js sample consent app and Hydra-JS SDK as follows:

  1. Browser ask Auth Server for Authentication
  2. Auth Server redirect to Consent-app
  3. Consent app verify the challenge by
    3.1)Retrieves a public key from Auth Server
    3.2)Uses the public key to verify the challenge
  4. User logs in and authorizes the scopes
  5. Consent app creates a response:
    5.1)Retrieves a private key from Auth Server
    5.2)Creates a response message and sign with the private key.

I would like to understand more about step 5.1. Why do we need to request a private key over http, would it be better to do
1)Consent app generate a public/private key pair
2)Consent app sign the response using the private key and send to Auth Server
3)Upon receiving the response, Auth Server send a request to consent app for public key
4)Auth Server uses the public key to verify the response is from Consent Server

I know we are in a process to refactor consent flow, so most likely I will need change my current Consent App impl. Having some insight will be very beneficial.

Thanks very much!
Wei

1 Like

Hi Wei,

first of all let me tell you that the consent flow is due to a large refactor with version 0.10.0. Instead of relying on asymmetric cryptography and JWK + JWT standards, it will be possible to use the trust relationship between the consent app and hydra and issue a REST request to hydra, letting hydra know that consent was given. Because the new API is completely documented in swagger, you can use swagger-codegen to generate an java SDK. We use swagger-codegen for the Go SDK already and even use it in Hydra internally, so it’s working 100%.

Having said that, let’s come back to your question which covers 0.9.x:

  1. Browser ask Auth Server for Authentication

Teh work flow this is correct. I only want to point out that we are talking about Authorization in the concept of OAuth 2.0. If you want 100% accurate, you would have to say:

  1. App asks user for Authorization by generating the Authorization URL (pointing to Hydra)
  2. Hydra asks browser of user for authentication by redirecting to the Consent App

It is important to separate authorization (your ability to enter a country) and authentication (customs checking your passport).

Everything else in your flow is 100% correct.

I would like to understand more about step 5.1. Why do we need to request a private key over http, would it be better to do
1)Consent app generate a public/private key pair
2)Consent app sign the response using the private key and send to Auth Server
3)Upon receiving the response, Auth Server send a request to consent app for public key
4)Auth Server uses the public key to verify the response is from Consent Server

Yes, you are correct here. That would indeed be a better flow. However, what influenced our decision was a developer experience aspect: generating cryptographic keys correctly is hard. By having an encrypted storage in Hydra and the ability to transport JWKs over HTTP(s), the decision was made to sacrifice the standard PKI structure. In retrospect, we could have used shared secrets instead. This is also why we’re refactoring this part in 0.10.0 to make it more accessible and also more logical.

Cheers!

1 Like

By the way, it is possible to only store the public key in Hydra and generate the private key in your consent app, it’s just not the default way how it’s done at the moment.

Thanks Aeneas,
This is helpful. Do you have a timeline of when 1.0 will be available? I would like to allocate sometime for implementing the new consent app flow before upgrading.

Cheers,
Wei

Version 0.10.0 which includes the new consent flow is now available: https://github.com/ory/hydra/releases