Can we issue a new token without adding a row to hydra_oauth2_access table?

[AleksanderBrzozowski]

Hi, we use ORY Hydra in our company to generate JWT tokens. We don't use revocation functionality of ORY Hydra, and we validate tokens outside ORY Hydra instance - we have our own service that uses ORY Hydra JWKS to validate the token.

We wonder if it is possible to generate a new JWT token with ORY Hydra without making changes in the database? I saw that whenever a new token is generated, a new row is added to hydra_oauth2_access table. I assume that it is later used to inspect the token, for example to check if it's active. Since we don't need this functionality, I thought that maybe it is possible to omit writing to this table. With such feature, we would be able to generate tokens using read only database access.

[vinckr]

Hello @AleksanderBrzozowski

I have not done anything like this yet, but I think yes it should be possible to omit that table.
Feel free to do some testing and come back to this with your results.

It's worth noting that by default, Ory issues opaque access tokens, which are random strings with a cryptographic signature that have no meaning or structure. These tokens are stored in a database, and their validity is checked by performing a database lookup. JWTs, on the other hand, are self-contained and do not require a database lookup to validate. Instead, JWTs contain a signature that can be verified to ensure that the token has not been tampered with -> source.

[AleksanderBrzozowski]

@vinckr Yeah, I am going to try it :)

I wonder what happens if we agree that storing token in this table is not required? Do we want to change this behavior in Hydra for JWT tokens?

[vinckr]

Do we want to change this behavior in Hydra for JWT tokens?

To be honest that is above my understanding of Hydra database performance. It might be a great addition, or something undesirable for a reason.

be able to generate tokens using read only database access

Can you explain a bit more on why this is a beneficial thing, or why this is something that would be useful for the broader Hydra developer community?

[AleksanderBrzozowski]

@vinckr Yeah, of course 🙂

Basically, we only use Hydra to store Oauth2 clients and issue JWT tokens, and we only allow for client credentials flow.

Based on that, there are only two tables that we utilize - the one that stores client data (client id + encrypted secret + supported flow etc.) and hydra_oauth2_access table that stores generated tokens.

The problem that we face right now is that it is impossible to deploy Hydra in multiple geographic regions, because of the SQL database which is centralized. Actually, the problem is related to generating the tokens, this operation should be as quick as possible and since every time we need to store the token in database, it is problematic.

So, I was thinking that if we stop saving JWT tokens in the database, it should be possible to have multiple read-only SQL replicas in different geo locations that we can use to issue new tokens, and one master SQL replica that would be used to manage clients data.

[vinckr]

@AleksanderBrzozowski
I see. Multi-region / worldwide geolocation is a pretty hard problem.
We spent a lot of time and effort building such a system for Ory Network, have you looked into that?
I think multi-region is not in the scope of the open source project; but you could open a design document with your proposed implementation