loadCryptoKeyFunction, jwksClient on clerk-sdk-node addition and fixes #2
Conversation
fix: Revisit middleware and instance tests, deepmerge fetcher options
igneel64
force-pushed
the
load_pk_injected_method
branch
from
d1ea736 to
637b854
Compare
| "@peculiar/webcrypto": "^1.2.3", | ||
| "camelcase-keys": "^6.2.2", | ||
| "cookies": "^0.8.0", | ||
| "deepmerge": "^4.2.2", |
There was a problem hiding this comment.
This was introduced as a fix for merging supplied httpOptions.
| expect(allowlistIdentifiers2).toBe(allowlistIdentifiers); | ||
| }); | ||
|
|
||
| test('clients getter returns a Client API instance', () => { |
There was a problem hiding this comment.
These tests about instance types seemed superficial. If anyone has an objection we can restore them.
| importKeyFunction: ImportKeyFunction; | ||
| verifySignatureFunction: VerifySignatureFunction; | ||
| decodeBase64Function: DecodeBase64Function; | ||
| loadCryptoKeyFunction?: LoadCryptoKeyFunction; |
There was a problem hiding this comment.
❓ What's the difference between the loadCryptoKeyFunction and the importKeyFunction?
There was a problem hiding this comment.
Their docs:
@param {ImportKeyFunction} importKeyFunction Function to import a PEM. Should have a similar result to crypto.subtle.importKey
@param {LoadCryptoKeyFunction} loadCryptoKeyFunction Function load a PK CryptoKey from the host environment. Used for JWK clients etc.Their difference is not so easily discernable for readers not familiar with the crypto operations we need to use for our jwt verification.
import is a reserved term coined as input a key in an external, portable format and take back a CryptoKey.
load does not have any special terminology like that and would allow injecting any kind of process that the client (of @clerk/backend-core) needs to do to provide a CryptoKey from his PK.
| status: AuthStatus; | ||
| session?: Session; | ||
| interstitial?: string; | ||
| sessionClaims?: JWTPayload; |
There was a problem hiding this comment.
🔧 I will suggest to create a custom type for this, which will include the session ID and user ID for now and not depend on the JWT payload
| 'raw', | ||
| encoder.encode( | ||
| ( | ||
| await jwksClient.getSigningKey(decoded.header.kid) |
There was a problem hiding this comment.
❓ What will happen if we can't find a key with the provided kid? Will it throw a descriptive error?
igneel64
force-pushed
the
load_pk_injected_method
branch
from
b7d555d to
7699fa9
Compare
Additions
Notes
As discussed with @chanioxaris . We chose here to pass the public key as a CryptoKey from any external function like
loadCryptoKey.That is because there were a few issues with public key parsing etc.
As a next step or an alternative, we can use the
loadCryptoKeyasloadPublicKeyand just return a public key as a string.