at 9:45, yes the token is digitally signed, but only the Authorization server can verify if the signature is correct, the client can't make that verification.
Hi there! These days JWT are typically signed with private keys. Any party that has access to the public key can verify the signature. Generally, authorization servers provide the /jwks endpoint which allows the recipient of a JWT to retrieve the public key and verify the signature. Therefore, the client can also verify it. I hope this helps
Hi, thanks for the explanation. One thing that I didn't understand yet is how an API server can know that the access-token sent by a client's request header is valid. It should authenticate itself into the same identity provider?
Hello Cristiano! There are a couple of things to consider. 1) if the access_token is a 'bearer' token it can be used by anyone who is in possession of it! This will be different if a 'proof-of-possession' flow is used but today that is usually not the case. 2) the resource server either has to call the authorization servers introspection endpoint to find out if the token is valid. Or, 3) if the token is expressed as JWT is may validate it directly, on the spot, by checking the signature and the included claims such as 'exp' (expiration), scope, issuer. In my video on refresh_token I touched on that validation topic. Please have a look and let me know if that helps. Thank you!
@@saschazegerman Hey Sascha, a bit old this thread but I hope you still see the comment. I have a clarifing question regarding 3) when using a JWT. The RS can validate the JWT on the spot, but it would still need access to the public key, meaning calling an endpoint (like penid-connect/certs with key cloak?) and cannot do it directly or otherwise the secret would have been hardcoded. But there is no option, the RS can validate the JWT on the spot and deducing the key from the process so far?!? Thanks for clarifying this :)
@@tims.7538 Hi Tim, thanks for your question. Yes, the option of retrieving the public key via an endpoint is the default. In OIDC it would be the /jwks endpoint. Nevertheless, the JWT header can also include the public key. Please have a look at this rfc and look for headers named 'x5...'. : www.rfc-editor.org/rfc/rfc7515#section-4.1 You will find that certificate chains can be included. Your JWT validating service then has to check if it trusts the certificate chain and, if so, can avoid the call to an external endpoint. Another option is to retrieve the public key and refresh it only from time to time. I hope that helps.
You passed 'openid email profile' in the request when obtaining the Id token. Does this mean when you decode the Id token, you will see the users email as a claim?
Hello! By OIDC spec. you do not get claims in id_token. Your client would receive email via a request to the /userinfo endpoint. However, you will find many implementations that do include claims in id_token, which means you have to read the documentation of the OIDC provider of your choice. I hope that helps!
Thank you! A very good explanation to begin to learn about OpenID
I kid you not, Sascha, you are BRILLIANT!!!!!
Very informative, but still looking forward to see more explanation or extension on OIDC...👌
Great Content. Thanks for making these videos, I really appreciate it. Looking forward for more.
rdfrrtytt
excellet video on such a complex topic .... loved it
at 9:45, yes the token is digitally signed, but only the Authorization server can verify if the signature is correct, the client can't make that verification.
Hi there! These days JWT are typically signed with private keys. Any party that has access to the public key can verify the signature. Generally, authorization servers provide the /jwks endpoint which allows the recipient of a JWT to retrieve the public key and verify the signature. Therefore, the client can also verify it. I hope this helps
Great video thanks Sascha!
Very informative 👌
Nice content about openid connect
Hi, thanks for the explanation.
One thing that I didn't understand yet is how an API server can know that the access-token sent by a client's request header is valid. It should authenticate itself into the same identity provider?
Hello Cristiano! There are a couple of things to consider. 1) if the access_token is a 'bearer' token it can be used by anyone who is in possession of it! This will be different if a 'proof-of-possession' flow is used but today that is usually not the case. 2) the resource server either has to call the authorization servers introspection endpoint to find out if the token is valid. Or, 3) if the token is expressed as JWT is may validate it directly, on the spot, by checking the signature and the included claims such as 'exp' (expiration), scope, issuer. In my video on refresh_token I touched on that validation topic. Please have a look and let me know if that helps. Thank you!
@@saschazegerman, thanks. I'll watch the reccomended video.
@@saschazegerman Hey Sascha, a bit old this thread but I hope you still see the comment. I have a clarifing question regarding 3) when using a JWT. The RS can validate the JWT on the spot, but it would still need access to the public key, meaning calling an endpoint (like penid-connect/certs with key cloak?) and cannot do it directly or otherwise the secret would have been hardcoded. But there is no option, the RS can validate the JWT on the spot and deducing the key from the process so far?!? Thanks for clarifying this :)
@@tims.7538 Hi Tim, thanks for your question. Yes, the option of retrieving the public key via an endpoint is the default. In OIDC it would be the /jwks endpoint. Nevertheless, the JWT header can also include the public key. Please have a look at this rfc and look for headers named 'x5...'. :
www.rfc-editor.org/rfc/rfc7515#section-4.1
You will find that certificate chains can be included. Your JWT validating service then has to check if it trusts the certificate chain and, if so, can avoid the call to an external endpoint. Another option is to retrieve the public key and refresh it only from time to time. I hope that helps.
You passed 'openid email profile' in the request when obtaining the Id token. Does this mean when you decode the Id token, you will see the users email as a claim?
Hello! By OIDC spec. you do not get claims in id_token. Your client would receive email via a request to the /userinfo endpoint. However, you will find many implementations that do include claims in id_token, which means you have to read the documentation of the OIDC provider of your choice. I hope that helps!
Love your videos 📹
Good one
Sir, did you write any book on this topics, if yes could you please share the link ?
Hello Kousher! Yes, I did writ ea book: a.co/d/jfDY2BJ The link takes you to amazon.
Great content for he beginner
u should have given some more examples of open id
Hi there! Do you have anything specific on your mind?
Really good Sascha, thank you!