Deconstructing REST Security by David Blevins

[@stephenhartley375]

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.

[@pelic9608]

It's rare that I put something on my "Liked videos" _and_ "Watch later" (again) list. This talk is one of them. 👌

[@matheusdallrosa4698]

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.

[@chon-850]

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.

[@Bastien78320]

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.

[@SunilShekade]

Great explaination. Cleared all the queries.

[@TheodoreRavindranath]

Great talk... hats off! And the repetition does play a key role, because this needs to be emphasised.

[@jorgeguberte7585]

2 minutes in and i already love the guy

[@Freedom-si6fb]

I like David is so honest.

[@MisterMArc]

Very good Overview. Thanks !

[@AuDHDQ]

thank you for including the part about JWT being pronounced "JOT!"

[@orochinagi1111]

great video!!

[@antonalekseyev9651]

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)

[@DavidBlevins]

Correct on the math. I should maybe add a slide to show that math.

[@kumarmanish9046]

33:40 hidden easter egg : *No Way Jose!* :D Who else noticed?

[@DavidBlevins]

You're the first and only so far :)

[@kumarmanish9046]

@@DavidBlevins Did you put it there deliberately or was it just a conincidence?

[@DavidBlevins]

@@kumarmanish9046 I like to add stuff like that for my own entertainment :)

[@christopherstamp9716]

Amazing speech... it's like rest security is looking more like ssh

[@Blizzardsunkmyship]

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 ?

[@thegrandmaster55]

Great talk, it transpires that you know what you are talking about and you explained it very clearly

[@vjnt1star]

very good clear presentation.

[@makdeniss]

Nice talk! Helped me a lot!

[@fambo6969]

Great talk!!!

[@rimbik1]

Excellent, I got it now

[@AnanthMajumdar]

Excellent talk! Thanks a lot!

Great Talk. I've heard it live in Cologne and it improved my understanding of what to implement in which situation. Thanks a lot!

[@himanshutomar3512]

Best talk on REST security!!

[@VictorHernandez-zi7ll]

This guy is hilarious. Great talk.

[@atuljoshi6182]

I am not getting how is 15000 TPS at LDAP ? Can anybody explain please ?

[@stephenhartley375]

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.

[@atuljoshi6182]

@@stephenhartley375 Thank you

[@MartinWilmes]

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?

[@engelshentenawy]

well, you generate the JWT, you shouldn't make it too long as it will be encrypted anyway (https).

[@demablogia]

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

[@originalme4368]

Excellent, but I have question... What if the token is stolen and issued from wrong origin?

[@raulastudillo1752]

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.

[@howardmarles2576]

Thank you !!

[@BharCode09]

Excellent insight.. Pls share the slides..

[@pohjoisenvanhus]

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.

[@SiddharthKulkarniN]

A fantastic talk. thanks!

[@tomknud]

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?

[@benotisanchez5583]

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.

[@tomknud]

If you've re-invented the wheel, you invented the wheel!

[@stavsap]

Great speech! very nice solution!

[@davidkozak8882]

Great talk, learned a lot from it, thank you! :)

[@alinaqvi2638]

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.

[@savagebp0]

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

[@DavidBlevins]

Check out some of the more advanced material and let me know what you think kzbin.info/www/bejne/paS0nnmEopWMerc The talk is so huge now I'm really looking for ways to condense and have people still not get lost.

[@zexli6709]

"Token sounds more official" XD

[@nstha8848]

Your voice is like Mark Zuckerberg

[@tenminutetokyo2643]

Just merge and consolidate all the crap into one standard. WC3 needs an annual merge review to stop tech diarrhea.

[@carnelyve866]

Use Soap. It has security built in.