3
Asymmetric cryptography
Source: supabase/supabase#29286 · opened by @JungeWerther
As far as I understand, if I want to verify the validity of JWT claims, I need to validate their signature against the original signing secret.
Now let's say I want to use different microservices to interact with my database on behalf of my users. The beauty of JWT is that, in principle, I wouldn't have to make a separate call to the the auth server for every back-end request, because I can validate tokens on-site.
However, this means I'd have to distribute the original signing secret across microservices, which means that if only one of them would get compromised, an attacker could impersonate the identity of all my users.
Is there some way to configure the use of asymmetric cryptographic algorithms for verifying the validity of supabase-issued JWTs, where if leaked, those keys could not be used to issue new JWTs?
Now let's say I want to use different microservices to interact with my database on behalf of my users. The beauty of JWT is that, in principle, I wouldn't have to make a separate call to the the auth server for every back-end request, because I can validate tokens on-site.
However, this means I'd have to distribute the original signing secret across microservices, which means that if only one of them would get compromised, an attacker could impersonate the identity of all my users.
Is there some way to configure the use of asymmetric cryptographic algorithms for verifying the validity of supabase-issued JWTs, where if leaked, those keys could not be used to issue new JWTs?
No pledges yet. Be the first to back this.
No comments yet.