วีดีโอ

Hello, and thanks for the question. Generally not, no. As this flow involves a redirect to the login page at the authorization server an API-only message flow does not work. However, there are proprietary solutions that support API based flows but those do not adhere to the RFC. I hope this helps.

Hi there, thanks for your question. 'Official' reasons for not using this grant_type can be found here: datatracker.ietf.org/doc/html/rfc6819#section-4.4.3 In your scenario the library should use an access_token that was granted via an authorization_code flow. That way, users can decide 'yes' or 'no' to requested access. With that, the access_token can also be limited to exactly what the client should be able to view in a users account. If you are the only developer, if all of this is your application, if you are managing users credentials in your own directory, then the usage is not too terrible. However, please refer to that link to get a broader view on potential challenges. I hope this helps.

Oh, and please look at other questions and answers of this video.

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.