Deconstructing REST Security by David Blevins
Вставка
- Опубліковано 10 кві 2017
- The learning curve for security is severe and unforgiving. Specifications promise infinite flexibility, habitually give old concepts new names, are riddled with extensions, and almost seem designed to deliberately confuse. For a back-end REST developer, choking all this down for the first time is mission impossible. With an aggressive distaste for fancy terminology, this session delves into OAuth 2.0 as it pertains to REST and shows how it falls into two camps: stateful and stateless. The presentation also details a competing Amazon-style approach called HTTP Signatures and digs into the architectural differences of all three, with a heavy focus on the wire, showing actual HTTP messages and enough detail to have you thinking, “I could write this myself.”
Founder of Tomitribe, veteran of Open Source Java EE in both implementing and defining JavaEE specifications for over 10 years with a strong drive to see JavaEE simple, testable and as light as Java SE. Co-Founder of OpenEJB (1999), Geronimo (2003), TomEE (2011). Member of the Java EE 7 and EJB 3.2 Expert Groups, past member of the Java EE 6, EJB 3.1, and EJB 3.0 Expert Groups. Contributing author to Component-Based Software Engineering: Putting the Pieces Together from Addison Wesley. - Наука та технологія
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.
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.
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.
Great talk... hats off! And the repetition does play a key role, because this needs to be emphasised.
Great explaination. Cleared all the queries.
It's rare that I put something on my "Liked videos" _and_ "Watch later" (again) list.
This talk is one of them. 👌
Nice talk! Helped me a lot!
Very good Overview. Thanks !
great video!!
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.
very good clear presentation.
Great talk!!!
Excellent talk! Thanks a lot!
thank you for including the part about JWT being pronounced "JOT!"
Excellent, I got it now
2 minutes in and i already love the guy
Thank you !!
Amazing speech... it's like rest security is looking more like ssh
Great Talk. I've heard it live in Cologne and it improved my understanding of what to implement in which situation. Thanks a lot!
A fantastic talk. thanks!
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 talk, learned a lot from it, thank you! :)
I like David is so honest.
Best talk on REST security!!
Great talk, it transpires that you know what you are talking about and you explained it very clearly
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
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 insight.. Pls share the slides..
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.
If you've re-invented the wheel, you invented the wheel!
This guy is hilarious. Great talk.
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 speech! very nice solution!
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.
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
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?
"Token sounds more official" XD
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 ua-cam.com/video/osQmFNm0YDU/v-deo.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
Use Soap. It has security built in.
Just merge and consolidate all the crap into one standard. WC3 needs an annual merge review to stop tech diarrhea.