Manual Hydra Bootstrap

ORY Hydra
#1

I’d like to be able to leverage my existing KMS infrastructure on GCP with Hydra. I’ve developed an auth system to handout JWTs that I’d like to replace it with Hydra. (and its extra attention to the Oauth2 Spec along w/ built-in defenses!) Many of the existing underlying components should be able to be used with fosite - reading through the fosite documentation, I’m pretty sure I can implement a strategy to leverage the KMS infrastructure. However, I see no way to bring that into Hydra, even if I’d like to manually bootstrap Hydra and not use the precompiled version.

Specifically, I’ve implemented a signing method to leverage the IAM API on GCP (see: https://github.com/someone1/gcp-jwt-go) and want to use that instead of passing in a secret for Hydra to use for encryption/signing. GCP also handles things like key rotation automatically and I think I can also utilize Cloud Endpoints if JWT tokens are generated using this method.

Is this within the scope of Hydra or am I better off implementing the strategy for fosite and the corresponding /auth, /token, etc. handlers myself? Can I inject my own fosite implementation to the hydra/oauth2 package and be on my way, knowing I won’t need the additional features of Hydra?

I’d appreciate any guidance on this, I think I can leverage parts of Hydra using custom configurations, like for the oauth2 parts, but I’m perfectly fine utilizing the normal Hydra bootstrapping for the remainder of how the server runs.

#2

There are a couple of things here:

  1. Hydra doesn’t hand out JWTs as access/refresh tokens, this has security and workflow reasons. You could however use oathkeeper (https://github.com/ory/oathkeeper) to “translate” Hydra’s opaque tokens to JWTs
  2. Hydra uses its own key management for signing HTTP over TLS as well as ID Tokens. You could write a small proxy that tkaes keys from KMS and pushes them to hydra, shouldn’t be a big deal.

In general I’d recommend sticking with hydra unless you’re 140% sure it absolutely doesn’t fit your case. Adoption with fosite has higher risk of BC breaks which are harder (due to tight coupling) to mitigate.

Hope that helps

#3

I did see that hydra doesn’t utilize JWTs for access tokens out of the box, but this would be required if I’d like to leverage existing PKI/KMS infrastructure available to me, where I don’t have to worry about securely handling secrets and rotating them. In fact, I never have access to the private keys myself and offload all that to the KMS infrastructure (and in some cases, I don’t have the public keys either). This is separation of duties at its finest.

If I can bootstrap into Hydra with my own strategy for forsite, this shouldn’t be an issue. I’ll dig through the code and see if I can mangle something together. I’ll probably throw it up on github and would appreciate any feedback on it. I think it’s mostly just copying the oauth2.RS256JWTStrategy and jwt.RS256Strategy to use my own GCP implementation of the github.com/dgrijalva/jwt-go package (linked above) and bootstrap Hydra the same exact way otherwise.

#4

JWTs are excluded from Hydra (for access tokens) because it’s best practice to keep these things opaque! :slight_smile:

#5

JWTs are still used for OpenID, correct? And although I agree that opaque tokens are preferred, JWTs are still widely used, and for my (desired) use case, required. If used properly, the security risks are near-zero.

I read through Hydra/Fosite, I think I understand it correct, and did the following:

  • Created a package for ory/ladon using Google Cloud Datastore as a backend: someone1/ladon-datastore
  • Created a package for using GCP’s IAM API for signing JWT’s: someone1/fosite-gcp-oauth2
  • Created a package for bootstrapping hydra using the previous two packages and added datastore backends for everything in hydra: someone1/hydra-gcp

I’m working on making a functional example application, I’ve only done a little testing but so far it looks good (I’m sure bugs will pop up due to the sheer amount of reflection and such all throughout the application).

I could make PR’s for ladon and hydra for adding the datastore backend if you’re interested. This has an advantage as a fully-managed, highly available, massively scalable database engine (Google Cloud SQL can achieve similar feats but with higher costs and more devops work). I am already on this platform and wanted to introduce oauth2 capabilities without moving to a new IdP, a new database, etc. Hydra seems like the perfect fit with some small modification.

I understand how you might not want the GCP bootstrap method to be available in hydra and can respect that, but the added backends shouldn’t be hard to add from my packages into ladon and hydra. Let me know and please if you have any feedback for me, I’d love to hear it!

#6

JWTs are still used for OpenID, correct? And although I agree that opaque tokens are preferred, JWTs are still widely used, and for my (desired) use case, required. If used properly, the security risks are near-zero.

Yes, the ID Token is JWT. The purpose of the ID Token is a different one than access tokens. ID Tokens are consumed by clients, access tokens by resource providers.

I’m working on making a functional example application, I’ve only done a little testing but so far it looks good (I’m sure bugs will pop up due to the sheer amount of reflection and such all throughout the application).

That’s awesome! Unfortunately, we’re not accepting additional storage backends because we don’t have the resources to support them. There is however the possibility to link it in the official docs.

Regarding Hydra, it’s possible to utilize Go’s plugin system to add a new storage backend. We’ve done that in the past for OracleDB: https://github.com/ory/hydra-oracle-plugin