Adding extensions to ory/hydra

ORY Hydra
#1

Hello folks,
We are planning to migrate our existing OAuth2 system to ory/hydra and have a custom workflow that I wanted to find out how to implement. Today, we have a bridge API call that allows the client to present a valid OAuth1 token and OAuth1 secret and we exchange that for OAuth2 Access Token and Refresh Token. This is built as an override to the ROPC grant handling i.e. in this case oauth1 token and secret is treated as login/password by the system and if found valid, OAuth2 tokens are issued.
I am wondering what’s the best way to achieve this in Hydra since ROPC is not supported.
Question-
Is there a way to add ROPC grant type extension if we wanted? In general, what is the supported way to add any custom behavior to Hydra like adding extension code, plugins etc and run in production?
Thanks in advance
M

#2

ROPC-ish grants can not be implemented with Hydra today.

#3

Thanks for the quick response. Appreciate it.
What would be your take on if we were to add custom code/extension to the project (just for our production usage, not compromising the main project). We have a chicken and egg problem because we need all the OAuth1 users to move over to OAuth2, so we need this bridge for sometime and then later it will be removed. So that’s why I am interested in doing something temporary as a local extension to the code.

#4

You could probably abuse the client_credentials grant if you really want to live on the edge.

#5

Thought about that. The problem with client_credentials grant is that the generated token would not have the uid (userid) so this would fail when the token is used for API call needing user context.

#6

In that case your only option is to keep the legacy system around for the migration, and move newer users to Hydra. You can use Oathkeeper to validate tokens from both.

Hydra will not support custom flows or other “bespoke” auth flows because they are not peer reviewed by an open community and most likely very vulnerable to a variety of attacks, if not audited properly.

#7

Hydra will not support custom flows or other “bespoke” auth flows because they are not peer reviewed by an open community and most likely very vulnerable to a variety of attacks, if not audited properly.

Fair enough. I guess we will have to do something custom for now then.
BTW, not supporting ROPC is little too extreme IMO :smile: . Most vendors like Okta, Ping and Auth0 support it
M

#8

No, it’s not too extreme. Auth0 deprecated this, Okta as well iirc. OAuth2.1 will explicitly remove it from the spec: https://oauth.net/2.1/

#9

I know both Okta and Auth0 recommend against using it but they still support it and so does ping. :slight_smile:
But I wasn’t aware of OAuth2.1 . That’s good to know.Thank you.
I am thinking about something like below

  1. Turn our OAuth1 token+ secret call into Authorize with this OAuth1 token and secret added to query params of the Authorize call
  2. At our login provider end validate these parameters and “autologin” the user, returning the user information to Hydra
  3. Hydra will return the auth code to client who should be able to exchange it to get Access and Refresh Token
    But I am not sure if Hydra carries the query params received in authorize call over to the call to login provider.
    M
#10

You could try and solve it like that but I honestly can’t give feedback because it is really hard for me to judge what you’re doing there and what implications (security, UX, or otherwise) this has. The only thing I can say is that if you seek OpenID Connect Certification, this will be a red flag.