Fantastic explanations, Aaron!! Thank you very much. They were extremely helpful and I appreciate you took the time to review the jargon and still simplify the language during the explanation.
Awesome presentation - I really understood all those OAuth headlines from 2017 better now! However, was there something cut at the @22:25 mark? Seems to jump ahead and missed his intro to the View As feature...
"Facebook had this great feature called 'View As'. You could be on your profile page and click View As and see what your profile looked like to someone else." was the sentence missing from the edit
As of today this only has 25k views. That seems on par to a war crime. Great video and the editing was done fairly well. The cut that was done toward the end was terrible however.
I admire your work. Explaining all these concepts in just 25 minutes is remarkable. Thank you. I still have a question. How does PKCE solve the problem of impersonating a client? There is no secret but the client_id is still public. What stops me from stealing the client_id, generating my own secret, hashing it, and building an URL that I can send to the user presenting myself as the client whose client_id I just stole? How does the OAuth server know that the randomly generated hash secret that comes in pair with a particular client_id is actually coming from the client who owns this client_id?
Thanks! PKCE doesn't claim to solve that problem, client impersonation is a different problem. What PKCE does is ensures that the particular client that makes the request to the token endpoint is the same one that made the first request to the authorization endpoint. Client impersonation is a difficult problem to solve, and right now most things in the wild rely on the fact that it's relatively hard to take over a redirect URL on someone's phone and also get them to start a flow in the attacker's app.
@@aaronpk Thanks for clarifying the answer to that question. This is something I have been trying to get a solid answer on for some time now and I did not see how PKCE could help this case. I think I may have been previously misinterpreting claims on the purpose of PKCE. It's confusing to me because in your video at 9:20, you explain that the result of the Twitter hack was that anybody could impersonate the Twitter app, and how this hack was a major problem with OAuth 1 and a huge motivator to develop OAuth2. Yet it seems that OAuth2 (or PKCE) does not claim to mitigate this problem? I am still confused :)
@@Tomsta17 It's confusing! So the core problem with OAuth 1 was that everything about it relied on the assumption that the application would be deployed with its own secret. As soon as you try to do that with native apps, the secret isn't secret anymore, so it just breaks down completely. What OAuth 2 did was recognize that some apps don't have the ability to keep a secret, and stops pretending like they can. So while OAuth 2 doesn't solve the app impersonation problem completely, it makes it so that you're aware of the problem and provides guidance on other ways to avoid the issue, primarily using app-claimed HTTPS URLs. But indeed, PKCE has nothing to do with app impersonation, instead it solves other problems even if the app does have its own secret.
@@aaronpk Now THAT makes sense :) I was still under the impression that PKCE was somehow trying to "Fix problem A", but instead, all we are now doing is saying: "Problem A is still a problem and will always be a problem (Until we have magic secure client secret storage). But you should know about Problem A, and stop relying on it. Find another way". Kinda? That really changes my outlook, so thanks. And thanks for the speedy response!
Around 10:00 to 10:10: Why don't users have access to the source code of web based apps? It's JavaScript files which can be downloaded using tools like wget or inspect it on the fly using the developer tools provided by browsers.
That should have been specifically web-*server* based apps, like the traditional way of developing apps before SPAs became popular... server-side languages like .NET, Java, PHP, etc.
I'm not confirming anything right now as I'm still learning but I've made a first test of Google oauth2 connection through a ReactJS SPA and I've been able to get data from Google and client secret isn't even mentioned in source files, only client id. It's the Google auth server who will check for this. I may say mistakes as I'm still learning
Not happy with your analogy. I get that the front desk is the Authorization Server, but who's the Resource Owner? Is it "me"? It seems like "me" is the client, not the RO. Where does the RO get to express their consent to the transaction? No, definitely not happy with this analogy--just seems to muddy the waters even more. It's been two weeks, and I'm still confused. Like the rest of the vid though. Thanks
You're right that this analogy doesn't have a good way to distinguish between the resource owner and the client, but "you" as the hotel guest are playing both roles. Consent is only one aspect of the OAuth flow and also isn't really represented here. The main thing this analogy shows is how access tokens are like a hotel key, issued by the front desk (authorization server) and read/consumed by the doors (resources), and that only the front desk and the door need to know how they work.
please don't read and ignore. I didn't even understand anything ... But I'm familiar with the terms . Who is going to train me on this field. I'm willing to put in the time ...
Your OAuth analogies in the beginning are really, really helpful!
All thanks to expeditetools com i received a hacked transfer of $34,000 .They are awesome.
This is the most informative video on OAuth I've ever seen, from the authoritative source. Well done.
i usually don't comment. But this video i can't resist . Amazing explanation. Too good. Thanks for lighting the path...
Fantastic explanations, Aaron!! Thank you very much. They were extremely helpful and I appreciate you took the time to review the jargon and still simplify the language during the explanation.
After watching this video, I am not the same person anymore. Thank you.
Awesome presentation - I really understood all those OAuth headlines from 2017 better now!
However, was there something cut at the @22:25 mark? Seems to jump ahead and missed his intro to the View As feature...
oh no, you're right! I'm not sure how that got lost! It was supposed to be an explanation of the "View As" feature!
"Facebook had this great feature called 'View As'. You could be on your profile page and click View As and see what your profile looked like to someone else." was the sentence missing from the edit
Thanks for filling in that missing piece! (and quickly)
Can you please define what is the back channel and front channel? I can't find them online.
That was super interesting!!! Thank you!!
Glad you enjoyed it!
As of today this only has 25k views. That seems on par to a war crime. Great video and the editing was done fairly well. The cut that was done toward the end was terrible however.
Hello, can you explain more about ''Front channel benefits: application without public ip can receive data''
Thank you!!
Wonderful Explanation. Thanks for taking time and explaining this.
Thanks for this easy to understand explanation.
ive recreated it but I dont figure out how to acess there account need help i mean how to connect my acc with theres
How do you know if aomeone has oauth?
Supercool presentation!!
It's a really good video.
Also, bought your Udemy course.
I think I'm gonna learn a lot from you :)
I admire your work. Explaining all these concepts in just 25 minutes is remarkable. Thank you.
I still have a question. How does PKCE solve the problem of impersonating a client? There is no secret but the client_id is still public. What stops me from stealing the client_id, generating my own secret, hashing it, and building an URL that I can send to the user presenting myself as the client whose client_id I just stole? How does the OAuth server know that the randomly generated hash secret that comes in pair with a particular client_id is actually coming from the client who owns this client_id?
Thanks! PKCE doesn't claim to solve that problem, client impersonation is a different problem. What PKCE does is ensures that the particular client that makes the request to the token endpoint is the same one that made the first request to the authorization endpoint. Client impersonation is a difficult problem to solve, and right now most things in the wild rely on the fact that it's relatively hard to take over a redirect URL on someone's phone and also get them to start a flow in the attacker's app.
@@aaronpk Thank you. I appreciate the fast response :).
@@aaronpk Thanks for clarifying the answer to that question. This is something I have been trying to get a solid answer on for some time now and I did not see how PKCE could help this case.
I think I may have been previously misinterpreting claims on the purpose of PKCE.
It's confusing to me because in your video at 9:20, you explain that the result of the Twitter hack was that anybody could impersonate the Twitter app, and how this hack was a major problem with OAuth 1 and a huge motivator to develop OAuth2.
Yet it seems that OAuth2 (or PKCE) does not claim to mitigate this problem?
I am still confused :)
@@Tomsta17 It's confusing! So the core problem with OAuth 1 was that everything about it relied on the assumption that the application would be deployed with its own secret. As soon as you try to do that with native apps, the secret isn't secret anymore, so it just breaks down completely. What OAuth 2 did was recognize that some apps don't have the ability to keep a secret, and stops pretending like they can. So while OAuth 2 doesn't solve the app impersonation problem completely, it makes it so that you're aware of the problem and provides guidance on other ways to avoid the issue, primarily using app-claimed HTTPS URLs.
But indeed, PKCE has nothing to do with app impersonation, instead it solves other problems even if the app does have its own secret.
@@aaronpk Now THAT makes sense :)
I was still under the impression that PKCE was somehow trying to "Fix problem A", but instead, all we are now doing is saying:
"Problem A is still a problem and will always be a problem (Until we have magic secure client secret storage). But you should know about Problem A, and stop relying on it. Find another way".
Kinda?
That really changes my outlook, so thanks.
And thanks for the speedy response!
Around 10:00 to 10:10: Why don't users have access to the source code of web based apps? It's JavaScript files which can be downloaded using tools like wget or inspect it on the fly using the developer tools provided by browsers.
That should have been specifically web-*server* based apps, like the traditional way of developing apps before SPAs became popular... server-side languages like .NET, Java, PHP, etc.
@@aaronpk Ah, so its the server calling to the other server, I see. :-)
I'm not confirming anything right now as I'm still learning but I've made a first test of Google oauth2 connection through a ReactJS SPA and I've been able to get data from Google and client secret isn't even mentioned in source files, only client id. It's the Google auth server who will check for this.
I may say mistakes as I'm still learning
great explanation!! Thanks a lot.
Great explanation
I love your T-shirt
Great content AND def not for the uninitiated (at least not in a 25 minute video).
Splendid !
Thank you for this explanation. Clear and easy to understand!
. I. Ziemlich z ??.?? ?I ended this?
amazing content
I just realize that thanks to hackers we might get improvements in any computer related applications, and this happens all the time.
Not happy with your analogy. I get that the front desk is the Authorization Server, but who's the Resource Owner? Is it "me"? It seems like "me" is the client, not the RO. Where does the RO get to express their consent to the transaction? No, definitely not happy with this analogy--just seems to muddy the waters even more. It's been two weeks, and I'm still confused.
Like the rest of the vid though. Thanks
You're right that this analogy doesn't have a good way to distinguish between the resource owner and the client, but "you" as the hotel guest are playing both roles. Consent is only one aspect of the OAuth flow and also isn't really represented here. The main thing this analogy shows is how access tokens are like a hotel key, issued by the front desk (authorization server) and read/consumed by the doors (resources), and that only the front desk and the door need to know how they work.
Great video, I would like it but I like the number its at (666)
Super!!!
please don't read and ignore. I didn't even understand anything ... But I'm familiar with the terms . Who is going to train me on this field. I'm willing to put in the time ...
awesome
glich me do sea huge festive cat litle to my best pet