This made the differences between the security level of the flows an the reasons behind them much clearer for me, also cleared up the reasons why it was not one before on some environments, great video!
I am currently working on a solution for a system that will involve OAuth2 and I can't thank you enough for this video and the one about OAuth and OIDC in plain english. Very great conversation between a Product person and a dev that I will be doing something similar to. Thank you thank you thank you!
So far I have read many articles about Oauth2 and the difference between Implicit and AuthCode flow, but this video owned all of them! Great job guys, thanks for it, keep it up!
Very informative and well presented, thank you! It annoys me to no end that we basically solved this problem with SSL client certificates a long time ago and we keep wasting time on this, but this is kinda beside the point...
Implicit flow was required as we didn’t have CORS back then. But, how come applications were able to call resource servers at that time? Or were resource server and client app usually had the same domain ?
Finally a good explanation about this, i have been days searching in the internet, all this oauth2 protocol is the most confusing thing i had ever to learn. Had no idea what was the problem of just sending a token in the url. But if it is not implicit just make the post directly to get the access token?
How does this prevent app developers from using proxy's to reverse engineer your app, make un-authorised calls to your API from their cloned app? Is there a way to prevent this in OAuth 2.0?
Good question. Fundamentally, if someone has physical access to the app/device and calls are going over the internet, it's hard to prevent this. What OAuth does is tie authorization (the access token) to the user. So, a valid access token authorizes API calls _for a particular user_. Someone could figure out your API endpoints, but they would still need a user to present their real credentials to the authorization server in order to get a valid access token.
Many thanks for this video. One question though: speaking about backend application - in terms of oauth client, do I make my frontend/mobile application and backend (e.g. spring boot) application two separate oauth clients? Like Frontend/mobile is public with PKCE and backend is confidential with client secret. Or they should be a single oauth client - public with PKCE?
Do I understand correctly, that I can use authorization code + PKCE basically instead of any other flow? Even for simple authorization code flow (in order not deal with updating the expiring client secret)?
Authorisation code +PKCE can be used for any/all code flows. However, it was intended for Mobile or Single Page App's where the token is extracted in browsers.
Eh, at the end of the video I'm still here ;) This video takes some time to get over the warm-up chatter, but in the end it's worth the time spend due to the good background and reasoning information. Just to nitpick: I would have like a few simple sketchy illustrations thrown in to underline the spoken explanations.
Any solutions when service workers have queues up requests (offline mode) and a access token expired. How to get Service Worker to get a refresh token with Implicit Grant? The other issue is Microsoft AAD does not support Code Auth Flow with SPA clients :(
Question: at 2:50, Aaron says that the very last step of OAuth is a POST request over the token endpoint; however, according to another presentation by Nate (th-cam.com/video/996OiexHze0/w-d-xo.html at 52:25), the POST request is made by the client application (RP), not the end-user. Could you please clarify ?
From a UX perspective, I don't like all the redirects, and extra steps like having to click a 'grant access' button that comes with PKCE. I like the flow of the password grant. Is it really a bad idea to use password grant for SPAs?
the "grant access" button isn't unique to PKCE, you could have that with the implicit flow too. That's called the "consent" feature and you can choose to enable or disable it per application regardless of the flow. As for the password grant, that's also being deprecated in the OAuth group for many reasons, so we may need to do a video about that too! oauth.net/2/grant-types/password/
I have a simple login form in a web portal. Once the user successfully logged in, they are redirected to home page of the web portal. Now here I need to authenticate across Okta and need to have an access token so that I can use the access token to retrieve user details from a system of records at the backend through an API Gateway. The API Gateway would be responsible for authorizing the access tokens. Here in this case, which flow should I use?
So if understood well, if i just want to make a web without need that web to access other servers requesting data like could be a login with google. I could just make the app more secure using oauth2 cause i wouldnt just receive a jwt token that anyone could use to get access with my credentials but also a client server would have set a secret or a dynamic secret with PKCE and request an authorization token to a authorization server that would be in the same server as the client, everything together in the same server.
So in implicit flow, if the redirect is intercepted, it's game over because the Access Token is in the URL. Explicit flow is better because instead of the Access Token, you get an Authorization Token, which needs to be sent back to the Auth Provider to get the real Access Token. Question: if an attacker still does the same attack with the implicit flow and obtains the Authorization Token, what stops them from just sending that to the Auth Provider to get an access token? what makes the authorization code "less sensitive" than the final access token?
You're exactly right, except it's called an "authorization code" not "authorization token". The reason it's "less sensitive" is because the authorization code is: short-lived (usually 60 seconds), one-time use, and requires a client secret and/or PKCE code verifier in order to be used to get an access token.
Here's a blog post that I wrote a couple years ago that combines a React app with Spring Boot and uses session cookies between them. developer.okta.com/blog/2018/07/19/simple-crud-react-and-spring-boot
It's not Okta specific, it applies in general. Okta docs on this are on developer.okta.com/authentication-guide/implementing-authentication/auth-code-pkce/#_1-setting-up-your-application but you can find general info on PKCE elsewhere as well.
![NISAMANEE - TADA (ท้าดา) [ OFFICIAL MV ]](http://i.ytimg.com/vi/hcQHEPMmJpU/mqdefault.jpg)
I really like how a lot of the potential questions were anticipated, asked and also answered here. I really respect your work here!
The interviewer did the first and best presentation he is well versed in the technical bit.
This made the differences between the security level of the flows an the reasons behind them much clearer for me, also cleared up the reasons why it was not one before on some environments, great video!
I am currently working on a solution for a system that will involve OAuth2 and I can't thank you enough for this video and the one about OAuth and OIDC in plain english. Very great conversation between a Product person and a dev that I will be doing something similar to. Thank you thank you thank you!
You're welcome! Glad it was helpful.
So far I have read many articles about Oauth2 and the difference between Implicit and AuthCode flow, but this video owned all of them! Great job guys, thanks for it, keep it up!
These guys have a way to explain complicated thing in a very understandable way. Thanks !
Thanks for watching! ♥
@@nbarbettini thanks for sharing ;-) by the way, your colleague looks a lot like Colin Farrell on that video haha
Aaron has a very unique way and explaining hard concepts simply, great job by Okta team!
Very informative and well presented, thank you! It annoys me to no end that we basically solved this problem with SSL client certificates a long time ago and we keep wasting time on this, but this is kinda beside the point...
Implicit flow was required as we didn’t have CORS back then. But, how come applications were able to call resource servers at that time? Or were resource server and client app usually had the same domain ?
I'm really glad I watched this video. Thank you for uploading!
this is such a great explanation haha. honestly the interviewer questions were 100% spot on
Glad it was helpful!
10 points for basic clarity as to how and why.
Aaron and Nate are great. Thanks for your feedback!
That's so useful! So many things I explained I was wondering about and trying to find answers for!
This answered a lot of my questions! Thank you.
Great video. Serving up our SPA from .Net Core so we can keep oauth on the server.
Great video that reveal a lot of my confusion. Thanks!
Really nice discussion, I can tell a lot of thought went into both the question and answer. Thank you!
Finally a good explanation about this, i have been days searching in the internet, all this oauth2 protocol is the most confusing thing i had ever to learn. Had no idea what was the problem of just sending a token in the url. But if it is not implicit just make the post directly to get the access token?
Great video. All the right questions asked. Thank you!
Very helpful. Thanks for posting this!
This was surprisingly too good. Thank you so much! 😎
Great talk, things became more clear now 👏👍
Nowadays it's hard to imagine the internet without cross domain requests. And to think CORS was accepted as recently as 2014.
How does this prevent app developers from using proxy's to reverse engineer your app, make un-authorised calls to your API from their cloned app? Is there a way to prevent this in OAuth 2.0?
Good question. Fundamentally, if someone has physical access to the app/device and calls are going over the internet, it's hard to prevent this. What OAuth does is tie authorization (the access token) to the user. So, a valid access token authorizes API calls _for a particular user_. Someone could figure out your API endpoints, but they would still need a user to present their real credentials to the authorization server in order to get a valid access token.
10:07 they could still intercept the code, they just wouldn't be able to use it because they don't have the code verifier / "dynamic secret".
Excellent overview. Thanks!
True ... 10 years ... Its been a long time ...
Amazing and such informative discussion!!
Thanks for the video, great content
Many thanks for this video. One question though: speaking about backend application - in terms of oauth client, do I make my frontend/mobile application and backend (e.g. spring boot) application two separate oauth clients? Like Frontend/mobile is public with PKCE and backend is confidential with client secret. Or they should be a single oauth client - public with PKCE?
Best for you to use two clients. Each client can be provisioned differently.
Great video, thanks for the explanation!
Do I understand correctly, that I can use authorization code + PKCE basically instead of any other flow? Even for simple authorization code flow (in order not deal with updating the expiring client secret)?
Authorisation code +PKCE can be used for any/all code flows. However, it was intended for Mobile or Single Page App's where the token is extracted in browsers.
Very informative, thanks guys.
Eh, at the end of the video I'm still here ;) This video takes some time to get over the warm-up chatter, but in the end it's worth the time spend due to the good background and reasoning information. Just to nitpick: I would have like a few simple sketchy illustrations thrown in to underline the spoken explanations.
Longer video, but I have some detailed illustrations on these flows in this talk: th-cam.com/video/996OiexHze0/w-d-xo.html
@@nbarbettini thanks for the pointer, very well done explanations.
Two legends in iam.😊
This was great. Thank you!
Any solutions when service workers have queues up requests (offline mode) and a access token expired. How to get Service Worker to get a refresh token with Implicit Grant? The other issue is Microsoft AAD does not support Code Auth Flow with SPA clients :(
Question: at 2:50, Aaron says that the very last step of OAuth is a POST request over the token endpoint; however, according to another presentation by Nate (th-cam.com/video/996OiexHze0/w-d-xo.html at 52:25), the POST request is made by the client application (RP), not the end-user.
Could you please clarify ?
From a UX perspective, I don't like all the redirects, and extra steps like having to click a 'grant access' button that comes with PKCE. I like the flow of the password grant. Is it really a bad idea to use password grant for SPAs?
the "grant access" button isn't unique to PKCE, you could have that with the implicit flow too. That's called the "consent" feature and you can choose to enable or disable it per application regardless of the flow. As for the password grant, that's also being deprecated in the OAuth group for many reasons, so we may need to do a video about that too! oauth.net/2/grant-types/password/
I have a simple login form in a web portal. Once the user successfully logged in, they are redirected to home page of the web portal. Now here I need to authenticate across Okta and need to have an access token so that I can use the access token to retrieve user details from a system of records at the backend through an API Gateway. The API Gateway would be responsible for authorizing the access tokens. Here in this case, which flow should I use?
So if understood well, if i just want to make a web without need that web to access other servers requesting data like could be a login with google. I could just make the app more secure using oauth2 cause i wouldnt just receive a jwt token that anyone could use to get access with my credentials but also a client server would have set a secret or a dynamic secret with PKCE and request an authorization token to a authorization server that would be in the same server as the client, everything together in the same server.
Great video. very informative. thanks!
So in implicit flow, if the redirect is intercepted, it's game over because the Access Token is in the URL. Explicit flow is better because instead of the Access Token, you get an Authorization Token, which needs to be sent back to the Auth Provider to get the real Access Token. Question: if an attacker still does the same attack with the implicit flow and obtains the Authorization Token, what stops them from just sending that to the Auth Provider to get an access token? what makes the authorization code "less sensitive" than the final access token?
You're exactly right, except it's called an "authorization code" not "authorization token". The reason it's "less sensitive" is because the authorization code is: short-lived (usually 60 seconds), one-time use, and requires a client secret and/or PKCE code verifier in order to be used to get an access token.
Thanks for your quick reply (and correcting my terminology) Aaron. What a legend! I was missing the secret/PKCE bit. Makes perfect sense.
this is more interesting than netflix web series..
Next step: Hollywood?!
good one! Thanks
Great explanation, thanks.
Is there any example project for using session cookie with react app?
Here's a blog post that I wrote a couple years ago that combines a React app with Spring Boot and uses session cookies between them. developer.okta.com/blog/2018/07/19/simple-crud-react-and-spring-boot
Fantastic video thanks!
Great info. Thanks.
This is a great video thank you !!
hey guys! do you have any videos/articles about PKCE itslef? is it OKTA specific?
It's not Okta specific, it applies in general. Okta docs on this are on developer.okta.com/authentication-guide/implementing-authentication/auth-code-pkce/#_1-setting-up-your-application but you can find general info on PKCE elsewhere as well.
PKCE is an extension to OAuth, and many providers support it! Here's some more info and links to some additional resources about it! oauth.net/2/pkce/
@@mathiasconradt Joshua Hartley is a liar and l he still lives with me and never divorced me either
I learned from this great vid - thx!
superb
Great video!
Nice
20 mins to explain that nerds ?
Great video. Serving up our SPA from .Net Core so we can keep oauth on the server.
Great video, thanks