Subject type of an OAuth token

Hi everyone,

In our stack we use hydra, oathkeeper and keto. I’ve configured oathkeeper to pass the subject of the request to our API and then I use it as the user ID in our services. This works well for the authorization code grant and the implicit grant but the problem is that now, I would like to implement the client credentials flow in our API. Obviously hydra already handles this mechanism but the problem I have is that the subject I get is now a client id (and not a user id).

So my question is, is there a way to know if a token represent a user or an application ?

If there is not, do you think that adding a field nammed subject_type in the introspection response would be a good idea ?

Thank you in advance for your answers

No there is not, I guess what you want is some type of Service Account or Account Impersonation feature?

We will probably do something like this in the end but for now I found that way too complicated for the size of our API.

I was planning to detect if the token represent an application (hence my question) and then use the owner of the application as the subject of the query.

Ok, I would however be very careful when implementing it like so, because the client does not usually act on the owner’s behalf but on it’s own! If you however have that in mind whenever you do implement this it should be ok.

As said our API is quite simple for the moment, I think it should be ok. We will implement a stronger mechanism (probably service account) later.

So since there is no way for determining the subject type of a token, do you think adding a subject_type in the introspection answer would be a good idea ?
If needed I could be up for developing the feature for hydra (and updating the authenticator in oathkeeper for storing the value in the session context)

Edit: Getting this value in the introspection (and consequently in oathkeeper) could be helpful to create special permissions with keto

That would be very uncommon and quite bespoke for your use case. Since you have access to the access token payload for regular users, why don’t you take the absence of a specific field as an indicator for what the token expresses in your system?

What do you mean by “access token payload” ? I’m not using jwt if this is what you are saying.

The stuff you set with session.access_token when accepting a consent request

Ok nice, I’m gonna try that


Can’t you simply check if client_id and sub claim are equal in the introspect response?

That could work also

In the end, that’s what I’ve done.
And for integrating everything correctly with oathkeeper I used an hydrator

I dont get that, i think they always are equal, can u explain that case for me ? tks in advance

so you used a hydrator to get user id and then check with keto ? i have same case with you

For any request my hydrator is called, then there are few different cases:
Either the subject is “anonymous”, in this case I just forward the request and set an extra variable to the subect
Either the subject is different from the client_id, in this case I also forward the request and set an extra variable to the current subject
Either the subject is equal to the client_id, in that case, I request hydra to return me the oauth client (using the client_id) and then I set the extra variable to the field “Owner” of the oauth client

After that, with oathkeeper, I use a header mutator to forward my extra variable to my micro-services

1 Like

tks for answering me, i have one more question, as i know hydrator hasnt been implemented, what’s version you use now ? i mean the one has hydrator step before authorization

Hi, sorry I did not see your reply

As far as I know we are using the latest version of keto and in the version we use the hydration is after the authentication

can you give me version of oathkeeper which you used ? current release of oathkeeper doesnt have hydration between authentication and authorization

My bad, I made a mistake. I was talking of oathkeeper in my previous message.

I finally achieved to find the version number: ORY Oathkeeper v0.38.3-beta.1

1 Like

Thanks, can you show me your configuration of hydration and rules ?