Web API Authorization & Access Control – done right!
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 170 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/50593 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
ComputersicherheitUnternehmensarchitekturClientBildschirmmaskeEinfache GenauigkeitClientDifferenteKartesische KoordinatenGoogolBildschirmfensterDienst <Informatik>ComputerarchitekturNetzbetriebssystemPasswortResultanteSchlüsselverwaltungComputersicherheitGeradeComputerspielIndexberechnungTypentheorieFlächeninhaltServerService PackKomplex <Algebra>UnternehmensarchitekturHumanoider RoboterInformationsspeicherungTermSchlussregelWeb ServicesPunktEreignishorizontRechter WinkelSoftwareentwicklerTwitter <Softwareplattform>ForcingSichtenkonzeptVideokonferenzTelekommunikationExplorative DatenanalyseNotebook-ComputerÜberlagerung <Mathematik>BitProtokoll <Datenverarbeitungssystem>QuaderAuswahlaxiomPhysikalisches SystemMustersprachePay-TVSoftwareFreewareDreieckMulti-Tier-ArchitekturCASE <Informatik>Domain <Netzwerk>DatenbankMultiplikationsoperatorMobiles InternetVirtuelle MaschineValiditätApp <Programm>Prozess <Informatik>Befehl <Informatik>Geneigte EbeneGamecontrollerArithmetisches MittelSymboltabelleIdentitätsverwaltungYouTubeBenutzerbeteiligungKerberos <Kryptologie>AuthentifikationEin-AusgabeNichtlinearer OperatorFront-End <Software>ZahlenbereichComputeranimation
09:24
Komplex <Algebra>AbstraktionsebeneAutorisierungFramework <Informatik>Protokoll <Datenverarbeitungssystem>Mobiles InternetStandardabweichungServerClientGeradeToken-RingE-MailTelekommunikationVirtuelle MaschineAuthentifikationToken-RingBildschirmmaskeTabelleWort <Informatik>DatenflussKartesische KoordinatenProtokoll <Datenverarbeitungssystem>Zentrische StreckungDomain <Netzwerk>Kontextbezogenes SystemPunktDifferenteVerzeichnisdienstCASE <Informatik>Nichtlinearer OperatorUltraviolett-PhotoelektronenspektroskopieAlgorithmusDienst <Informatik>BildschirmfensterTypentheorieComputersicherheitInformationRoboterServerClientOrdnung <Mathematik>UnordnungDatenstrukturAutorisierungZeichenketteFlächentheorieKategorizitätExogene VariableSoftwaretestZufallsgeneratorExpertensystemGoogolGamecontrollerBrowserKomplex <Algebra>SoftwareentwicklerBenutzerbeteiligungElektronische UnterschriftVorzeichen <Mathematik>Deskriptive StatistikMereologieEinfache GenauigkeitAuswahlaxiomPasswortFront-End <Software>TelekommunikationWeb-ApplikationCookie <Internet>VersionsverwaltungDateiformatLoginQuick-SortSkriptspracheSchreib-Lese-KopfEntscheidungstheorieMultiplikationsoperatorAggregatzustandSchreiben <Datenverarbeitung>Open SourceSchätzungExistenzaussagePhysikalisches SystemRechter WinkelVirtuelle MaschineLesen <Datenverarbeitung>VierzigImplementierungOffice-PaketStandardabweichungExplorative DatenanalyseWeb-SeiteVerschlingungÄhnlichkeitsgeometrieMaschinenspracheLie-GruppeQuellcodeMathematikURLInternetworkingMusterspracheARM <Computerarchitektur>Zellularer AutomatEndliche ModelltheorieCLISelbst organisierendes SystemHardwareComputeranimation
18:49
IdentitätsverwaltungServerAutorisierungTelekommunikationVirtuelle MaschineDatenflussClientSynchronisierungBildkorrelationKonvexe HülleZeichenketteVirtuelle RealitätInnerer PunktOvalInformationsmanagementVarianzHauptidealPhysikalisches SystemRechenwerkVerschlingungData Encryption StandardDebuggingPhysikalischer EffektKreisringToken-RingPasswortClientAutorisierungDienst <Informatik>ZahlenbereichDigitales ZertifikatCASE <Informatik>ServerBenutzerbeteiligungVersionsverwaltungZweiÄhnlichkeitsgeometrieStandardabweichungIdentitätsverwaltungSystemaufrufElektronische UnterschriftPunktKartesische KoordinatenMereologieZeichenketteAlgorithmusTypentheorieComputersicherheitExogene VariablePublic-Key-KryptosystemKlasse <Mathematik>EinsWrapper <Programmierung>MaßerweiterungMiddlewareApp <Programm>AdressraumGüte der AnpassungSoundverarbeitungSpielkonsoleE-MailOffene MengeGamecontrollerInteraktives FernsehenEntscheidungstheoriePortabilitätDemo <Programm>SoftwareTelekommunikationAuthentifikationOpen SourceOrtsoperatorQuaderGeometrische FrustrationRückkopplungSchreib-Lese-KopfSondierungMultiplikationsoperatorZufallsgeneratorDatenverwaltungService PackDatenflussHochdruckBildschirmmaskeArithmetisches MittelKategorie <Mathematik>KontrollstrukturOffice-PaketMathematische LogikSelbst organisierendes SystemMusterspracheGeradeSichtenkonzeptSchreiben <Datenverarbeitung>CodeComputeranimation
28:13
ClientDatenflussPasswortToken-RingExogene VariableAutorisierungServerSynchronisierungBildkorrelationLokales MinimumKonvexe HülleDatenverwaltungMenütechnikDienst <Informatik>App <Programm>InformationSpieltheorieStellenringMobiles InternetCodeComputersicherheitTypentheorieToken-RingDemo <Programm>FlickrExogene VariableCookie <Internet>DatenfeldServerKartesische KoordinatenAuswahlaxiomProdukt <Mathematik>ClientPasswortSoftwareentwicklerLoginBenutzerbeteiligungDatenflussMAPWeb SiteWeb-SeiteTwitter <Softwareplattform>Front-End <Software>App <Programm>AutorisierungDienst <Informatik>MathematikAuthentifikationDifferenteE-MailPunktFacebookTVD-VerfahrenSystemaufrufMultiplikationsoperatorInhalt <Mathematik>BrowserTouchscreenARM <Computerarchitektur>EinsEigentliche AbbildungInverser LimesPhysikalisches SystemMechanismus-Design-TheorieRechter WinkelVektorpotenzialProfil <Aerodynamik>ComputerspielCoxeter-GruppeVerschlingungPhysikalischer EffektSmith-DiagrammMaschinenspracheVolumenvisualisierungMusterspracheIndexberechnungComputeranimation
36:51
AutorisierungClientServerGoogolSigma-AlgebraGammafunktionVakuumTwitter <Softwareplattform>BewegungsunschärfeStatistikToken-RingExogene VariableKommensurabilitätURLLoginRechenwerkClientServerBrowserKartesische KoordinatenDatenflussVirtuelle MaschineHash-AlgorithmusWeb-SeitePasswortInhalt <Mathematik>Ein-AusgabeSichtenkonzeptHumanoider RoboterGeradeToken-RingAliasingLoginTouchscreenSchreiben <Datenverarbeitung>ZeichenketteLesen <Datenverarbeitung>AuthentifikationOffene MengeAbfrageQuellcodeZahlenbereichCodeDienst <Informatik>EntscheidungstheorieMaschinenspracheBenutzerbeteiligungPunktInternetworkingFacebookInformationAutorisierungTypentheorieMultiplikationsoperatorBildgebendes VerfahrenURLBitPhysikalisches SystemUmwandlungsenthalpieEinsTwitter <Softwareplattform>ParametersystemSchnittmengeApp <Programm>Prozess <Informatik>SystemaufrufImplementierungGoogolRechter WinkelMehrrechnersystemFreewareAppletSkriptspracheProfil <Aerodynamik>FlächeninhaltProtokoll <Datenverarbeitungssystem>Taylor-ReiheTopologieVorzeichen <Mathematik>ARM <Computerarchitektur>Computeranimation
45:28
Lokales MinimumServerAutorisierungToken-RingKanal <Bildverarbeitung>Mechanismus-Design-TheorieClientCookie <Internet>DatenflussCodeAusgleichsrechnungStapeldateiTelekommunikationWeb-ApplikationHash-AlgorithmusToken-RingServerClientKlasse <Mathematik>CodeRegulärer Ausdruck <Textverarbeitung>Kartesische KoordinatenAuthentifikationBenutzerbeteiligungBrowserAutorisierungPhysikalisches SystemBildschirmfensterTwitter <Softwareplattform>Graphische BenutzeroberflächeCookie <Internet>Humanoider RoboterBitComputersicherheitFront-End <Software>Inhalt <Mathematik>AbfrageDatenflussEreignisdatenanalyseSoftwaretestVirtuelle MaschineAggregatzustandDienst <Informatik>TouchscreenLoginRechter WinkelOffice-PaketMereologieProzess <Informatik>Serviceorientierte ArchitekturWort <Informatik>MultiplikationsoperatorGrenzschichtablösungSprachsyntheseComputeranimation
49:49
ServerAutorisierungClientLoginFacebookToken-RingRandwertExogene VariableDienst <Informatik>VerzeichnisdienstAutorisierungClientFacebookQuellcodeGatewayStichprobenumfangMultiplikationsoperatorBitServerStellenringArithmetisches MittelLoginAggregatzustandPhysikalisches SystemGeometrische FrustrationWort <Informatik>ComputersicherheitDatenflussToken-RingKontextbezogenes SystemRandwertComputeranimation
52:17
AutorisierungServerFramework <Informatik>Token-RingZugriffskontrolleClientQuellcodeInformationIdentitätsverwaltungClientKartesische KoordinatenIndexberechnungBildschirmfensterVektorpotenzialErwartungswertPhysikalisches SystemGatewayModallogikCodeServerTypentheorieAutorisierungDienst <Informatik>Kategorie <Mathematik>GeradeRechter WinkelToken-RingAttributierte GrammatikMereologieVerzeichnisdienstRandwertSchlussregelEnergiedichteMusterspracheEinsNP-hartes ProblemBenutzerbeteiligungAuthentifikationComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
Cool, let's get started. So, yeah, the talk is called Doing It Right. That's obviously a bold statement, yeah? I'm not claiming that I'm doing everything right. But I want to show you a number of common patterns that people use, that I have used in the past, that work for securing web APIs, cool.
00:24
So, a little bit of background, so where I come from, or when I started doing security, I was in this nice, wonderful world of the enterprise, right? Where everything was being taken care of. Does anyone know what this triangle means?
00:42
It's like Active Directory, that's the official symbol for Microsoft's Active Directory, or at least it used to be 10 years ago, yeah? Where, you know, everything has been taken care of. We have immensely complex security protocols going on there, Kerberos and LDAP as data access, and we managed to compress it down to a single checkbox called
01:01
Enable Windows Indicated Authentication, done, okay? Oh, and also that the mindset was a little bit like, you know, you enter your company, you're using a chair that is owned by the company, you're logging on with a machine that is owned by the company. Actually, your identity is owned by the company
01:20
from nine to five, right? You're using the domain account to log on to their network. You're talking to servers which are owned by the company, and everything has been taken care of by a domain controller owned by the same company. So it was kind of like a trusted subsystem in that we have lived where everybody more or less trusted each other, okay? Then, you know, then the whole era came
01:42
where we wanted to talk to other triangles out there, yeah, not just our own, and we created these immensely complex protocols like SOAP and WS-STAR and XML and SAML and everything just to achieve that we can talk to other people outside of that blue line, yeah?
02:01
And it turned out sometimes this even worked, no? And then, you know, the life-changing event for security guys but also for many, many other people was this, right? Suddenly, there was a device which, you know, basically didn't care at all about the enterprise, right?
02:21
There was no Kerberos, no SOAP, no SAML, no WS-STAR, no, not even Windows, right? And I think it's funny that still on YouTube there's this video where Steve Ballmer says like, this iPhone thing will never take off. We don't have to care about that, yeah? It turns out it did take off, yeah?
02:43
And now we have an ecosystem of devices which are not Windows integrated authentication, yeah? Where we have scenarios where, you know, sometimes you want to integrate this into your enterprise, sometimes you have scenarios where you want to integrate such a device without any enterprise, yeah?
03:01
And this all led to much more smaller and more lightweight architectures, yeah? Because basically, the only thing that these, in that new world, we can basically rely on is HTTP and JSON and HPS, of course, yeah? And finally, reducing from this very big, you know,
03:24
technology stack to a very small one resulted into something what we call today modern applications, yeah? And the mindset when writing these modern applications is a little bit different than back in the enterprise days. And you basically have three buckets here.
03:43
One are the users, obviously, the humans that want to use your services. We have the services itself, and they are often called web APIs these days. You know, that's a kind of a hipster name for writing a web service, but many people are afraid of the term web service these days because it could mean soap, yeah?
04:02
And the thing that in this newer modern mindset was introduced is so-called clients, okay? So as I said, in the enterprise world, you know, everything was kind of trusted, right? You were using a client application, running on a client operating system,
04:21
accessing services all owned by the same entity, okay? But things have changed, yeah? You might write a service that is consumed during daytime by your users using a laptop in their company, and once they leave, you know, at five o'clock, they leave the company, they are starting using this device
04:41
to access the same set of services, okay? You might be writing public APIs where you don't control at all who is connecting to your services in the sense of which type of clients and applications. So I try to be very specific, yeah, during the talk.
05:00
Users are the carbon-based life forms in your system. Clients are the silicon-based life forms, okay? And there's a difference, yeah? You might not trust every user, you might not trust every client, okay? And obviously, the other thing that's much different and that Steve Ballmer didn't see coming, I guess,
05:23
is that now we are writing these applications in very, very many technologies, right? There's not only Windows anymore, there's iOS and Android and Node and HTML and even other stuff, okay? So what are the security requirements of such architectures?
05:44
It's pretty simple, yeah? Users, of course. The question a user should ask himself is, do I trust the app I'm currently using? Yeah, I mean, you go to the App Store, you download something, and installing this something
06:01
basically means you trust the application, right? Because you installed it on your device. Again, there's more choice today. You can easily use five different Twitter clients, right, to access the same Twitter backend. So you have a choice, yeah? Some may work well or better than the others, some you wanna prefer, and so on.
06:21
The other thing is, what do clients care about is, well, typically they care about who is my user, okay? And when they establish that, how can they transfer that identity and that communication securely to their backend?
06:41
At least they should be concerned about that, yeah? And the services, they typically care about who is the user, yeah? You wanna be able to know who the user is. Is it my user, is it a user from Google? Do I have to make it my user after he signed in with his Google account, for example? What is this user allowed to do? Is he premium subscription or just on the free tier, yeah?
07:05
And also, who is the client, yeah? So maybe you're having an architecture where you have your flagship application, which can do everything in your service backend, and you might have your light mobile API, for example,
07:23
and they shouldn't be able to do everything, okay? Again, that is something that you might wanna do, and that's why you might wanna care about who is the client. Is this client registered in my system? Do I even allow that? Is he licensed, yeah? Is it written by us, by a trusted partner,
07:40
or is it just some third party that I don't even know about? So these are the requirements for these newer types of architectures, and Windows can help here, but it's not the answer anymore because there is so much more than Windows, okay? So but that stuff can still become complex, right?
08:00
I mean, I have many customers that start with these newer application types, and I said, okay, easy. We have one type of user and one service, and we're gonna write now a client for that, okay? And what they often start with is something they understand, is something like username password authentication, for example, yeah? So that the user has a password,
08:21
let's send it to the server, validate it, and if it's okay, then the user is okay as well, okay? Obviously, we all know that password-based authentication with business services has become an anti-pattern, right? I mean, the way HTTP works is that you have to send that credential on every single request to your service,
08:41
which basically means, from a developer point of view, either you ask the user for his password for every single request, or you have to store it, okay? Storing, as we all know, is pretty bad. We have to store it in a way that we can get back to the clear text, which often means let's store it in clear text there.
09:02
So the other thing is obviously the server, the backend, has to validate that password on every single request, yeah? And the way we should store passwords today would be that typically, the common rule today is a password validation process should take around half a second
09:21
to slow down brute-forcing attacks against our password databases. So we do immensely complex stuff like hashing, creating a random number, appending that, hashing, hashing, hashing, like 40,000 times. Around that takes roughly half a second on current hardware, yeah? So in other words, if you would do that right,
09:41
every request would take half a second plus the actual business operation that you're doing on top of that. So it doesn't really scale this model, okay? The other thing is it quickly becomes more complex, right? The first application was a success, we need a second one, okay? Suddenly you have the same user using two different applications,
10:00
talking to the same backend, then we have a second backend, and suddenly we end up with something like this, okay? And then, you know, we wanna maybe integrate third parties, that might be stuff like social or business partner backend, for example, either you wanna maybe aggregate data, maybe you wanna support them for authentication,
10:22
and this pretty quickly becomes a big mess, okay? And the thing that Microsoft did 12, 14, 15 years ago to bring order to the chaos in their Windows world is they introduced something like a traffic cop,
10:42
a guy that knows about clients and services and users, and that was called the domain controller, right? And a very similar idea applies here, once you have a critical mass of services and you wanna bring order to the chaos, and that is basically a thing called the authorization server. That is, think of it as a domain controller thingy but made for the web, for the HTTP age, if you like, yeah?
11:05
And that is basically what is specified by a standard called OAuth, okay? So OAuth is a document, an RFC, an official standard, which talks about how to implement secure authorization
11:21
in a simple, always be cautious when you hear the word simple somewhere, but standard, always be cautious of that as well, method for different types of applications, web, mobile, and desktop, okay? And if you click that link, you come to the official IETF page, which says the same thing in much more words
11:41
and a courier font, okay? But the idea that OAuth brings to the table is, is to not directly do security between the client and the resource, but have something in between that helps establish the security context between the parties. So in the OAuth approach,
12:02
basically what you have is this thing called the authorization server, okay? And you have your APIs. And think of that like you have your many, many APIs you've written, you give them names, if you like, yeah? And they are called scopes in the OAuth world. Yeah, so for example, Google has a calendar API, so they have a scope for that, something slash calendar,
12:23
or something slash Gmail, yeah? So that identify us for these APIs so that clients can ask for access to these APIs, okay? And basically what a client is doing then is he uses this OAuth protocol to go to the authorization server,
12:41
say hey, I'm client one, you know me, I have registered with you, please give me an access token that I can use to access these services that I'm asking for, okay? So what then will typically happen is the authorization server will authenticate the user, right?
13:01
It needs to know who the user is. It makes sure it knows who the client is. Then it can look up, is the client allowed to access these services? And if yes, we give him back an access token, okay? From that point on, the client is done with any sort of security, yeah? No passwords anymore, nothing.
13:22
He will hold on to the access token and use the access token to access the services. Pretty much like cookies, right? You go to a forms, to a login form on a website, you type in your name, you get back a cookie in return, same thing, just different technology, okay? These access tokens,
13:41
they can come in different shapes and forms. Some, like Google for example, they just give you like a quit, a random number if you like, yeah? And whenever you access the APIs, they call back to the authorization server, say hey, I have this quit here. Is this a valid access token for my service? And then the server says yes,
14:01
that's fine, let him in, okay? This is often done to make the tokens really small on the cable, and also to allow immediate revocation of tokens, right? So let's say it turns out that this bot guy here is a scammer or something, yeah, and Google deactivates his account, he wants to immediately deactivate access
14:21
to all services this might have asked for, okay? That's why people sometimes use reference tokens. The opposite of that are called self-contained tokens, that's basically a data structure that contains information about the client and the user and the scopes he has access to,
14:40
and there's no back-channel communication between the APIs back to the authorization server. It depends on your scenario which is the better approach. Many people these days use this thing called JSON Web Tokens, which is a standard token type for self-contained tokens, yeah? So the authorization server creates this data structure,
15:02
and JSON Web Tokens have a header, basically saying something like, yeah, I'm a JSON Web Token, and that's the algorithm you can use to verify my signature, this thing is signed, right? To make sure it's coming from a trusted source, that no one can tamper with it. And the second part are claims,
15:21
basically saying like, where is this token coming from? How long is it valid? For which backend is it meant to be? Who is the user? That's the subject claim, the S-U-B, yeah? And who's the client? That's the client ID. And the scopes that the client has access to, so yeah?
15:40
So it might be that this client has only access to the read-only version of your API, whereas other clients have access to the read-write version of the API, for example, okay? And this is a pretty nice token format because it's pretty compact on the cable, right? So you take the first part, base64 encoded,
16:02
put a dot, take the second part, base64 encoded, add a dot, and then you take the first two parts, sign them, and append the signature as a base64 string at the end, okay? That is a pretty common choice for self-contained tokens.
16:21
Okay, cool. So that's the idea, right? Instead of putting the security part into the actual APIs you're writing, and you will be writing many APIs and you will be replicating that security over and over and over again, is to put the security part into this thing called the authorization server. You have a single responsibility design here
16:41
because this thing has only one job, namely creating security tokens for your APIs. Much better for things like penetration testing as well. You'll be choosing the attack surface and the complexity of your services. And actually can leave the service, you know, the developers that write services are typically not security guys.
17:01
They are experts in their domain, in their business domain. So why do you want to burden them with all the weird security stuff? So that's the idea, okay? And this idea is around for a very, very long time. As I said, Active Directory works exactly like this, but designed for intranets, yeah?
17:23
And we've been using the OAuth approach for the last couple of years with many, many customers, and it worked out really well, okay? So I want to show you some of the common use cases and how they work, and have a look at, you know, maybe the ups and downs of that as well. So when you're reading the OAuth specification,
17:42
which is actually not very exciting to read, they talk about things called flows. And flows are basically descriptions of how various types of clients can request access tokens from an authorization server. And basically, the big categorization here would be
18:02
machine-to-machine communication, that's where no human is involved at all, yeah? Then there are applications which are running, like native applications, applications which are running in the browser, and now it becomes tricky. Are they running in the browser and are written in JavaScript and are run mainly on the browser?
18:21
Or are they applications which are web applications which mainly run on the server, okay? And that's another technique. And there's also federations, so basically when you want to cross domain boundaries, like you're having a business partner that you want to trust and want to allow them into your system, how do you deal with these different trust domains,
18:44
how that works, okay? So flows are more or less patterns, if you like. We have done, last year, I think, I released this thing called authorization server, which was an OAuth 2 implementation, open source. And for the last three or four, no,
19:04
rather six or seven months, I've been working on this thing called Identity Server Version 3, which is like the next version of authorization server, which is OAuth 2, OpenID Connect, and Federation, and Account Management, and all kinds of stuff.
19:20
I wanna do the demos today with the new one, because that's just more exciting, yeah? But both are available on GitHub, it's free for, you can use them for free, it's open source, okay? Cool. So let's start with the simplest OAuth interaction of them all.
19:41
Think of you having a service that wants to communicate with another service, okay? Like in your data center, service to service communication. There's no human involvement, which makes it easier, as always, yeah? And the way this works is, and there are two competing mindsets here.
20:00
Some say, for this scenario, I wouldn't use OAuth, why not just have a shared secret between the service and the other service, and they can use the two authenticators with each other? That's one way to go. I don't like it too much, because I rather have a shared secret between a service and an authorization server as between services. Makes it easier to manage, in my opinion, yeah?
20:21
So I would rather use the OAuth approach here. And the idea is simple. The service basically goes to the authorization server, there's an endpoint called the token endpoint, yeah? It authenticates with the authorization server, so when you register a client in OAuth, you give him a so-called client ID
20:41
and the client secret, yeah? Which are basically, you know, random numbers, yeah? No humans involved, excellent, yeah? I mean, we can use pretty good passwords. And basically, then the client goes to the authorization server, says, hey, give me access, or give me an access token that I can use to talk to service X, okay?
21:03
A scope, you know? And then again, the authorization server can run some logic, make sure that the client's actually allowed to access that service, and answers with a JSON-encoded response, which contains the actual access token. That's it, as easy as that, yeah?
21:22
The XPIAS in tells the client how long the access token will be valid, so it can do its own bookkeeping to figure out when do I need to get back to the authorization server to get a new token, okay? That's all there is to it, yeah? And NT server version three is built, you know,
21:45
using the latest and greatest Microsoft technologies, Owen, Katana, you may have heard of that, but the nice side effect of that is we don't have a dependency anymore on IIS, so you can run it on your web server, but you can run it in an NT service, you can run it, as I do right now, as a console application, okay?
22:03
So, let's run the actual, oh, let's have a look at the client first. So, basically, when you're starting using this approach, is that big enough? Yeah? Good. You basically divide your applications in two parts.
22:22
The one part is how you request the token, and the other part is to use the token, okay? So, that's the request token here, and that's the call service, which basically uses the access token which comes back from step number one, okay? Requesting a token, as I said, is as easy as hand-crafting this HTTP post, okay?
22:44
Which anybody can do. That's the other nice side effect of OAuth. It runs on any client that has an HTTP stack, yeah? I mean, we've built software for set-top boxes, for example, or for Raspberry Pi, which, you know, can totally do that because, you know, it's just HTTP, you know?
23:01
Nevertheless, I've written a little wrapper class here called the OAuth 2 client. You pass in the address of the token endpoint, you pass in your client ID, you pass in your client secret, you tell him which scopes you want to have access to, and it returns a token response, and on the token response, you have the access token, okay?
23:22
So, that's the client. How does the server look like? Since we're using JSON Web Tokens, which is a standardized format, there's actually the standard middleware for Microsoft that allows you to validate these tokens, and that is basically this guy here, you're writing your normal startup class,
23:42
you say app.useJSONWebToken, you pass in, what is the name of the issuer that I expect this token to come from? What is the name of the audience that I expect this token to have in, and what is the public key that allows me to verify the signature on this JSON Web Token, okay? These are the three things you need to know, yeah?
24:02
That here is for self-contained tokens, this one here. There's also another one here for reference tokens, where you basically point to the endpoint in identity server that you can send the token to, and it makes sure the token is valid and gives you back the claims, okay? So you can use either of them, they're just middleware.
24:22
Let's run that, okay? Let's run our client, and it's not very exciting, it's only exciting for security geeks, really. That's the token response.
24:41
You see here's the access token, that's this opaque string. That's the XPIAS in, and for debugging purposes, I decoded the JSON Web Token, you can see what's in there. There's the type is JWT, the algorithm in this case is RS256, which is RSA, using a SHA256 hashing algorithm,
25:03
and the X5T is the X509 certificate thumbprint that was used to sign the token, so the recipient could now go into his certificate store, look for a public key with that thumbprint, use it, and validate the token using that, okay? That's the issuer name ISS,
25:21
that's the audience, or AUD, so you see they wanna keep it short. NBF means not before, EXP means expiration, and these are by the way, that's epoch time, that is the number of seconds since the first January of 1970. That's used to get around all of these weird daytime encoding issues cross-platform.
25:43
Here's the idea of the client, the client name if you like, and here are the scopes that the client has access to. That's all there is, and when I now look at my service, this simple controller here, that I'm calling now,
26:02
so when the token arrives at the service, the middleware does its job, it validates the token, and then turns that token into a claims principle, so basically what you can do now is, from the controller, you can say user, that's the .user property, cast that to a claims principle, and then you have all the claims that were in the token
26:21
as part of the claims collection in .net, okay? And then you can access all the data and make authorization decisions based on that. And what this thing does, it just echoes back the claims, right? So we can look through the eyes of the server, if you like, to see what's in the token. So when I press enter, these are the claims,
26:40
and these are exactly just the claims that you've just seen, okay? A useful tool, actually, that I sometimes use, let's put a breakpoint here,
27:01
and let's go to the access token. There's a nice website written by the Auth0 guys. It's called shot.io, and in here you can paste your JSON web token, and they decode it for you, so again, for troubleshooting purposes,
27:20
when you wanna make sure everything that you expect is in the token, and again, you're seeing the same thing here, that's the header, that's the claims, that's the header here, the blue part are the claims, and the red part is the signature, okay? So a useful tool, good.
27:41
So how does the client actually use that token? Basically, by putting it on the authorization header and sending it along to the service backend, and again, there's a little extension method here for HTTP client called setBearerToken. You pass in the token string that sets the authorization header, and you are done from a security point of view, okay?
28:02
So that's the simplest possible overall flow, and all the other ones follow a similar pattern, yeah? Okay, so that was really, really easy because there is no human involved, yeah? As soon as humans are involved, there are more considerations to make here, really, yeah?
28:22
And again, there's one flow that is called the resource owner password credential flow, yeah, very long name, but the whole idea is basically that you're writing an application, and the application brings up its own login dialog, and the user types in his name and his password, yeah, and then you hit enter,
28:41
and what the application would do is it would send that password and that username to the authorization server, yeah? Again, there's a scope involved, obviously, for making sure we are accessing the right service, and then the authorization server will turn that username and password credential into an access token, yeah?
29:02
And from that point on, the client can forget the password, yeah? It doesn't need it anymore because we're now using the access token instead, okay? So let's have a look at that. It's just really a small variation only.
29:23
You see again, same pattern, request token, call service. This time, the call service is a little different because we pass in the username and the password and the scopes and get back the access token, but from that point on, it's all the same. Once you have the access token,
29:40
how you access the service doesn't change anymore, okay? We can run that. You see a slight difference here in the claims. We now have a so-called subject claim, and you always have a subject claim when there is a human involved, okay? The user that signed on was Bob.
30:01
That's why the subject claim says, okay, that is the name of the user, okay, or the user ID, depending on your system. But again, as I said, from that point on, everything works the same, yeah? The scopes are in there and so on. Now, many people like this flow
30:21
because it's very much like what they did since ever. We are writing our own login dialogue and we are collecting some credentials from the user and then we are turning that, which is new at that time, into a token, yeah? And that is what OAuth calls the flow for so-called trusted clients.
30:41
Why trusted? Well, because the actual client application can see the user's password, okay? Which might not be an issue for you if you are the developer of the service and of the client application, so who cares? I can look in my database, yeah, if I want to. But this does make a difference when the client application is not written by you
31:02
and maybe written by someone else, maybe either a company you're working with or maybe App Store, public API scenario, some company that you don't know at all, yeah? So you might not want that these client applications,
31:21
which you don't know the developers, you don't trust the developers and so on and so forth, can see the passwords of your users, okay? Twitter, for example, I know the time, like, I don't know, five years ago where everybody was doing Twitter demos on stage
31:41
because it was so easy, right? You wrote a little HTTP, you added the name and the password on the header and just got back the tweets. And Twitter realized they now have these millions of Twitter clients out there and all of them store usernames and passwords locally on devices, and they don't want that, yeah? They only want that their passwords
32:01
are living on the Twitter backend and not on some untrusted devices, yeah? That's why they turned off the endpoint and the demos stopped as well, yeah. The nice thing about this flow is, obviously, even if the client can see the password,
32:22
it doesn't have to store the password anymore. Yeah, because we now can use the access token. The access token is typically time-bombed, yeah? It has a finite lifetime, yeah? Depending on you, basically, it could be a really short access token,
32:41
like one hour or 10 minutes or it could be something really long, yeah, like, forever. Whenever the access token expires, the user has to reauthenticate, okay? So that's the compromise between security and productivity. Google, for example, they made the choice that they give you authentication cookies for 14 days,
33:04
so the user has to reauthenticate every 14 days. That's their decision, okay? There's another feature in OAuth which is sometimes used, it's called the refresh token, and the idea is that the access token itself is short-lived, yeah?
33:20
But there's another token, the so-called refresh token, that you can use to request new short-lived access tokens without having to present the user's credentials back to the server. So think of it as sliding expiration in cookies, yeah? And the way this works is that the token response
33:41
basically has another field called refresh token. You would store the refresh token as well and then could basically go back to the authorization server present the refresh token, reauthenticate the client, not the user in this scenario, and get back a new access token. This also allows you, hence the name refresh,
34:03
to refresh the claims that are inside the access token. So many people ask me like, ah, we are putting roles in our access token, but now the roles have changed, but the access token is still valid for eight weeks. What do I do? The problem is you shouldn't do that, right? If you have data that frequently changes,
34:22
then you probably don't put them into the access token because once this thing is out there, it's out there, right? And you can't update the access token, only the authorization server can update the access token. So some people use refresh tokens to get this benefit of having like short-lived access tokens,
34:41
and you go back to the server periodically to get new access tokens with maybe updated content. The thing you should think about is how do you revoke refresh tokens, right? Because basically what a refresh token is it gives a client application more or less unlimited access
35:01
or unlimited time access to an API. And many of the websites out there, they have so-called app permission pages like Facebook has them, Flickr has it, as you can see here. That's how my Adobe Photoshop Lightroom has a token to post to my Flickr albums.
35:22
At some point, I might not want that anymore, so you can remove the permission here with the remove permission link, which essentially invalidates the refresh token, okay? That's how it looks like with Dropbox, for example. That's how it looks like at Microsoft, so if your highly trusted Minesweeper client
35:42
wants to access the profile, that's how you can revoke access to it, okay? So in summary, the resource owner flow is basically a way to exchange a password with a token. That token could be short-lived or long-lived or somewhere in between with a refresh mechanism, yeah?
36:02
Which is better than storing the password on the device, because it's a scoped credential, right? And it's time-limited as well, but the client can see the credential. That's something you might not want. Which brings us to the next common scenario where you want to separate the client application
36:20
from the user's credentials. You don't want that the user types in his password into this client application. You only want it on your server, okay? And that's the so-called implicit flow. And the way this works is you're writing an application and that is typically made for native or browser-based applications. So if you are in the browser,
36:41
you redirect the user to the authorization server and present him with, which in turn, presents him with a login screen. If you are a native application, you have to open a so-called web view, like an embedded browser in your application which renders the UI. And what OAuth specifies is basically
37:01
which query string parameters you send to the authorization server, okay? So there are a number of ones that are specified in the specification. For example, what is the name of the application which points to a set of allowed URLs where the token will be sent back to once we are done?
37:24
Okay? So you basically say, hey, I'm native app. I want access to the read scope or service. When you are done, please send me the token back to this URL, okay? Now what happens now on the server side is
37:42
we are in the browser or in a browser. Now the user gets authenticated if he's not already authenticated. They are like single sign-on. And once that has happened, there's an optional step depending on what type of application you're writing. If you're more writing like in-house applications,
38:01
you typically won't do that. But if you're writing like public applications, then you inform the user what's going to happen now, yeah? So we know who the user is. That's Dominic. We know the application because it identified itself. That's Fiedli in this scenario. And Fiedli's asking for scopes. And these scopes map to a personal information of Dominic,
38:24
the guy sitting in front of the machine hopefully, and manage my Google reader data. So you see that's a bit of an older screenshot. And now that's the last line of defense really. A human has to validate that information, yeah?
38:40
And say, okay, that's me. That's the application I just clicked on. And I'm fine with releasing that data, okay? And when you click Allow access, that's what you exactly get. The application Fiedli will get access to this data. That's how it looks like with Twitter. They combine the content screen with the login screen.
39:04
And again, they are pretty explicit here. The application will be able to read your tweets, update your profile, and so on, but will not be able to see your Twitter password, okay? I like this approach here. That's from Evernote. By default, they limit the time
39:23
how long an application will be able to access your data. Let's say you are just, whatever bubble browser really is, evaluate this client, yeah? You can say, okay, give it access to the data for one week. And if I don't use it anymore, after one week it will expire automatically,
39:40
and I'm done. If I decide to use it for more than one week, okay, after one week I will give it more access maybe for a year or something like that, okay? So the content screen is important, right? Because it informs your users what's going on. And I recently had a question, someone said like,
40:02
yes, but can OAuth2 save my grandma on the internet from these weird attacks? And the answer is obviously no, right? I mean, you still need to understand what you're doing, and these content screens try to help the user understand what he's going to do, yeah?
40:21
There's a guy from GitHub who brought up this content screen just to figure out how many people think allow without reading the content. And it turned out many people did that, okay? So, once that is all done, yeah,
40:41
authentication, content, and so on, then the authorization server sends back the access token on a callback URL, okay? This callback URL must be pre-registered with the authorization server, because that is the holy grail now, right? When you, whoever receives that token has access to the data, so you wanna make sure
41:01
you only send it back to trusted locations, yeah? And they're using, which is a subtle detail, a hash fragment for that, not a query string. Why? Because in browsers, everything that's behind the hash fragment will never be sent back to a server, okay?
41:21
There was an interesting attack where someone, it was Facebook as usual, where someone could manipulate the callback URL pointing to a Facebook page, still on Facebook server, which was considered trusted, but this page had an image on it which came from a server that he controlled.
41:42
So the browser made a referrer, sorry, a GET request to the image, and on the referrer, there was the access token. So he could basically leak the access token to an untrusted location. That's why it is mandatory you do that after hash fragments and not after query strings, okay?
42:02
They fix that. Cool. So let me show you that. Let's show you a native application first, yeah? That's the best I can do in UI design.
42:21
So this is a native application, could be anything really, yeah? And we're asking now for an access token. And what happens is I'm opening this embedded browser inside my application, yeah? That's the username, of course, I have an alias in my system. I log in, and I basically see the constant screen now.
42:44
And that basically says, okay, this client here called implicit client is trying to access the read data and write data applications or data backends, whatever. And do you want me to remember that decision for you? Okay? Let me say yes. Basically, here's our access token, okay?
43:04
And again, from that point on, I mean, we can look into the access token. You see, again, there's the issuer expiration and so on, client ID, scopes, read, write, subject, the authentication method reference, how did the user authenticate, when did he authenticate, and from which source this was coming from.
43:24
Okay? And then again, we can call the service using the access token, and it just echoes back the claims. So again, a common question I get is, who makes sure, or who can save me from that
43:40
this page here is actually really a browser and not something that looks like your login page? Yeah? This is a native application, right? So they installed it on your machine. You press the button, clicked on the XE, whatever. That was your trust decision, okay?
44:01
Of course, nobody can make sure that this is not a fake login screen, yeah? You installed this thing on your local machine. It can do whatever it wants. But that has been always the way, right? So yes, OAuth, again, as a protocol, can't save you from that. That's a different problem, okay?
44:23
The nice thing about this approach with this embedded web view is that the client is completely unaware of how authentication works, yeah? So what do you think? How much code do I need to write now to add Google authentication to this WPF client?
44:42
In the client? Nothing, right? That's done by the server. So when I go back here, I could log in with Google. And now, if I look at the access token, you see this was sourced from a Google account.
45:02
Yes, the client gets that for free, right? Because it's not implemented in the client anymore. If you would go to resource owner password flow, then you would have to implement everything in the client. And if you have like five clients, they're like Android and iOS and so on, you would do it five times. So here, basically, you get that for free for every client.
45:23
Okay, so that was the implicit flow. Oh, I want to show you JavaScript. Who does JavaScript in this room? I love it.
45:43
So same application, yeah? I wanna ask for an access token. I do a redirect in the browser. I sign in. And you know, again, strictly speaking, this must not be a browser. This could be something that looks like your Chrome browser on your machine, right? Just saying. And here we are.
46:01
That's our access token. And again, we could send the access token to that API backend and use that, okay? The way this works in Java, pretty quickly, there's an OAuth client class that we've written. On the way in, it generates these URLs, yeah? And on the way out, it uses this regex to extract what's after the hash fragment
46:21
so we can get back to the token. So in summary, that is basically how you separate the credential from the client application. And many operating systems these days have helped us to make these web views more secure.
46:41
Like Windows 8 has the web authentication broker, which is a native API which creates a secure web view, whatever that means, yeah? But it at least has a separate cookie container from desktop IE, for example, stuff like that. Android has something. Pedro is gonna show that later. iOS, I'm not sure.
47:04
Okay, so the next flow I wanna quickly show you is stepping up security just a bit because now the application is actually installed on a server, so that the client is now a server application, okay?
47:21
That is sometimes a little mind-bending to understand in the first place, but that's the way it is, yeah? And the way they do that or can do that is they can, instead of asking for a token, they can ask for a code. And what that means is that the authorization server will do all its work, but it will not send the token back.
47:41
It will send back a so-called authorization code, which allows the client to get the token but using a machine-to-machine-based communication and not wire the client's browser. So in other words, the token is not sent back via the client machine, okay? So we get back the token, sorry, the code,
48:04
and then the application goes to the authorization server, says, here's the code, give me back the token, and then they store the token on the server side and not on the client side, okay? Different scenario again. Same idea, just quickly show you that as well.
48:21
Code flow client, okay? Let's say, give me access to the read. Yeah, same idea, we sign in, content screen,
48:43
and you see now that here on the query string, there's just the code and not the token anymore, and now when I say get token, the application does a server-to-server communication to change the code with the token, and then we have the token in our application, okay?
49:04
Cool. Again, this is often used in conjunction with refresh tokens because this allows to authenticate the client, so the client can securely refresh tokens. For long-lived access, yeah, think of you're writing an application that, you know, there's this silly application out there that once a week tells you on how many Twitter retweets
49:22
you had and followers and unfollowers and so on, and what they basically need is it's a server-based application, a web application that does, on that backend, like batch processing style, long-lived access to your Twitter account, that's how they do that, yeah, with the authorization code flow and refresh tokens, that's how you would implement that.
49:42
Cool, how are we on time? That's gonna be tricky. Cool, so the last flow I wanna talk about, or concept is rather, it's about federation, okay? So we've seen that basically you are having an authorization server, and your APIs trust the authorization server, yeah?
50:02
That's the way it works. I get many questions asking like, but can't we use Facebook's access token to secure our servers? Well, you can't, because Facebook is not responsible for securing your services, right? They know about their services, and they should be responsible for securing them, yeah? So in other words, the token has to come
50:23
from a trusted source, and that source is from you, the service owner, okay? But what if you have these scenarios here? You wanna cross a trust boundary, yeah? Think of maybe how would I do a Facebook login to secure my service, yeah? How would I let an external business partner
50:40
in my system, for example, using their Active Directory, for example, yeah? So that's basically the so-called assertion flow, and the idea is who has done federation in the past knows that picture already. It's just different names now, yeah? So the idea is your client could be your business partner, and they have Active Directory, okay?
51:00
And they want to access your resource, yeah? How do you give them access? Well, you don't want to trust their Active Directory directly, yeah? But you want maybe something in between, and that is often called a gateway, okay? So the idea is that your client has its own authorization server, and home means in that context,
51:20
that's the place where the credentials live of the user, yeah? And you have your authorization server, that's your gateway, if you like, to others, and the trust relationship is like this, okay? Your resources trust your authorization server, but your authorization server has a trust to the external partner, okay?
51:43
Now when the user wants to authenticate, he basically first goes to his local authorization server, he gets back a token for the gateway, the gateway makes sure the token is trusted, you get back a new token, this time for your API, and then the client can use this API to access the resource, okay?
52:06
I've written a sample that shows how that works. It's a bit hard to see, but the idea is this. Here's the client. You see what the client is doing?
52:22
It first authenticates with AD to get a Windows token, or a Windows-based access token, and then it uses this access token to get an access token from the gateway, and with that access token, we finally call the service. So here's a little mini OAuth authorization server
52:42
that has only one job, turning Windows credentials into JSON web tokens. That's your Active Directory authentication, yeah? So let's run that, and let's run the client. Fingers crossed, yeah, here we are, okay? So first we went to the Windows token service to turn my Windows credential into an access token.
53:03
Then I send the access token to the gateway, and then the gateway gave me back a real access token for the service, and then when we end up at the service, what's my subject name? My Windows account.
53:22
So that is one of the more advanced scenarios, but necessary for doing federation across trust boundaries. Excellent. So we spent now 55 minutes talking about how to authenticate users, or how to request access tokens.
53:44
Once now, and that was the easy part, believe me, yeah? Now once the access token and the user is inside your service, now the hard part starts, figuring out how do you authorize him, business rules, and all these things, yeah? And you know, I can't tell you how that works
54:01
because that's so specific to your application you're writing, but you have two things, two buckets that you can source data from. One is the identity of the user, and that's your main, main source of information, right? You know your users, they have certain properties in your system, rules or permissions, whatever, yeah?
54:23
And you know who the client is, because the authorization server knows who the client was, and puts that information into the token, okay? So you know who the client is, what type of client is it, is it like a public client, is it a client installed on a server, for example, which you might trust more,
54:41
and you know which scopes the client has access to. And with that together, you form your authorization policy, okay? We have written two attributes to make that a little bit easier. The upper one is for user-based authorization, where you can annotate your code with like, okay, this method is adding a customer, now make sure the client is,
55:01
sorry, the user is allowed to add a customer in your system, and the lower one is an attribute which makes it automatic to check for scopes in the access token, so if your client application calls the post method, it will make sure that the scope read-write is inside the access token,
55:21
otherwise the request will be rejected, yeah? Again, just help us, yeah? But they seem to be useful sometimes, okay? Cool. That's it. Lots of tokens and users and clients and everything,
55:40
but I think it's useful to see these patterns. Many, many people are using them successfully, and I hope that was something interesting to you as well. Right after this talk, I will talk about OpenID Connect, as I said, which adds the authentication access to what we've just seen, which we haven't talked about yet, right? We only have talked about
56:00
how to get access tokens to something. Thank you.