FSince opaque tokens are an opaque string you have not alternative then to call an endpoint in zitadels api to verify them or to request data.
However in your case would it not make sense to use a JWT and then verify the signature? This gets rid of the additional round trip and you can still verify the token against zitadel on privileged operations like deletes or so
However in your case would it not make sense to use a JWT and then verify the signature? This gets rid of the additional round trip and you can still verify the token against zitadel on privileged operations like deletes or so
FHm I think that should work just fine 
We usually tend to recommend opauqe tokens over jwt because it takes some of the mental overload out of the equation since they are a little more secure by default
We usually tend to recommend opauqe tokens over jwt because it takes some of the mental overload out of the equation since they are a little more secure by default
F1) Sort of, we have optimized read models to have fast queries and rely on the DB cache
1a)... we are talking about introducing a fast shared cache in zitadel like redis but that is not yet decided
2) Not ATM, but if you reach that amount of traffic we should talk... usually our storage format is relatively efficient.
1a)... we are talking about introducing a fast shared cache in zitadel like redis but that is not yet decided
2) Not ATM, but if you reach that amount of traffic we should talk... usually our storage format is relatively efficient.