An excellent architectural overview of the options available for API authentication, that really explains why each scheme is better or worse than the others. Essential viewing for API architects.
I think that OAuth2 was made to solve the problem of delegating the authorization to a third part. But using it to make authorization on your own REST API is an overkill in my opinion.
yes but the point for OAuth2 originally was that the token was communicated through back channel between the web server and the resource server so it's harder for man-in-the-middle attack on the end user. OAuth2 was about authorisation. What you described as "just another fancy password" is actually Open ID Connect, which is built on top (retrofitted) of OAuth2, plus the implicit flow - which is not the usual OAuth2 flow.
But where would one store current existing key_ids in a stateless system ? A common caching layer / server containing these keys would still be a bottleneck, albeit, a fast one. Would it be unsafe to encrypt the access token and pass the key within it ?
Please explain where 0.55 TPS came from 32:21? 1000 users refresh their tokens once per hour (3600 seconds) = 0.27 TPS for refresh. 0.55 TPS would be in case of 30 minutes tokens expiration period (30 min * 60 = 1800 seconds)
Assume enforcing authentication on the back end microservices as well as the front end API gateway then: At the gateway, 1,000 users @ 3tps = 3,000 tps. In the back end microservices, 1,000 users @ 3 tps requiring the use of 4 microservices to complete = 3,000 tps * 4 = 12,000 tps For a total of 3,000 front end + 12,000 back end = 15,000 tps.
Only cleartext , I mean violet + yellow text, ( base64 encoded , I know ) is variable lenght . The sign (blue text ) is hashed , so it should have a limited size. Anyway, I think your bigger problem could be the HTTP header size limits apply by web servers. For example, Tomcat defines , by default, 8K ( per HTTP header ) . But I don't think that you reach easily
OAuth2.0 should be used for limited Authorization NOT Authentication. If you want to still use OAuth2.0 there's a layer on top of it called OpenID which is more for Authentication and works fine.
I use node js crypto to encrypt and decrpt a json payload containing the user details. I don't know I'm probably the only one doing that lol. But I really need to know if this is vulnerable. Got sick and tired of the cumbersome npm modules with a Chunk of unnecessary code and a bunch of other npm modules. I mean bcrypt somes with some 40 node modules. LoL what? This is to hash a password? I think node js inbuilt crypto module handles that pretty easily.
This seems like a great lecture that I've made a point to come back to after several months. In terms of state, though, wouldn't a 'revocation' list for refresh tokens cause some state distribution and keeping?
At 16:18 just thinking that a username-password pair at least has a lookup based on the username and is stored as a hash on the server. Session IDs / tokens just rely on being random enough but I think they're not stored as securely on the server. Password logins should have at least some sort of a brute forcing prevention scheme in place like rate limiting, but then again rate limiting in a load balanced and distributed system would require a shared resource to do that. In the end the user agent is just sending in a bunch of bytes and the services are checking that against a table either raw or hashed. Some systems require the client to first fetch what is effectively a salt tied to the session they get at the same time and then send a hashed version of the password and username or whatever sequence of bytes they need to send in order to be authenticated. But like David says there only a limited number of ingredients here that people mix in order to try to secure things.
Man.. Such a great meat, but the rest of the 85% was a huge broken record player of rants. This probably could've covered the full content in 20 minutes instead
Check out some of the more advanced material and let me know what you think th-cam.com/video/osQmFNm0YDU/w-d-xo.html The talk is so huge now I'm really looking for ways to condense and have people still not get lost.
Excellent talk ... we need more presenters calling out BS on "new" techs which are 80% rehash of previous techs and provide little to no benefit to the end users. 'JWT = Cookie' lols awesome.
An excellent architectural overview of the options available for API authentication, that really explains why each scheme is better or worse than the others. Essential viewing for API architects.
I think that OAuth2 was made to solve the problem of delegating the authorization to a third part. But using it to make authorization on your own REST API is an overkill in my opinion.
yes but the point for OAuth2 originally was that the token was communicated through back channel between the web server and the resource server so it's harder for man-in-the-middle attack on the end user. OAuth2 was about authorisation. What you described as "just another fancy password" is actually Open ID Connect, which is built on top (retrofitted) of OAuth2, plus the implicit flow - which is not the usual OAuth2 flow.
It's rare that I put something on my "Liked videos" _and_ "Watch later" (again) list.
This talk is one of them. 👌
Great explaination. Cleared all the queries.
Great talk... hats off! And the repetition does play a key role, because this needs to be emphasised.
This video is very interesting. I will have to watch it twice to fully understand all the implication of each technology. Thank you David Blevins.
I like David is so honest.
Very good Overview. Thanks !
thank you for including the part about JWT being pronounced "JOT!"
2 minutes in and i already love the guy
very good clear presentation.
33:40 hidden easter egg : *No Way Jose!* :D Who else noticed?
You're the first and only so far :)
@@DavidBlevins Did you put it there deliberately or was it just a conincidence?
@@kumarmanish9046 I like to add stuff like that for my own entertainment :)
great video!!
Amazing speech... it's like rest security is looking more like ssh
But where would one store current existing key_ids in a stateless system ? A common caching layer / server containing these keys would still be a bottleneck, albeit, a fast one. Would it be unsafe to encrypt the access token and pass the key within it ?
Excellent, I got it now
Nice talk! Helped me a lot!
Please explain where 0.55 TPS came from 32:21?
1000 users refresh their tokens once per hour (3600 seconds) = 0.27 TPS for refresh.
0.55 TPS would be in case of 30 minutes tokens expiration period (30 min * 60 = 1800 seconds)
Correct on the math. I should maybe add a slide to show that math.
This guy is hilarious. Great talk.
Excellent insight.. Pls share the slides..
Excellent talk! Thanks a lot!
Great talk!!!
Great Talk. I've heard it live in Cologne and it improved my understanding of what to implement in which situation. Thanks a lot!
I am not getting how is 15000 TPS at LDAP ? Can anybody explain please ?
Assume enforcing authentication on the back end microservices as well as the front end API gateway then:
At the gateway, 1,000 users @ 3tps = 3,000 tps.
In the back end microservices, 1,000 users @ 3 tps requiring the use of 4 microservices to complete = 3,000 tps * 4 = 12,000 tps
For a total of 3,000 front end + 12,000 back end = 15,000 tps.
@@stephenhartley375 Thank you
If you've re-invented the wheel, you invented the wheel!
Very nice talk. Just one question: How would you handle the case that the JWT data gets too big to be sent on every request?
well, you generate the JWT, you shouldn't make it too long as it will be encrypted anyway (https).
Only cleartext , I mean violet + yellow text, ( base64 encoded , I know ) is variable lenght . The sign (blue text ) is hashed , so it should have a limited size. Anyway, I think your bigger problem could be the HTTP header size limits apply by web servers. For example, Tomcat defines , by default, 8K ( per HTTP header ) . But I don't think that you reach easily
Excellent, but I have question... What if the token is stolen and issued from wrong origin?
OAuth2.0 should be used for limited Authorization NOT Authentication. If you want to still use OAuth2.0 there's a layer on top of it called OpenID which is more for Authentication and works fine.
Great talk, it transpires that you know what you are talking about and you explained it very clearly
Thank you !!
Best talk on REST security!!
I use node js crypto to encrypt and decrpt a json payload containing the user details. I don't know I'm probably the only one doing that lol. But I really need to know if this is vulnerable. Got sick and tired of the cumbersome npm modules with a Chunk of unnecessary code and a bunch of other npm modules.
I mean bcrypt somes with some 40 node modules. LoL what? This is to hash a password? I think node js inbuilt crypto module handles that pretty easily.
A fantastic talk. thanks!
This seems like a great lecture that I've made a point to come back to after several months. In terms of state, though, wouldn't a 'revocation' list for refresh tokens cause some state distribution and keeping?
Great talk, learned a lot from it, thank you! :)
At 16:18 just thinking that a username-password pair at least has a lookup based on the username and is stored as a hash on the server. Session IDs / tokens just rely on being random enough but I think they're not stored as securely on the server. Password logins should have at least some sort of a brute forcing prevention scheme in place like rate limiting, but then again rate limiting in a load balanced and distributed system would require a shared resource to do that. In the end the user agent is just sending in a bunch of bytes and the services are checking that against a table either raw or hashed. Some systems require the client to first fetch what is effectively a salt tied to the session they get at the same time and then send a hashed version of the password and username or whatever sequence of bytes they need to send in order to be authenticated. But like David says there only a limited number of ingredients here that people mix in order to try to secure things.
Great speech! very nice solution!
"Token sounds more official" XD
Man.. Such a great meat, but the rest of the 85% was a huge broken record player of rants. This probably could've covered the full content in 20 minutes instead
Check out some of the more advanced material and let me know what you think th-cam.com/video/osQmFNm0YDU/w-d-xo.html The talk is so huge now I'm really looking for ways to condense and have people still not get lost.
Excellent talk ... we need more presenters calling out BS on "new" techs which are 80% rehash of previous techs and provide little to no benefit to the end users. 'JWT = Cookie' lols awesome.
Your voice is like Mark Zuckerberg
Just merge and consolidate all the crap into one standard. WC3 needs an annual merge review to stop tech diarrhea.
Use Soap. It has security built in.