OpenID Connect - Basics
Вставка
- Опубліковано 8 лип 2024
- This video provides a very first step into OpenID Connect. It covers basics only and explains the main difference to OAuth 2.0. This should be helpful to anyone who is new to this topic.
OpenID Connect is generally needed as soon as an application should not only have access to a protected resources but should also know about the current user (resource_owner).
Links to start reading about it:
- openid.net/connect // this is the location of the spec.
- client.loginbuddy.net // the demo client of my open source project 'Loginbuddy' which can be used to see the content of an OpenID connect provider response
Thank you! A very good explanation to begin to learn about OpenID
Really good Sascha, thank you!
excellet video on such a complex topic .... loved it
Great video thanks Sascha!
Great Content. Thanks for making these videos, I really appreciate it. Looking forward for more.
rdfrrtytt
Very informative, but still looking forward to see more explanation or extension on OIDC...👌
Very informative 👌
I kid you not, Sascha, you are BRILLIANT!!!!!
Love your videos 📹
Nice content about openid connect
Great content for he beginner
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
Good one
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.
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.
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!
u should have given some more examples of open id
Hi there! Do you have anything specific on your mind?