OAuth 2.0 - Implicit grant and how it works

[@olegsuprun7590]

Thank you very much! That was really helpfull and easy to understand!

[@gerardsimons3757]

Very clear, well done !

[@kirank5676]

it is awesome basic explaination. if possible please do videos on ping product demos. it may help to many

[@saschazegerman]

Thank you for the feedback. In regards to Ping products, have you checked their youtube channel? There is an extensive list of videos. If something is missing that you eould like to see, please let me know

[@charliemelga7445]

Great video, thanks for posting. I also assume the the client sends is client_id and client_secret on the initial request to the authorization end-point. Meaning the client_secret is in plain sight when using a packet capture as no TLS (aka SSL), unless the authorization end-point uses TLS? Do authorization end-points use TLS normally and if not why not? thanks very much

[@saschazegerman]

Hi Charlie! Please do not assume that a client_secret is involved. The implicit flow does not use nor support a client_secret. Since all traffic is in public (all parameters are seen in the URL) a secret would not be a secret. This also means that no tooling is required to capture any value that is involved in this flow. If you have not yet, please watch the video about client types. IT relates very much to this topic. I hope this helps!

[@breakpoin80]

How does the web app make use of the access token in the implicit flow if it doesn't receive the fragment? With JavaScript? Thank you for the video.

[@saschazegerman]

Hello Siby! Yes, the javascript client has access to the fragment and is able to extract the access_token. If there was a web app that needed the access_token the authorization_code flow would be the better choice. I hope this helps, thanks for watching!

[@breakpoin80]

@@saschazegerman I appreciate it

[@angmathew4377]

SAML 2 and what and why we need to use it?

[@lennypuente5926]

Great video I was just wondering how do you retrieve the code that gets sent back as a response from the /authorize endpoint? Is it stored somewhere? This is the step I'm stuck at currently. Thanks

[@saschazegerman]

Hello Lenny! You do not really need to store the code since it is usable exactly once. Just receive and use it for the code exchange. I have a simple example in my open source project "Loginbuddy". If you clone and run the project you can try a 'SPA' demo client that is using this flow. This is the project: github.com/SaschaZeGerman/loginbuddy, here are the demo web components (html + JS): github.com/SaschaZeGerman/loginbuddy/tree/master/net.loginbuddy.democlient/web Have a look at ./script/spa-demo and you will find the code that received the authorization_code. I hope that helps!

[@davespencer2349]

good video well explained

[@commonpike]

Most services also limit the capabilities, or possible scopes, of clients using implicit flow. Their use case is mostly 'web app', so only need limited features, and since it is less secure...

[@muratgumus4218]

thank you for these precious information , can I have chance to access your powerpoint documents ?

[@saschazegerman]

Hi Murat! Thanks for your feedback. Unfortunately, I cannot share my slides. I hope the videos still help you.

[@Gr3mBr4nX]

Just because something is public doesn't necessarily mean that it's not secure. The reason why the implicit flow has flaws is missing imo

[@saschazegerman]

Hello Christian! Thanks for you comment. If my video could not point out why the implicit flow should be avoided, please have a look at the IETF oauth best practices paragraph on that, Maybe that additional info helps to convey the message: datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-16#section-2.1.2 (Updated link)

[@huizhao2050]

@@saschazegerman The link is dead. Could you please revise it?

[@saschazegerman]

@@huizhao2050 Thanks for the info, I updated the link!