Adventures in Federating Authorization and Authentication with OAuth
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 28 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30637 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201528 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
Multiplication signInformation technology consultingComputer programmingMoment (mathematics)Cellular automatonGroup actionIntegrated development environmentBitAnalytic setWeb 2.0Computer animation
00:42
Insertion lossKey (cryptography)Bit rateGroup actionSoftware developerSet (mathematics)Computer programmingExtreme programmingBasis <Mathematik>Computer clusterConstraint (mathematics)Regular graphNumberGreedy algorithmError messageInformation retrievalMultiplication signHypermediaTask (computing)MereologyComputer animationXML
02:03
Extreme programmingNumberStandard deviationComputer-assisted translationComputer programming1 (number)Bit rateComputer animation
03:03
CodeCoefficient of determinationOffice suiteMass1 (number)Maxima and minimaRight angleComputer fileOcean currentComputer-assisted translationPlanningComputer animation
03:50
Computer programmingWebsiteWeb serviceMetropolitan area networkWordMeeting/Interview
04:29
Information securityMobile WebBitCASE <Informatik>Web serviceQuicksortComputing platformEvolutePhysical systemAreaWordMeeting/InterviewComputer animation
05:25
Endliche ModelltheorieData managementComputer animation
05:55
Resultant1 (number)Type theoryCollatz conjectureMultiplication signComputer animationMeeting/Interview
06:26
Point (geometry)Representation (politics)Right angleMultiplication signMobile appMathematicsDialectUniverse (mathematics)State observerXML
07:00
Web serviceRow (database)Single sign-onMultiplication signBounded variationInsertion lossBasis <Mathematik>Physical systemMomentumBitCartesian coordinate systemMultiplicationInformation securityDiagram
08:04
State of matterCartesian coordinate systemMultiplication signInformation securityDifferent (Kate Ryan album)Source codeComputer animation
08:37
Computer-assisted translationSoftware1 (number)WordInsertion lossComputer programmingRing (mathematics)Computer animation
09:12
Mechanism designCartesian coordinate systemWordEnterprise architectureInstance (computer science)Physical systemDifferent (Kate Ryan album)Type theoryPasswordComputer configurationMoment (mathematics)Set (mathematics)Error messageKey (cryptography)Video gameRight angleMultiplication signBit rateArithmetic meanComputer animation
10:55
BitExecution unitGoodness of fitSet (mathematics)ArchitectureCodecInformation securityWeb serviceWordLinearization
11:57
Multitier architectureAuthorizationBitAuthenticationWeb 2.0Right angleContent (media)CASE <Informatik>Square numberWebsiteSingle-precision floating-point formatPoint (geometry)ImplementationCartesian coordinate systemProcess capability indexNumberPhysical systemAdditionInformationComplex (psychology)Category of beingRevision controlQuicksortForm (programming)Web serviceToken ringHacker (term)Information securityType theoryVideo gameSocial classSource codeMultiplication signLengthParameter (computer programming)Broadcasting (networking)TheoryExecution unitCycle (graph theory)Moment (mathematics)Computer animation
16:15
AuthorizationCodeTwitterLoginFrequencyString (computer science)Cartesian coordinate systemField (computer science)Hacker (term)FlagWeb serviceClient (computing)Connectivity (graph theory)QuicksortServer (computing)ImplementationMereologyData storage deviceBitInternet service providerProper mapMechanism designAuthenticationHuman migrationBit rateMultiplication signWorkloadInsertion lossDependent and independent variablesAreaUniform resource locatorVariable (mathematics)Term (mathematics)NumberCASE <Informatik>Pattern languageResultantElectronic mailing listXML
21:00
Different (Kate Ryan album)Web serviceFood energySystem callMechanism designLoginQuicksortComputer animation
21:34
Mechanism designHookingCartesian coordinate systemAuthenticationPlug-in (computing)Multiplication signComputer animation
22:05
Web serviceCartesian coordinate systemImplementationArchitectureUsabilityPhase transitionStrategy gameServer (computing)CodeCentralizer and normalizerSystem callStructural loadInstallation artEndliche ModelltheoriePasswordLoginAuthorizationSemiconductor memorySurfaceAreaLine (geometry)Software testingDependent and independent variablesCASE <Informatik>1 (number)Residual (numerical analysis)Task (computing)Engineering drawingDiagram
24:20
Insertion lossToken ringMultiplication signWeb servicePattern languageExecution unitComputer animation
25:17
Standard deviationTerm (mathematics)MereologyBitToken ringMetadataWeb serviceAuthorizationRight angleDifferent (Kate Ryan album)ArchitectureClient (computing)AuthenticationDatabasePoint (geometry)System callPhysical systemSingle-precision floating-point formatProduct (business)Multiplication signCartesian coordinate systemGame controllerEmailEvent horizonProcess (computing)Data managementWordGraph coloringSurfaceSocial classVariety (linguistics)TheoryXML
28:54
Product (business)Different (Kate Ryan album)Video gamePhysical systemToken ringCodecFrequencyImplementationOcean currentAuthenticationWeb serviceMultiplication signCartesian coordinate systemArchitectureIn-Memory-DatenbankRight angleParameter (computer programming)Branch (computer science)Form (programming)DivisorTheory of relativityError messageVariety (linguistics)Series (mathematics)Water vaporComputer animationEngineering drawing
31:21
Reflection (mathematics)ImplementationExpert systemProduct (business)Web 2.0Single-precision floating-point formatWebsiteProcess (computing)GodToken ringMiniDiscWeb serviceAuditory maskingDefault (computer science)Information securityCartesian coordinate systemMechanism designQuicksortJava appletReal numberSoftware developerMultiplication signUser interfaceRight angleUniverse (mathematics)Revision controlStandard deviationAreaPattern languageWordRow (database)Panel paintingComputer animation
35:27
Bit rateRevision controlElectronic mailing listLecture/Conference
Transcript: English(auto-generated)
00:01
My name is Lance Gleason and I'm with a small consultancy called Polyglot Programming. We specialize in Rails development, a little bit of Angular, along with wearable companies.
00:28
You can go to a small company called Attenda Linux, this is one of our side product companies at this point. We're doing web analytics in physical spaces with things like Deacons. So if anything high school related, you can probably have a beer or something, it's just fun stuff.
00:41
Stux also happens to be the co-organizer of Ruby Fusa. Which is, up until this year, has been the only Ruby developer conference in Africa. There now is also a small one in Nairobi which makes us extremely happy because we love spreading Ruby love. Also am co-organizer of Ruby Decamp Set A.
01:03
Now has anybody here in this room ever heard of Ruby Decamp? Okay, so if you're curious to know what Ruby Decamp Set A is, come talk to me afterwards, it's an unconference. Or talk to somebody that's actually meant to Ruby Decamp because that is how we started this. Quick question for everybody though. How many people here in this room have ever heard of extreme programming?
01:25
Okay, so pretty much everyone. And how about pair programming? Okay, good to know. Awesome. Okay, how many people on a regular basis practice pair programming? Okay, so a decent number.
01:41
Well, with us being a routine consultant, we were trying to figure out one time, how do we maintain the benefits of pair programming when we're faced with some constraints you may not need with a larger organization? You may not have a budget for a dev pair, you may not have, you know, there just may not be enough people. And so one day I woke up and I saw this.
02:05
How many people here have a cat? A decent number. I thought, what is that about extreme programming to the next level? And I substituted out a human dev pair for a feline dev pair and practiced.
02:26
So here we are, we're getting ready for a standard session here, and I'm going to kind of do this a little bit backwards, but you know, I've got a comfortable chair for my dev partner, and we're using the single-keyboard approach. I've learned a few things with this. I've learned that first of all, with a cat, like, I used to think that when Ally would jump up on my keyboard,
02:44
she was trying to tell me, you just want attention. Really, she's trying to tell me, you're doing something stupid, stop that. And as I've talked about this, it's like there are a lot of misconceptions around it. So people say, well, the cat is always the observer, right? And it's like rubber duck programming.
03:02
I disagree. She draws, and her code works. This was a gnarly debugging session, we were working on this. We had a really tough problem, and she helped us through this. Now, how many of you are dog people? Okay, we have run some experiments with K9 Coding 2. Here's Max.
03:21
He was solving a Ruby problem. And there's R1B. He was solving another issue, working on some gamble files and all that. And here's our interspecies current planning session. As you can probably see here, though, I don't know. We have she-zoos, and the she-zoos don't seem to have as much motivation as the cat does.
03:43
The cat is definitely the team lead, both from a tech standpoint and just from motivation. So it's definitely something that you should try. We've got a little website for it. I also happen to have t-shirts later on, so if you're into pro programming, we've got little t-shirts that talk about that. But we're obviously not here to talk about pro programming and all that.
04:03
We're here to talk about web services. And specifically microservices. I wasn't here earlier to see DHH's talk, but I heard that there were some rumblings about DHH's, and we're using too many of them. If you subscribe to that, you may think that this is... You may not like this talk, but get over this.
04:24
And specifically when we're talking about federating off, we're going to talk about a few things. We're going to talk about web services. We're going to talk about federation. We're going to talk about security. And we're going to talk about mobile. In a way, it's almost like it's a little novel, right?
04:41
We've got the Dulce case dude, right? We've got the federation, we've got war, we've got the other. Okay. So let's start, though, by talking about services. What are they? I guess the first question is, how many people in this room have ever worked, or how many people here understand what web services are, feel like they kind of do?
05:03
Okay, so a few. And then, how many people here have worked in a system where you're basically, you're working in some sort of service-based architecture? Okay, so a few. For those that haven't, the best explanation I can give you for web services is it's kind of, it's sort of an evolution of your platform.
05:21
And let me explain what I mean by that. You start off with this little rails application, which is like a puppy. Right, it's like a kitten, if you're a kitten. But then, over time, it grows and kind of gets like a lion. Or, maybe a better example is it starts off like Mr. Panky, where he's friendly, you know, he leaves little brown spots,
05:41
but he's, you know, it's small and it kind of, it's manageable and everything like that. Pretty soon it grows, and you end up with like, you know, a human or something. And then, it ends up with something like this. Do something to break it up. So it's kind of, I've very shamelessly stolen this slide, but the idea is it's basically,
06:00
it's basically taking a big monolith and breaking it up. Anybody can say, why are you using poop for an example, this one? Well, because there are two types of engineers. The ones that have this happening from time to time. You know, the ones that rely on it, right? I guess if it was somebody else's code, where we have some empathy and we're saying,
06:22
okay, there's probably a good reason for it because I've done this myself, but that's the idea behind it. Okay, so why do we want to even break up our application? Before we talk about federations, why do we even care about this? Well, usually something's kind of leading us to that point. The monolith is kind of getting pretty unwieldy.
06:41
It's getting really difficult to make changes because it's just too big. So it feels like this dude here, our app may be starting to get really slow. Or maybe that we need to scale, we need to be able to scale to certain things to kind of be able to hit the dials. How about federations?
07:04
We're talking about federation and federating these all-out services. So what is federation? Well, the textbook definition is basically, it's taking disparate systems and using a common interface so that the disparate systems act as one system.
07:27
An example of that might be that you have something like this where you're doing SSO, you want to federate something with a single sign-on solution and have that single sign-on solution work across multiple sub-services.
07:42
Okay, so single sign-on. This is one of the impetus of how this talk turned out because basically we had an application where we wanted to implement a single sign-on.
08:02
Now when we're getting to that though, let's also understand a bit about security. Now security, when we think about that, we think about a lot of different things. You think about, well, that means nobody came into my application. The first thing obviously we want to understand with that is that there is no such thing as an application that is not 100% secure.
08:24
Just like when they have states, for example, states are rated by the amount of time people take an experienced state cracker to get into the thing. So a classic example of that might be your Wi-Fi network, for example. When you have a Wi-Fi network, you think, yeah, it's fairly secure or whatever else like that.
08:42
But yet you could do something like basically take a spark cord, a few different pieces, and then put it on your cat and go war-dive. There was actually about a year ago a guy did this. It was awesome. He used his cat to send his cat around to war-dive the neighbor's Wi-Fi networks. He was able to tell which ones were insecure.
09:00
Fun stuff. And if you have an adept hacker, like my programming partner here, they can get in your system too. But if we're working with a RANOS application idea, we're going to probably use something like Devise.
09:20
That's usually our go-to solution when we're just adding some security, like we need to log into our application or do something else like that with it. How many people here have used Devise? Pretty much everybody, right? Now, yes, you may use Word. Yes, you may use a custom solution. But for most of us, we're probably going to use Devise. And if we're federating our application, the problem is it's greatly the model.
09:44
We just put Devise on there. Awesome. Don't. But if we're not just going from service-oriented architecture, we're just using Devise as our mechanism for protecting these disparate resources now, you're going to end up with something that probably feels kind of like that. You're going to have basically multiple instances of your application
10:04
that are going to either have the same password you have to basically coordinate, or you're going to have a bunch of different passwords and people will probably choose something insecure, and you'll have something like that. These are great passwords, by the way, so you should use them for all your knowledge. So other options that we may have as a Rails developer,
10:22
Stanley. How many people here have ever worked with Stanley on your application? So a few. It's not a bad solution. It tends to be used more with enterprise types of implementations, healthcare systems like them, some banking systems like them. And again, I've seen telecommunications, that type of thing.
10:42
And I've worked with it too. When we were looking at doing a fresh implementation, my biggest thing that I tried to get at was this. I don't know, I don't like XML. And Samuel felt my first initial reaction, that the right one was to say, it feels kind of a little bit like this, or maybe more appropriately,
11:01
implementing Samuel feels a bit like that. Now how many people here that work with Samuel feel like this is what it's like to... Yeah, exactly. It's not even. Now we could, as a Rails developer, always just roll our own security solution as our fabric. How many people here are working in a service oriented architecture early?
11:25
Is anybody? Okay, a few. And out of that number, if you have security requirements, how many people have just decided, the hell with these standards, we're going to do it ourselves? Just roll our own. Okay, not many. That's probably a good thing actually.
11:41
The other approach we may have heard of is using a firewall. So what do I mean by that? How do we use that to protect our resources and protect our system? Well, in essence what we have is you've got only one set of words that's accessible to the outside world, the rest is not. And then you take in that tier and you put authorization and authentication in there.
12:04
So basically at that point, to enter into any piece of the application, you always have to go through this web tier and that will determine, do you need to authorize it into the resource? And if you do, do you have the right permissions? Only then does it let you through. To kind of give you a little bit of a better example,
12:21
this is how it might look if you've got your services built out a little bit. So the idea here is that you have an authentication, authorization layer in there, and you have to go through there to access anything else as a standard user. This isn't a bad solution per se, but it's got to be brought about.
12:40
And this is one we did consider when we were trying to break down our application. The biggest one is that you have a single point of success. Now this is another, a nicer way of saying that we have a single point of failure. If you look back at this, every request now has to go through that one layer
13:01
before it can access anything else in your system. If it goes down, your website goes down. It's a bad form of excuse, and I'm going to get into what I mean by that in a minute. And you are adding a layer of complexity to your architecture.
13:22
Okay, so with all this being said, if you have an application that's very right-centered, and what do I mean by right-centered? Well, you're basically, you have something like your wonder list, or you have a banking application, or you're writing your own version of the web gmail.
13:42
That actually may be an appropriate architecture, and if that's the case, probably this federation that we're going to talk about may not be the right thing for you. The problem that we had, though, was that we were basically, we were working with a property that had mostly read-only content. I would say roughly 90% of the content on this website is read-only.
14:04
So we're talking about serving up video assets, serving up articles, news articles, that type of thing. In addition to that, only about half of the assets on the website actually require some sort of authentication or authorization.
14:21
So again, you're looking at this single point of success going, does that make sense for us? The answer was yes. We said no, it doesn't. Because now, if that one layer goes down, we get a spike in traffic. The whole website just went down. Now yes, you could cloud front, you could do all this and other things with it,
14:41
but we said let's keep that layer out of our market. Another big thing with this too is we don't have, we didn't have insane security requirements. We're not dealing here with a HIPAA compliant website, or something that needed to be PCI compliant, or that's dealing with highly valuable information. It's more subscription-based.
15:00
Where if the website gets hacked, if somebody hacks around this authentication mechanism, it's not the end of the world. It will cost the company money, but you can recover. But more importantly too, we needed to scale. This particular website would get spikes in traffic. It would easily hit 30,000 uniques.
15:22
When I say 30,000 uniques, I'm talking, sorry, 30,000 occurrence per bus. So let's talk about OAuth. How many here, how many people here have actually worked with OAuth? In some way, shape, or form, okay.
15:42
Now, out of that group, how many of you have actually implemented an OAuth server, done a server-side OAuth implementation before? Okay, so a few. A lot of us probably do the client-side, but we don't do the server-side as much. Now, there are a number of different, basically, workflows with it.
16:03
And the biggest one is probably like the web was a web authentication token, I think, or something like that. Or, as I like to refer to it, sometimes it's like the bearer token. Now, what do I mean by bearer token? Well, it's not a token with Smokey the bearer. That was my first thing when I saw a writer, you know.
16:22
A token from your local casino. We're talking about a workflow for authorization. All right, so let's just trace through this for those that kind of never use this, or don't really understand this. Let's be your typical, let's try to explain it all.
16:40
It basically starts out with, when you've got a user, they say, I want to use this application. The request goes from the application over to the OAuth server saying, hey, the user wants to use me. Cool. So a redirect occurs where, basically, it sends a user off somewhere else
17:01
to be able to check to see if you actually want to authorize them to use it. It could be just a string login page, or what most people are familiar with is, hey, you're going to log in through Twitter, and this application is asking if you can log in through Twitter. You want to allow it to access stuff. You allow it. We say yes, and an auth code is returned.
17:24
Now, a key thing to understand with this workflow is when the auth code is returned, it's actually done as part of the URL in the redirect. And so what's important with that with the bigger token workflow, which is the one we ended up using, the one a lot of people use, is that because it's been returned in the URL,
17:42
it's not overly secure. And so most implementations will basically, they'll have to find out of some sort where it's actually only valid for a very short period of time, and it's a one-use. So then it's going to be very difficult for somebody to try to sniff the wire while you're doing that hack. From there, another request is made to the auth server to say,
18:03
hey, give me the access token based on this auth code. The access token is given back. And from there, as long as basically everything is kosher, from there we basically access our service, we pass in the access token, and providing that we have the proper permissions
18:23
and things like that, if you're a Rails developer, this is probably your go-to solution if you're basically implementing your own OAuth provider service. How many people have used Dorky?
18:42
Okay, so a decent number. Let's look at what it takes to actually use Dorky to put it on one of our services. We're going to use, we're going to do a gem, right? Our gem file. We're going to Rails generate,
19:01
or a keeper install, pretty standard stuff. And then we're going to do a Rails generate, or a keeper migration, and a rate of DB migrates. Now, when you're working with a monolithic application, probably none of this would even raise any red flags. Because you're saying, well, okay,
19:22
I already have a data source, so what's the two extra fields in the database? But when you're working with a service-oriented architecture, you may find that when you're breaking certain components out, that until you introduced DoorKeeper, you didn't need to have a data store, yet now, if you got DoorKeeper, you're using that as your OAuth solution.
19:42
Every instance, in other words, every service now has to have a data store. Okay, so we go on through, we're trying to figure out now, if we're bettering the system, we're trying to break it out. So we've looked at DoorKeeper, we're saying, okay, we'd like that, we want to use it,
20:01
but what are some other basic options? So we may just say, well, let's just sort of devise it. Well, actually, we're going to use DoorKeeper with it, along with devise, and put that on every service. You're still going to end up with the same thing as if you just used devise without DoorKeeper.
20:23
Lots of passwords, and let's say if you have four services, you have four services, this is basically the workflow that all of your clients are going to have to use with every one of these services, which from a federation standpoint is not great, because yeah, they kind of work the same, but it's also really clunky.
20:43
So how do we improve this? How do we basically get this to something that's a little bit more tenable? You might decide with DoorKeeper to use your own authentication mechanism. Yeah, you can throw clearance in there, something like that. That's really not going to help you.
21:01
You're going to end up with the same situation, lots of federation, lots of different services. So you could say, okay, let's use the DoorKeeper mechanism to specify our authenticator, and we could have some sort of a call that goes through. And it begins to help us. However,
21:21
what we found when we were implementing our solution was that it was kind of, quite often you end up having callbacks anyways when you're going out to another service with a login via devise, or something else like that. So we ended up going with Omni. How many people here have used Omni?
21:41
Okay, so a few. For those that don't know what it is, OmniAuth is basically a solution that allows you to easily hook in, easily, hook in other authentication mechanisms into your application. And there's a really nice plugin that allows OmniAuth and DoorKeeper
22:02
to work together. So by doing that, we end up with an architecture that looks something like this. So the idea behind this here is that we basically have, now we've separated out where basically our authorization
22:20
when we log in is off on a separate service here. We still have DoorKeeper on all of our other services, our microservices. At least we're not having to maintain multiple passwords for the application.
22:42
Now DoorKeeper is going off to a central server somewhere to at least log in. And from a usability standpoint, this actually might be enough for a lot of applications. We say, this is good enough. It's actually usable enough. And in fact, about a year ago we started this project, this is where we were at.
23:01
We basically, we, this was the best thing that was out there when we did a bunch of research, especially in Ruby. They were saying basically, oh, if you need to separate your OAuth services, go and install DoorKeeper on every single one of the services and then just use your centralized login solution. And there you go, that's it.
23:24
Your implementation, it might look something like this. So you've got your, basically what you want code to do is you create a module that's running with the strategies and you do a model load inside of there. You might have various things like Vulkan service, clean out service, I just made up some.
23:43
And then you configure OmniAuth to use basically those providers. And then a strategy implementation may look something like this. So you basically, the big thing to note with this when you're doing it is you've got a request phase and a callback phase. So in the request phase you're going to set up some things and then when you make a call over to whatever
24:02
service you're going to log into, the user's going to log into rather, you're going to have something to tell where to call back to. And how and when to send it. And when you get your callback page, you're going to process it. Were they successful? And then send them on and get them in all of them.
24:21
If you're not generating a lot of services, it's fine. You should just have to deal with maybe one. But when you start to get a lot of services, you'll end up really quickly having to manage all these different tokens in your client. And when we looked at this, I said, this is my reaction.
24:44
Why the hell do I have to manage all these tokens? Because the problem is you start adding services and now you're going to have to take it, you're going to have to manage a log out. You're going to have to somehow figure out a way to score the tokens. You're going to have to invalidate them. You're going to have to go back to all the services and it's like, hmm, that just didn't quite feel right.
25:01
And when you're working with service-oriented architecture, these are a lot of common patterns you're going to run into where it's like basically you're saying, oh my god, okay, initially we had one problem but then we start pushing the problem around. Okay, what if we do a little bit of
25:23
to make our architecture look something like this? So the big difference here is that instead of having basically every single one of these services having to buy this person or device having to put Doorkeeper on them, what if we put Doorkeeper on just one of them here?
25:44
Delegate calls from our other services over to that one? And in an ideal sense, if you're really following textbook microservices architectures, you're going to basically Doorkeeper, that service will then become something that only processes a lot of
26:01
style requests. And I say that meaning it's handling, it's just got Doorkeeper on there and it's whole mission is just managing that OAuth lifecycle. You still have some other services dedicated to logging in, you know, allowing other services in your RFIN the system basically
26:21
delegate calls over to Doorkeeper. How does that look? In essence, what we have here is now, on our now Doorkeeper service, we no longer need to install the Doorkeeper gem. We no longer have to have a database.
26:41
What we do instead is we basically, in our application controller and this is very similar to what we actually ended up putting in production we just basically say, okay great let's take and let's create a small filter. And you just put a before filter in your controller and if you look, all we're doing with that one is we're saying we're looking at the header
27:01
and this is just standard OAuth, basically as part of the standard you put in the request header an authorization token. Since they're under authorization we look at that and then providing this there, send them through to, send a request through to our Doorkeeper service
27:23
to see if they're basically authorized or not we may send some metadata back and providing that everything works, we let them through and if it doesn't if either the user is not authorized or it's an invalid token or something else like that, we 401 them and from there all the requests either
27:41
the user can then, we have the client the standards that OAuth provides, I can either go through and say we're going to now go back and we need to refresh our token or maybe we need to log in or do something like that we still have a problem with single point success with this. We're
28:01
doing better to look back at this now, especially with the architecture that we have for this application 50% of the reads needed to go directly to the services and didn't require authentication but the other 50% did not so we have a bottleneck where every single time
28:21
something requires authentication it's still going back to the doorkeeper to see the service it has in the doorkeeper to see if they can get interference under load, obviously that's going to cause a problem for us
28:41
so what if we try something a little bit different, we give some cash delegation to be honest with you, I'm not even sure if this is an official term or not, this is kind of what we ended up calling it so what do I mean by cash delegation? Oh that's right the first thing we need to actually mean is this
29:07
our architecture looks very similar to how it was before but the difference is now basically we've added another layer, or not a layer really but we've just added one little thing to our services and that is that we're cashing
29:21
the tokens now in each one of these services so the idea behind this is that basically instead of having instead of just sending the request all the time back to doorkeeper our doorkeeper service, we say hang on a second if we've already received a request with the
29:41
same token that we're receiving right now and it's within a certain period of time just let them through we throw an in-memory database on the services and now in essence what we have is we basically we've kind of got the best of both worlds where we have one service whose primary mission
30:01
now is just to take care of our OAuth requests and handle all the OAuth stuff we have another service that's only dedicated to one thing and one thing only in life and that is handling login basically authentication and all that and we basically our other services only have to
30:22
concentrate on what they're designed for our implementation may look something like this and again this is actually very similar to what we're actually using in production on the system and you'll notice the only difference is you just have a redis you have to check in redis first
30:40
to see if we've seen that token and then we check to see if it's expired yet and if it has we let them through otherwise we don't everything else is exactly the same with this solution we load tested, we're in production right now, we can hit spikes with 30 housing
31:01
currents and the thing doesn't even break out sweat when we run this through things like lits and stuff like that we've been able to get much higher numbers and so we feel very confident that this will scale and it has so far and compared to our monolithic application this did work for us
31:21
so success this is how we solve this problem with that being said a few reflections on this I guess are in order because we're obviously talking about how do we take and scale this thing and everything but
31:40
I don't know how many people really enjoy the process how many people really enjoy using Omer more importantly how many people found that it was easy to use you know one person that's exactly it we have a single masking disc up in the front other than that nobody does
32:01
and that's been the exact experience so every time that like I've had to go in and look at this after the fact like a couple months after like two months after we first implemented we have to treat a couple things or whatever or we need to add another service to it I always go like this
32:20
this is honest to god I mean even after being pretty deep in this and doing a hell of a lot of research and yes I'm not a security expert or anything like that I come back and I go god this is so painful now yes somebody can say yeah but it's a stand or you hear that sometimes and then I've heard people suggest
32:40
basically JSON web tokens that might be something you know they'll say if you roll your own solutions it's going to be less secure and actually overall I wouldn't agree with that minus with the one caveat being unless you know what the hell you're doing and you're a security expert then you probably would roll something better than solutions it's not anything against the team
33:01
that's developed doorkeeper oauth or anything else like that but it's just it's kind of one of those things where it becomes a standard but keep in mind you know java web tokens and things like that are also earlier probably the other biggest thing that we found was that
33:20
default doorkeeper can be extremely insecure too and let me explain how this has happened because we actually didn't have this occur bad confessional but luckily nobody knows which sites this was on we when we did our first implementation using basically creating oauth service with doorkeeper doorkeeper gives you this really nice sort of
33:42
web interface right and you can basically create new authorization tokens with it and do different things like that and you'll get what you'll find what we found so we have that we looked at that and then decided to go with a different mechanism for it and said okay great let that go
34:00
get the rest of our implementation and forgot to turn that off and so for about a month it's sitting there in production and luckily nobody the users for this website are not that sophisticated we don't have any evidence that anybody actually got it or did anything with it but that's like dammit we shut it off but it's real easy to do and that's probably
34:20
one of my biggest takeaways in general probably the biggest like if you were to do a retrospective on this is that this is what it feels like when you're trying to put security into a federated application it feels like you're trying to create a lock and they're getting you this okay go create a lock with that one well I'm not looking for good locks
34:41
that's right I don't do a lock I just want to secure my thing I mean I just want this I want to be able to just install it in a house like this and have something I can use but it's just so often it's like and it's not right now what I think is one of the better solutions with it I think it's I wish there was something better if it was like the best people that we had
35:03
but it makes me wonder if there is something better but you know maybe it is we just need to evolve things because unfortunately unless you're a security expert it's going to be probably really easy to add a lot of holes to your application and if you have something that has heavy security concerns with it where you might
35:20
want to use something that's more federated it's going to be really difficult at best so at any rate that's all I have open the floor to some questions here