Видео

Thanks for your comment! I did not miss the refresh_token, I simply ignored it since this was about an introductory overview of this flow. In addition, there are products that allow the developer to configure if a refresh_token should be issued to its client or not. I still hope it was informative.

Thanks for the question. In my experience you, as a developer, have to know. It usually works like this: configure the type of application (web, sp), then choose the grant_type. Most services share the supported grant_types via the well-known endpoint. For example, this is google: accounts.google.com/.well-known/openid-configuration You will find "grant_types_supported", you can choose one of those. I hope this helps

Hi Matt! The verifier is generated by the client, on the fly, per authorization request. The hacker would have to be able to derive the verifier from the sha-256 hash of it. The chances are basically 0 to achieve that. For example: this is the base64 encoded hash of a short string and the chances of you figuring out what the sentence is ... probably not going to happen: yWIgwAZPNpBFshwG7lIU2KTFntFQKQ+LRebfFZrBiDQ=. This means, whatever verifier the hacker app sends, the server will use it to regenerated the sha-256 hash of it and it will not match the value that was given to the server in the beginning of the authorization flow. I hope this helps!

Thank you for your question. Unfortunately, any possible configuration depends on the product you are using. So, it may not be possible at all. If this type of configuration is important for you, you may need to choose your OAuth server based on that requirement. I hope this helps.

Damn it, yes :-) Thank you

Hi! SHA256 is only true for algorithms that use sha256. And base46url encoding is done on the output of generated hash. Do you think you identified something that should have been explained differently?

I didn't understand at all, sh-256 itself cant be reversed why to do base 64 on hash

@@manideepkumar959 Base64url encoding transforms the hash value into a regular string which can be transferred in an http message

Good catch. Actually the OP explained that part but it is missing. comparing the calculated hash value with signature hash in the token is not enough. There is an encryption and decryption process to verify the signature. It works like this: you have a data and a public/private pair. Data is hashed end encrypted with Private key and the result is a Signature. To verify that if signature is correct: Signature is decrypted with Public key and the result should be the hash value of the data. This is the validation. In the ID token scenario, Issuer creates the signature using its Private key. To validate the signature you have to use the Public key which you can get from the jwks_url. Creating the signature works like Encryption, validating the signature works like Decryption. This detail is missing in the video. (i.stack.imgur.com/B93DO.png)

@@sonyolcu23 Thank you for your comment. But please note that your comment contains a few wrong messages. Private keys are not used for encryption, public keys are not used for decryption as you mentioned it above. The id_token is not encrypted, only signed in this video. Private key -> create signature, public key -> verify signature. No encryption is used in this context. In this video only JWT, JWS (signature) are referenced, not JWE (encryption).

Hi there! Do you have anything specific on your mind?

Thanks for the question. I do not know, but since DPoP is quite new I am assuming it would still be mTLS. However, DPoP is probably simpler to implement.

Thank you

Do you think you can make a video on a topic of common bugs /missed considerations not just on this DPoP topic but other topics you covered so far?

I guess I could that that, yes. Thanks for the idea!

Sounds like it, true 🙂

Hello, thanks for your question. Refresh_token usages are often implemented differently. Some OAuth/ OpenID Connect providers allow multiple usages, some just once. Therefore 'MAY'. If you plan to work against a provider, you need to read their developer documentation. If you plan on implementing a server yourself, I would try the 'once only' approach first. I hope this helps!

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 there! Thanks for watching my video and asking a question. Well, in most cases access_token are issued as JWT these days. That means, the signature can be verified and therefore the authenticity of the token. In addition introspection endpoints are usually available. Wherever Token Exchange is supported authorization servers usually are configured to only accept certain token issuers. It is usually not a blind "let's exchange any token for ours" scenario. Please let me know if this helps.

​@@saschazegermannice answer. Thx

Hi there! Please scroll down and find the second last comment and find my response which answers exactly this question. I hope that helps!

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!

Hi there! Please have a look at this example of the token exchange spec: datatracker.ietf.org/doc/html/rfc8693#section-2.3. To me it sounds very similar to what you are trying to do. The main idea is what you ask for, receive a token of an accepted issuer (Stream) and issue a token for your resource server. Alternatively, you could also look into using id_token_hint. Since you re already supporting authcode with PKCE, you could accept an id_token (basically a JWT) issued by Steam which would be just a small extension to the protocol you already support. I hope this helps!

Hi Jonas! To be honest, your question completely confused me. Until this moment is was cleat to me that token exchange is meant for one client exchanging token for another, different token. If clients change, and they are internal clients that work within an infrastructure, I would say yes. Otherwise, I have to say it depends on the use case and has to be documented well. Sorry that I do not have a better answer for you.

You're welcome, glad you liked it

Hello Kousher! Yes, I did writ ea book: a.co/d/jfDY2BJ The link takes you to amazon.

Hello! Imagine it like this (not completely accurate, but good for understanding the difference): - the authorization_code is delivered to the app like a letter to an apartment building. Imagine a high-rise with 100 apartments but two of those have the same apartment numbers. The letter will end up in one of those two letter boxes. Just like the OS which selects one app having the same redirect_uri. - The token exchange is more like a phone call between two parties. I hope this helps!

Thanks, that really made it clear!

Hello Riza! The difference is that a refresh_token is never exchanged with the resource_server. IT is only used between the issuing authorization_server and the requesting client. Therefore, it is at leas only less party that has access to it. And it cannot be used to retrieve protected data from a resource_server. And yes, access_token lifetimes are usually short. There are cases where they can even only be used once. For example, transferring USD 10.000 to another account, could be such case. I hope this helps, if not, please let me know.

Hello Ajit, thanks for the question. Users have to register again, unfortunately. If users register under 'auth.ajit.com' and you change the domain to 'auth.ajitsingh.com', a new registration is required. I hope this helps!

​@@saschazegermanOkay... but then all my data with my "old" account would be lost? (if my only login method would have been a passkey)

@@unmapped89361 That is correct. That is why all FIDO2 (or Passkey) providers have more than one option to sign into an account and will almost always want you to setup a recovery method for your account. I hope this helps!

Hi there! You do not have to, but it is encouraged, it does no harm. It is just one more tool to keep your application and your users data safe.