Hi there, first off thank you for the excellent do...
# talk-hydra
l
Hi there, first off thank you for the excellent documentation. I am a bit new auth and was hoping someone could clarify a question I have about Oauth2 and Hydra with our intended use case. We want to set up an authorization server with identity management. We would like our users to login through the Authorization Code Grant flow, and make requests to our API with the JWT that they get from the authorization server. Am I correct in assuming this is a valid OAuth2 use case? In this scenario it seems as though I need both Hydra and Kratos, Hydra as the authorization server, and Kratos for identity management. I was looking through the documentation and have been struggling to find out how to integrate Hydra and Kratos -- the docs speak of some 'bridging' code, but I battling to find a good example of how that is done. Can anyone point me in the right direction? Thank you in advance for you time.
b
shameless plug but here is my bridge code 🙂 https://github.com/atreya2011/go-kratos-test/tree/hydra-consent
n
Users do not login through OAuth 2.0, that sounds like authentication, which is not what OAuth 2.0 is for. OAuth 2.0 is for providing a third party (i.e. the “client”) with access to communicate with an API on behalf of a user, so by definition the person making the request is not the user. If you want authentication of who the user is, you just want Kratos. OpenID Connect is a separate thing built on top of OAuth 2.0 for authentication, but that’s still giving a third party access to verify who the user is, so if you’re building a first-party app you likely still just want Kratos directly. take a look at this doc and see if it helps - https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/
👍 1
l
Thanks, Andrew. Does Kratos issue JWT's?
n
I’m not certain, we haven’t gotten that far into our Ory build. Their docs should help you set that up if it’s possible.
l
The OpenID Connect specification is confusing me, here it actually says: "This section describes how to *perform authentication using the Authorization Code Flow.*" https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
n
OpenID Connect is an authentication mechanism built on top of OAuth 2.0. Basically, it’s still delegated authorization, but what you’re actually doing is giving the Client authorization to retrieve the User’s identifying information. Then your service can use that information to identify (and authenticate) who the user is. That id_token normally wouldn’t directly be used to make requests to any other service, as it doesn’t represent any kind of authorization to API resources in itself. You would use that id_token to identify a user and generate some other authentication session (like a cookie) that is owned by the service being authenticated against.
What you may want to look into is Oathkeeper, which you can use to convert another authentication type, like cookies, into a JWT id_token internally (following the format of Open ID Connect but not technically an Open ID Connect flow). That way your underlying services can interpret only JWT tokens from Oathkeeper, but you can use multiple authentication mechanisms based on the client type. That’s effectively what we’re doing, and so far it’s working very well to help us migrate from a legacy system to a modern system with multiple client types without our services having to individually know how to interpret every kind of auth mechanism.