Different behavior between MITREid / Hydra

[monwolf]

Hi,

Currently, we have implemented the MITREid Connect implemented on our microservice platform generating JWT for authenticating the connection between the microservices.

For performance issues, we would like to replace our solution for Hydra it seems to work smoothly under big workloads.

After digging a little bit we found 2 main differences in the response:

• The claim scope is changed by scp in ory/Hydra this is not a big deal we need to adjust a little bit our middleware

• If the request doesn't contain any scope, you receive an empty list of scp in the response, while in MITREid Connect you get the full list of scopes assigned. Is there any way to get the full list without having to specify it?

Thanks for your effort!

[aeneasr]

The claim scope is changed by scp in ory/Hydra this is not a big deal we need to adjust a little bit our middleware

We recently merged a patch in ory/fosite which would allow changing this to scope!

If the request doesn't contain any scope, you receive an empty list of scp in the response, while in MITREid Connect you get the full list of scopes assigned. Is there any way to get the full list without having to specify it?

Depends, if you are not talking about client_credentials grant, you can choose the scope freely during the consent step. For client_credentials grants I am not sure if that's possible at the moment, but there have been ideas around supporting JsonNet transformation #1748 !

[monwolf]

Hi @aeneasr,

Thanks for your response :)

Regarding the first point do you have the commit/issue id to check it?

In the other point, we are talking about client_credentials. I think for our use case adding jsonnet is like trying to use a sledgehammer to crack nuts, for me the best solution would be to add a config param (general o per client) allowing to choose the behavior.

Thanks!

[aeneasr]

In the other point, we are talking about client_credentials. I think for our use case adding jsonnet is like trying to use a sledgehammer to crack nuts, for me the best solution would be to add a config param (general o per client) allowing to choose the behavior.

Haha - makes sense!