I understood everything before JOSE, so could you please explain with an example how with the help of node jose library you generate the cek, kid, public and private key set etc etc and then use it to encrypt the message and then decrypt it later on. With current video its bit confusing as random fancy words are just appearing on the screen :D
First of all, fantastic talk! Second, when decrypting the JWE, can I confirm that the private key is in the header? It seem insecure then? Anyone who gets hold of the JWE can decrypt it? Did I miss something?
A bit late here - but no, the private key is always completely private and securely stored on the server. The header has three fields the "type" (typ), the algorithm used (alg) and optionally the key ID (kid). This is because sometimes the OAuth/OIDC server will use several public/private keys at the same time, different keys for signing and encryption, and the keys will periodically get refreshed too - so this is a way to know which of the public keys to use to validate the JWT was signed by the corresponding private key. OAuth has an API endpoint called "/introspection" where a client can send a JWT to validate it was signed by the private key with the keyid (kid) in the header. In OIDC this has been deprecated in favour of publishing a list of well known JWKs (JSON Web Key) with all the public keys and key IDs being currently used. This was the client (resource server trying to access the API for) can download and cache the public key for that key id. and validate "was the JWT signed by the private key for this public key.
Definitely one of my favorite talks so far
I understood everything before JOSE, so could you please explain with an example how with the help of node jose library you generate the cek, kid, public and private key set etc etc and then use it to encrypt the message and then decrypt it later on. With current video its bit confusing as random fancy words are just appearing on the screen :D
could anyone show how to do this ?
First of all, fantastic talk!
Second, when decrypting the JWE, can I confirm that the private key is in the header?
It seem insecure then? Anyone who gets hold of the JWE can decrypt it?
Did I miss something?
A bit late here - but no, the private key is always completely private and securely stored on the server. The header has three fields the "type" (typ), the algorithm used (alg) and optionally the key ID (kid). This is because sometimes the OAuth/OIDC server will use several public/private keys at the same time, different keys for signing and encryption, and the keys will periodically get refreshed too - so this is a way to know which of the public keys to use to validate the JWT was signed by the corresponding private key. OAuth has an API endpoint called "/introspection" where a client can send a JWT to validate it was signed by the private key with the keyid (kid) in the header. In OIDC this has been deprecated in favour of publishing a list of well known JWKs (JSON Web Key) with all the public keys and key IDs being currently used. This was the client (resource server trying to access the API for) can download and cache the public key for that key id. and validate "was the JWT signed by the private key for this public key.
@@mitchynz Thank you for your reply! What you wrote makes sense.
Also, no worries on the lateness of reply :)
@@mitchynz thanks for the knowledge.
This was excelent, thank you !!
Great session
who'd have thought Joaquin Phoenix was a programmer too!
Best video!
you've made my day
thank you