https://supertokens.com/ logo
Join Discord
Powered by
Im looking at useing the JWT service as a means to...
# support-questions-legacy
p
Im looking at useing the JWT service as a means to generate short lived JWT tokens to be used between services. The documentation seems to suggest that every call to Jwt.createJWT involes an http request to the supertokens core is that right?
r
Hey @pitchash that is correct.
p
hmm.. maybe this isnt the way togo for us then.. maybe we will just use our own jwt;s signed locally
r
Fair enough. May I ask what’s the downside for this?
p
it would be a lot of outbound api calls
so short lived jwt to access a resource on a seperate service..
so every request to access a respource would require a new jwt.. so an outbound api call.. will slow our requests down etc
r
I see. But if you have several services creating JWTs, then they would need to query some place to get their jwts?
The only way you avoid having network calls is if you hardcode the same private keys in all the services
p
not really..
you can use the pulic endpoint for each service to fetch the cert once on startup
and the signer generates a new cert each time it starts..
so creating each jwt should not require a an api call
r
So each service would fetch the private keys on startup essential?
p
no, each sercice generates its own cert locally on start up
then other services query the public cert of the other services
r
Right. But for a service to actually trust a JWT, it needs to know that some trusted source has created it.
p
i wouldnt mind an outbound call on start up to generate / fetch the private cert from suypertokens..
i just dont want to do that every single time we dreate a new jwt
r
But if the JWT is created from the same service that is requesting a resource, then it’s not really trusted?
p
the url the child service uses to fetch the public cert can be hardcoded
r
So you are essentially enforcing that only a certain set of microservices can query each other microservice?
p
yes i guess so
i have a primary service where the user logs in..
this service handles permissons etc.. so creates tokens to be used by the others services that contain properties to limit access to specific resources
the child services need to verify the token.. and use a hardcoded url to get the public key
so.. the primary service is frewuently creating short lived tokens to enable access to certain resources on the child services
but with supertokens as it is now.. every single time it wants to sign a jwt.. its an outbound http call to super tokens... rather thann just signing it with a private key obtinated from supertokens on startuip
and these tokens will also be created in its own api request handler.. so slowing down the request responses
the pattern could be seen as something like an AWS signed url to a resource on s3 for exampe.. so we want to generate a short lived "signed url" to a resource on another service
I was looking at the supertokens JWT recipe to see if it was appropriate.. but I dont think it is if we are going to make this outbound http request every time
r
Makes sense!!
Thanks for the info.
p
one more question... on the superoken solution.. the other services that need to verify jwts dont need to integrate super tokens correct?
only services creating jwts need to integrate?
r
They don’t.
They just call the jwks endpoint exposed by the backend SDK that integrates with supertokens
p
and that jwks endpoint returns a cached copy of the public token that the sdk obtains from super tokens when it expires etc?
or does every inbound http request to {apiDomain}/{apiBasePath}/jwt/jwks.json result in another outbound request to supertokens too?
r
it sends a request to the core, but the caching part is supposed to be done by the service that's calling the jwks endpoint (which is done by jwt verification libs)
p
Copy code
import JsonWebToken, { JwtHeader, SigningKeyCallback } from 'jsonwebtoken';import jwksClient from 'jwks-rsa';var client = jwksClient({  jwksUri: '{apiDomain}/{apiBasePath}/jwt/jwks.json'});function getKey(header: JwtHeader, callback: SigningKeyCallback) {  client.getSigningKey(header.kid, function (err, key) {    var signingKey = key!.getPublicKey();    callback(err, signingKey);  });}let jwt = "...";JsonWebToken.verify(jwt, getKey, {}, function (err, decoded) {  let decodedJWT = decoded;  // Use JWT});
in the example code above (from the doc) is the caching done by jwksClient ?
r
can you please reformat it?
p
or would we need to add aching ourselvs?
r
jwksClient -> should do the caching
p
ok.. docs on jwksClient looks like caching isnt enabled by default.. so code on the supertokens example wont cache i think... but its clear whats happening thnks
i think there are benefits to using the supertokens jwt solution for traffice bwteen our sevices... but for the fine grained resource permissions I think we need an additional permissons token as a query parameter so we dont have to keep regenerating the jwts
5 Views
PreviousNext
Powered by