Тёмный

Deconstructing REST Security by David Blevins 

Devoxx
Подписаться 156 тыс.
Просмотров 28 тыс.
50% 1

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.

Наука

Опубликовано:

 

10 апр 2017

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 54   
@matheusdallrosa4698
@matheusdallrosa4698 3 года назад
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.
@stephenhartley375
@stephenhartley375 3 года назад
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
@pelic9608 4 года назад
It's rare that I put something on my "Liked videos" _and_ "Watch later" (again) list. This talk is one of them. 👌
@chon-850
@chon-850 3 года назад
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.
@AuDHDQ
@AuDHDQ 2 года назад
thank you for including the part about JWT being pronounced "JOT!"
@TheodoreRavindranath
@TheodoreRavindranath 5 лет назад
Great talk... hats off! And the repetition does play a key role, because this needs to be emphasised.
@makdeniss
@makdeniss 7 лет назад
Nice talk! Helped me a lot!
@SunilShekade
@SunilShekade 2 года назад
Great explaination. Cleared all the queries.
@orochinagi1111
@orochinagi1111 7 лет назад
great video!!
@MisterMArc
@MisterMArc 3 года назад
Very good Overview. Thanks !
@Bastien78320
@Bastien78320 6 лет назад
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.
@vjnt1star
@vjnt1star 4 года назад
very good clear presentation.
@fambo6969
@fambo6969 7 лет назад
Great talk!!!
@AnanthMajumdar
@AnanthMajumdar 7 лет назад
Excellent talk! Thanks a lot!
@jorgeguberte7585
@jorgeguberte7585 4 года назад
2 minutes in and i already love the guy
@rimbik1
@rimbik1 4 года назад
Excellent, I got it now
@Freedom-si6fb
@Freedom-si6fb 3 года назад
I like David is so honest.
@christopherstamp9716
@christopherstamp9716 7 лет назад
Amazing speech... it's like rest security is looking more like ssh
@howardmarles2576
@howardmarles2576 4 года назад
Thank you !!
6 лет назад
Great Talk. I've heard it live in Cologne and it improved my understanding of what to implement in which situation. Thanks a lot!
@VictorHernandez-zi7ll
@VictorHernandez-zi7ll 2 года назад
This guy is hilarious. Great talk.
@SiddharthKulkarniN
@SiddharthKulkarniN 7 лет назад
A fantastic talk. thanks!
@thegrandmaster55
@thegrandmaster55 5 лет назад
Great talk, it transpires that you know what you are talking about and you explained it very clearly
@antonalekseyev9651
@antonalekseyev9651 6 лет назад
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
@DavidBlevins 6 лет назад
Correct on the math. I should maybe add a slide to show that math.
@Blizzardsunkmyship
@Blizzardsunkmyship 3 года назад
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 ?
@tomknud
@tomknud 2 года назад
If you've re-invented the wheel, you invented the wheel!
@himanshutomar3512
@himanshutomar3512 4 года назад
Best talk on REST security!!
@kumarmanish9046
@kumarmanish9046 3 года назад
33:40 hidden easter egg : *No Way Jose!* :D Who else noticed?
@DavidBlevins
@DavidBlevins 2 года назад
You're the first and only so far :)
@kumarmanish9046
@kumarmanish9046 2 года назад
@@DavidBlevins Did you put it there deliberately or was it just a conincidence?
@DavidBlevins
@DavidBlevins 2 года назад
@@kumarmanish9046 I like to add stuff like that for my own entertainment :)
@MartinWilmes
@MartinWilmes 6 лет назад
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
@engelshentenawy 6 лет назад
well, you generate the JWT, you shouldn't make it too long as it will be encrypted anyway (https).
@demablogia
@demablogia 6 лет назад
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
@davidkozak8882
@davidkozak8882 5 лет назад
Great talk, learned a lot from it, thank you! :)
@originalme4368
@originalme4368 6 лет назад
Excellent, but I have question... What if the token is stolen and issued from wrong origin?
@raulastudillo1752
@raulastudillo1752 4 года назад
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.
@benotisanchez5583
@benotisanchez5583 2 года назад
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.
@atuljoshi6182
@atuljoshi6182 3 года назад
I am not getting how is 15000 TPS at LDAP ? Can anybody explain please ?
@stephenhartley375
@stephenhartley375 3 года назад
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
@atuljoshi6182 3 года назад
@@stephenhartley375 Thank you
@BharCode09
@BharCode09 4 года назад
Excellent insight.. Pls share the slides..
@stavsap
@stavsap 4 года назад
Great speech! very nice solution!
@tomknud
@tomknud 2 года назад
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?
@zexli6709
@zexli6709 5 лет назад
"Token sounds more official" XD
@nyrtzi
@nyrtzi 5 лет назад
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.
@alinaqvi2638
@alinaqvi2638 4 года назад
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
@savagebp0 6 лет назад
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
@DavidBlevins 6 лет назад
Check out some of the more advanced material and let me know what you think ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-osQmFNm0YDU.html The talk is so huge now I'm really looking for ways to condense and have people still not get lost.
@carnelyve866
@carnelyve866 6 лет назад
Use Soap. It has security built in.
@nstha8848
@nstha8848 5 лет назад
Your voice is like Mark Zuckerberg
@tenminutetokyo2643
@tenminutetokyo2643 4 года назад
Just merge and consolidate all the crap into one standard. WC3 needs an annual merge review to stop tech diarrhea.
Далее
Optional by Stuart Marks
48:21
Просмотров 30 тыс.
JUnit 5 by Marc Philipp
51:23
Просмотров 17 тыс.
Common API security pitfalls by Philippe De Ryck
50:19
OAuth 2.0 and OpenID Connect (in plain English)
1:02:17
Introduction to Apache Kafka by James Ward
49:48
Просмотров 278 тыс.
Managing Data in Microservices
52:07
Просмотров 142 тыс.
Authentication as a Microservice
50:26
Просмотров 214 тыс.
Здесь упор в процессор
18:02
Просмотров 146 тыс.
S-Pen в Samsung достоин Золота #Shorts
0:38