Using Hydra in "micro service" env

ORY Hydra
#1

Suppose we have a client application accessing a resource server (service A) with access token.
Service A validates the token against Hydra via introspection api and get the information about the authenticated user.
Suppose service A doesn’t have all the information it needs to respond to the client, it then need to call service B to get additional data.
Service A would call B’s api with the user’s access token but then service B will need to check Hydra as well. This is obviously a waste…

I know Oathkeeper aims to solve this issue as being the gateway to the internal system and translate the opaque access token to a readble/verifyiable jwt that inner services can consume.
But assuming we are not ready to integrate with Oathkeeper yet (will require considerable amount of work) is there a nice way to solve this ?

We could possibly ask the client to additionally pass the id token, but I think we will still have to verify the access token additionally.

Thanks

#2

That’s really up to you, your system, and your security model. There are different designs (sidecar, gateway, middleware, trusted subnet, …) that work in different scenarios. I fear that figuring this out for your specific use case is out of scope of this forum :frowning:

#3

I thought about using the id token as some sort if identity that can be passed around between services while roaming the inner network.

Will do some more investigation
Thanks :slight_smile:

#4

The ID Token is primarily for third parties, not so much for internal systems. You should rely on access tokens here :slight_smile:

No problem, any time!

1 Like
#5

Going over the Oathkeeper docs, one example for credential issuer is the id_token issuer that terminates the OAuth access token and issues an ID token for upstream apis.

Isn’t it what I suggested basically ?
:wink:

#6

Right, it depends on context! In OpenID Connect, the context of the ID Token is one for the relying party (RP). The relying party is the client that initiates the OpenID Connect request - not the resource server!

In the context of IAPs, the ID Token is one way of transmitting authentication information within your service infrastructure. The ID Token makes sense here, because it’s well defined, but it could obviously also be a SAML assertion or whatever. But it’s not the ID Token from OpenID Connect!

1 Like
#7

I think I understand
This sentence confused me:

This credentials issuer takes the authentication information (e.g. subject ID) and transforms it to a signed JSON Web Token, and more specifically to an OpenID Connect ID Token.

I thought it uses the same ID token as the the RP would have got from Hydra.
So you’re saying it just uses the same format, but the issuer here is not Hydra but Oathkeeper the IAP ?

#8

I can totally see why that is confusing, the docs have been updated so this isn’t as confusing for the next reader, hopefully :slight_smile:

1 Like