-
Hi there, I noticed
I was think of opening PRs for both of these, but I wanted to make sure the project was open to it first. Cheers! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Amazing that you asked first, i would hate to disappoint you if you worked on a PR but had parts of it rejected.
Absolutely, I don't see a reason why not. but given that
Not natively no, there's too much risk involved in it to have it exposed natively. But also, there's already a native function built in that you can wrap around with minimal code to achieve it. import { createRemoteJWKSet } from 'jose/jwks/remote'
import { jwtVerify } from 'jose/jwt/verify'
const cache = new Map(); // replace with lru-cache?
const memoize = (jku) => {
if (!cache.has(jku)) {
cache.set(jku, createRemoteJWKSet(new URL(jku)))
}
return cache.get(jku);
}
function jkuJWKS(...args) {
const { jku } = args[0]
if (!jku || !allowed(jku)) {
// error?
}
return memoize(jku)(...args)
}
const { payload, protectedHeader } = await jwtVerify(jwt, jkuJWKS, {
issuer: 'urn:example:issuer',
audience: 'urn:example:audience'
}) |
Beta Was this translation helpful? Give feedback.
Amazing that you asked first, i would hate to disappoint you if you worked on a PR but had parts of it rejected.
Absolutely, I don't see a reason why not. but given that
JWSHeaderParameters
andJWEHeaderParameters
both have indexable string properties I don't think it's strictly necessary. I don't mind it tho.Not natively no, there's too much risk involved in it to have it exposed natively. But also, there's already a native function built in th…