OAuth: When Things Go Wrong

[@AidPast]

EXCELLENT preso. Every product security engineer should watch this!

[@KDOERAK]

I learned a lot by watching this video; my time was well spent - thx!

[@luismesquita6528]

Wow such a cool presentation, many thanks. The best way to have a deeper knowlodge on a concept is when we understand it's points of failure (although most are already solved).

[@PriyankMandavawala]

This is a great video! very nicely explained!

[@learnprogramming123]

Nice video. Thanks for uploading.

[@aroundthisprettyplanet]

Nice presentation!

[@-q-b0_1]

This is awesome

[@SoeaOu]

Great talk, thanks.

[@debabhishek]

one question. I understand that we don't have an publicly accessible ip when we are connected to internet and browsing ,, how the front token is passed is it passed as http forward response with the token ?

[@aaronpk]

The server sending data (the authorization server) sends back an HTTP redirect to the browser with the data it's trying to send back to the client. That HTTP redirect step is what we call the front channel.

[@debabhishek]

@@aaronpk I have seen your another video and I understood how it works, but I am happy that you given enough attention to viewers queries , thanks again.

[@nicolasduboc]

Very nice presentation, thanks. Could you elaborate a bit more on the last topic on the video regarding the validation of the access token by the protected resource server ? You seem to suggest that, in pure OAuth2 (not OIDC) this can be done by an additional endpoint out of scope of the OAuth2 spec. Then, doesn't that imply that there must be a strong compatibility relation between the auth server and the resource server ? For OpenId Connect, do you suggest that the client app can forward the IDToken, that it got for its own use, to the resource server app ? Isn't the IDToken audience only for the client app ?