How not to use 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 |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45615 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201962 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
Open sourceFreewareGoogolFacebookLoginMultiplication signRight anglePoint (geometry)Cartesian coordinate systemSoftware developerFacebookStandard deviationAuthorizationCASE <Informatik>Web 2.0Insertion lossXMLUMLJSON
01:50
Text editorClient (computing)Server (computing)AuthorizationIdentity managementAuthenticationDigital photographyInternet service providerGoogolAuthorizationGraphics softwareClient (computing)Server (computing)Computer configurationDigital photographyCartesian coordinate systemCASE <Informatik>Identity managementWeb browserSoftware developerAuthenticationFacebookFormal languageMobile appInternet service providerJSONXMLComputer animation
03:42
Standard deviationAuthenticationInternet service providerIdentity managementServer (computing)Text editorClient (computing)AuthorizationDigital photographyAuthenticationAuthorizationStandard deviationConnected spaceOpen setPerspective (visual)Computer animation
04:41
Client (computing)Text editorCodeAuthorizationGoogolServer (computing)Digital photographyCodeImage registrationToken ringParameter (computer programming)Graphics softwareMobile appDigital photographyAuthorizationAuthenticationMoment (mathematics)Pattern languageState of matterServer (computing)Cartesian coordinate systemLoginDiagramFlow separationDataflowUniform resource locatorClient (computing)Regulärer Ausdruck <Textverarbeitung>WindowIdentity managementInformation securityWebsiteWeb browserMereologyText editorPlastikkarteFlash memoryPoint (geometry)1 (number)GoogolComputer animation
09:29
Text editorToken ringDigital photographyServer (computing)AuthorizationClient (computing)Equals signCodeClient (computing)Identity managementPoint (geometry)State of matterMultiplication signCross-site scriptingData storage deviceDataflowComputer animation
10:36
Server (computing)Client (computing)Text editorAuthenticationDigital photographyAuthorizationCodeClient (computing)CodeDataflowServer (computing)Web browserPoint (geometry)PasswordPresentation of a groupComputer animation
11:28
Digital photographyText editorClient (computing)AlgebraAuthorizationServer (computing)Mobile appSingle-precision floating-point formatWeb pageAuthenticationGoogolMoment (mathematics)CodeAuthorizationCodeInformation securitySingle-precision floating-point formatToken ringWeb applicationWeb pageServer (computing)Cartesian coordinate systemGoodness of fitDifferent (Kate Ryan album)Web browserMereologyDataflowWeb 2.0Client (computing)Moment (mathematics)Dependent and independent variablesComputer animation
13:16
Information securityImplementationClient (computing)Parameter (computer programming)Software development kitFacebookWeb browserVulnerability (computing)Information securityImplementationCross-site scriptingError messageState of matterMathematicsField (computer science)AuthorizationPattern languageClient (computing)Parameter (computer programming)Web browserSingle-precision floating-point formatMereologyComputer animation
15:15
ImplementationWeb browserParameter (computer programming)Vulnerability (computing)Open setUser profileGradientIntegrated development environmentInformation securityPersonal digital assistantData modelMereologyImage resolutionSoftware bugInformation securityMathematicsStandard deviationIntegrated development environmentFacebookWebsiteRegulator geneProfil (magazine)Communications protocolAuthorizationOpen setElectronic signatureIdentity managementCartesian coordinate systemNumberState of matterContext awarenessGroup actionCASE <Informatik>Database transactionMobile WebMultiplication signComputer animation
17:38
Client (computing)Internet service providerServer (computing)AuthorizationAerodynamicsComplex (psychology)AuthorizationService (economics)Graphics softwareServer (computing)FacebookMobile appRange (statistics)Internet service providerClient (computing)TwitterCartesian coordinate systemIdentity managementDigital photographyComputer configurationSoftwareMultiplicationDynamical systemScaling (geometry)XMLComputer animation
18:48
AuthorizationServer (computing)Internet service providerAerodynamicsClient (computing)Complex (psychology)Server (computing)Client (computing)Information securityService (economics)Physical systemMultiplicationAuthorizationIntegrated development environmentImplementationRight angleMultiplication signMathematicsCodeComputer animationProgram flowchart
20:08
Address spaceInformation securityComplementarityFormal grammarMathematical analysisoutputData modelElectric currentOcean currentInformation securityFitness functionStandard deviationIntegrated development environmentGroup actionAuthorizationImplementationEndliche ModelltheorieSimilarity (geometry)MathematicsDynamical systemMathematical analysisSoftware developerConvolutional codeJSONXMLComputer animation
21:43
Mathematical analysisSystem programmingEndliche ModelltheorieFormal grammarSoftware testingCommunications protocolStandard deviationCodeTransport Layer SecurityInformation securityLimit (category theory)Endliche ModelltheorieMathematical analysisCodeMereologyLogicFluid staticsStandard deviationTransport Layer SecurityWeb 2.0Mixed realityInformation securityCartesian coordinate systemFormal languageFormal grammarSoftware testingImplementationWeb applicationAlpha (investment)Latent heatProcess (computing)MathematicsSpacetimeCryptographyComputer animation
22:56
Information securityInformation securityCodeMereologyLibrary (computing)Point (geometry)Flow separationCartesian coordinate systemFacebookMetadataContext awarenessAuthorizationConfiguration spaceImage registrationSoftware developerMIDIStandard deviationService (economics)Connected spaceServer (computing)Open setComputer animation
26:07
Client (computing)AlgebraSanitary sewerToken ringSingle-precision floating-point formatWeb pageMobile appServer (computing)AuthorizationWeb browserAuthenticationSystem programmingInjektivitätWeb browserAuthorizationServer (computing)Information securityCodeOperating systemLeakCross-site scriptingClient (computing)Token ringSoftware testingConnected spaceIntegrated development environmentProxy serverFlow separationDigital rights managementComputer filePoint (geometry)Single-precision floating-point formatService (economics)GoogolNeuroinformatikCartesian coordinate systemPower (physics)Dependent and independent variablesInjektivitätPhysical systemMobile WebString (computer science)Domain nameSource codeContext awarenessBlock (periodic table)Game theoryOperator (mathematics)Computer animation
30:48
Web browserToken ringInjektivitätUniform resource locatorLeakServer (computing)Client (computing)CodeAuthorizationPhysical systemToken ringWeb browserVulnerability (computing)Constraint (mathematics)RootMereologyAuthorizationComputer configurationCodeInjektivitätClient (computing)Proof theoryServer (computing)Web pageCartesian coordinate systemMobile WebBitDifferent (Kate Ryan album)Information securitySingle-precision floating-point formatAuthenticationBounded variationOperating systemAndroid (robot)Set (mathematics)Pattern languageFront and back endsFlow separationComputer animation
33:15
Token ringAuthorizationServer (computing)CodeInjektivitätProof theoryCodeProof theoryHash functionClient (computing)AuthenticationInformation securityToken ringSoftware bugKey (cryptography)Mechanism designRow (database)Data acquisitionFormal verificationComputer animation
35:05
Token ringAuthorizationSanitary sewerSingle-precision floating-point formatCodeProof theoryCodeToken ringMechanism designSingle-precision floating-point formatXMLComputer animation
35:55
Token ringSanitary sewerAuthorizationConstraint (mathematics)Public key certificateSingle-precision floating-point formatCodeProof theoryPublic key certificateCodeToken ringClient (computing)Keyboard shortcutMechanism designWechselseitige InformationConstraint (mathematics)Server (computing)Data storage deviceMultiplication signPower (physics)AuthorizationConnected spaceAuthenticationComputer animation
37:17
Token ringInjektivitätCodeClient (computing)AuthorizationSanitary sewerToken ringLeakCodeAuthorizationLibrary (computing)Client (computing)Injektivität1 (number)Service (economics)DataflowConstraint (mathematics)NumberInformation securityTransport Layer SecurityServer (computing)Wechselseitige InformationXML
38:19
Client (computing)AuthorizationDependent and independent variablesTrailVideo trackingMatching (graph theory)Uniform resource locatorParameter (computer programming)Keyboard shortcutToken ringReduction of orderLimit (category theory)Client (computing)Parameter (computer programming)Server (computing)Connected spaceToken ringOpen setGoodness of fitMechanism designMixed realityLatent heatComputer configurationAuthorizationPoint (geometry)Dependent and independent variablesDifferent (Kate Ryan album)State of matterRandom number generationString (computer science)Multiplication signInformation securityConstraint (mathematics)Flow separationXML
40:49
CodeToken ringClient (computing)Client (computing)Token ringCodeMultiplication signMechanism designPoint (geometry)CAN busComputer animation
42:01
Token ringForceAuthenticationClient (computing)Keyboard shortcutConstraint (mathematics)PasswordToken ringPublic key certificateClient (computing)AuthenticationNumberMultiplication signWeb browserPasswordStandard deviationAuthorizationWebsiteProxy serverDataflowField (computer science)Server (computing)Enterprise architectureContext awarenessDependent and independent variablesComputer configurationMechanism designInformation securityFormal grammarRight angleComputer animation
45:19
Parameter (computer programming)Dependent and independent variablesAuthorizationClient (computing)TrailVideo trackingToken ringCodeServer (computing)Sanitary sewerPublic key certificateClient (computing)Web browserUser interfaceServer (computing)Cartesian coordinate systemAuthorizationSet (mathematics)XMLComputer animation
46:07
Token ringKeyboard shortcutReduction of orderLimit (category theory)CodeClient (computing)PasswordParameter (computer programming)AuthorizationSanitary sewerConstraint (mathematics)Public key certificateSingle-precision floating-point formatProof theoryWeb browserInjektivitätLeakUniform resource locatorServer (computing)AlgebraSystem programmingMobile appWeb pageProof theoryHash functionClient (computing)PasswordDataflowPoint (geometry)Right angleData storage deviceCodeFormal verificationComputer animation
47:42
Keyboard shortcutToken ringReduction of orderLimit (category theory)Client (computing)PasswordCodeEmailWeb browserAuthenticationLine (geometry)AuthorizationStandard deviationInformation securityFormal grammarProof theoryImplementationReading (process)Data modelPasswordClient (computing)Web 2.0AuthenticationWeb browserINTEGRALKeyboard shortcutInformation securityMathematical analysisState of matterVulnerability (computing)Standard deviationProof theoryServer (computing)ImplementationContext awarenessLibrary (computing)CodeSpacetimeAuthorizationCartesian coordinate systemEndliche ModelltheorieDegree (graph theory)EmailConnected spaceDifferent (Kate Ryan album)Direction (geometry)Content (media)Closed setSoftware developerGraph (mathematics)Mobile appOperator (mathematics)Computer animation
52:18
Formal grammarMathematical analysisSoftware developerFront and back endsJava appletInformation securitySoftware developerAuthorizationJava appletLatent heatLibrary (computing)MereologyDot productData storage deviceForm (programming)String (computer science)Token ringMathematical analysisServer (computing)Multiplication signStreaming mediaWeb browserSpacetimeClient (computing)Standard deviationFormal grammarFront and back endsComputer animation
55:58
Open sourceFreewareComputer animationXML
Transcript: English(auto-generated)
00:07
Thank you everybody for joining me here today. I'd like to speak about how not to use OAuth. Who in this room is familiar with OAuth in general? Okay, that's almost everybody.
00:23
My guess is that almost everybody or everybody in this room has used OAuth at one point or the other. Maybe as a developer when there was some particular problem with authorization to solve, but most likely also as a user. And sometimes you don't even know that you use OAuth,
00:45
or most of the times you don't know that you use OAuth. Because of course, it's not something that is supposed to be seen by the user. The user just wants to use it. How does it look like? So this is something you might have seen in the web.
01:03
Something like sign in with Facebook, or you give somebody access to your Facebook timeline if you are on Facebook. If you use Google, you might have seen something like this here on the right. For example, if some application wants to have access to your Google Calendar, then you can use OAuth to give that application access to your Google Calendar.
01:28
There are also use cases at banks, for example, where which nowadays start using OAuth. And also, as you might have heard, Apple is rolling out
01:41
sign in with Apple, which is also based on OAuth. So what is OAuth? OAuth is a standard for federated authorization. What does that mean? Well, authorization is if you as a user, here on the left, want to authorize an application
02:04
which in OAuth language is called the client, not to be confused with a web browser as a client for example, you want to give that client access to your data at some third party. For example, you have a photo editor app and you want to give that photo editor app
02:24
access to your photos on your Google Photos account. And this is authorization. So you give somebody else access to your data. As I said, the application would be called the client in OAuth and the Google Photos
02:43
application in this case would be called either the authorization server, which is the server where you give the authorization to the photo editor app, or the resource server. This is the server where the OAuth client retrieves your resources and accesses your resources.
03:02
Authorization is not the same as authentication as you might know. authentication means federated authentication is if a user wants to authenticate to some website, then call the relying party using an identity from some identity provider. For example, if you want to log in at Airbnb,
03:23
they offer you the option to sign in with Facebook. This is federated authentication. And these use cases are completely different. Oftentimes, however, they are conflated into one or the users or developers are confused about what they need.
03:43
OAuth is not a standard for authentication. OAuth is only for authorization and you should never confuse that. However, you can also use OAuth plus the standard OpenID Connect
04:02
for authentication. So here we're talking only about OAuth in this talk, but most of what I'm saying here is also applicable to OAuth plus OpenID Connect. OpenID Connect is a layer on top of OAuth for authentication, but OAuth only provides authorization.
04:21
Okay, this is really important. And now we are only talking about OAuth, so only authorization in this talk. So how does OAuth work? From a technical perspective, so this is the high-level picture, what does it look like in detail? Well,
04:42
here we have the three parties. We have the user on the left using her web browser typically, could also be an application on a mobile device. The photo editor app and the Google Photos server. So typically the user would say, okay, I'd like to connect my photo editor account to that Google Photos account.
05:03
Then the photo editor app would prepare some values and redirect the user to Google Photos. And in this direction, the client for the editor app adds several parameters.
05:20
The interesting ones here are the redirect URI. This is the URI where the user should be sent to after the authentication slash authorization part is over. So where the user comes back to the client. And then there's a value called state, which I will talk about in a moment.
05:41
Now the user sees this window from Google, similar to the one we've seen before, and Google asks, do you want to give photo editor app access to your photos? If the user is not already logged in at Google, of course the user would also have to sign in at Google.
06:01
Which is out of the scope of OAuth, so the user just as usual signs in with Google. Then we assume that the user actually gives access to the photo editor app. The user is being sent back to that redirect URI. You can see that it's the same URI. And now the
06:23
Google Photos server adds something that is called the authorization code, or code for short. Plus the state, which is the same value as above. But this is the important thing, the code. The user then, of course, because this is just a redirect,
06:42
the user retrieves that URI from the photo editor app. Therefore the photo editor app now knows the code. Now the photo editor app sends a back channel request to Google Photos to the so-called token endpoint
07:01
with that code. And Google now sees, okay, that's the code I've issued before, and Google responds with the so-called access token. This is all happening in a back channel, so this is not in the user's browser. Now the client has the access token. And the access token is the most important thing in OAuth, because the access token gives you access
07:25
to all the things the user authorized you to access. So this is really the only authentication credential at this point in the flow that is relevant anymore. So, whoever has the access token can access the resources of the user at the Google Photos website, at the resource server.
07:49
Okay? Now you might ask, why do we have the code here? Why don't we send the access token in this step? So Google could just send the access token here. Why do we have this extra step with the authorization code?
08:07
Well, we'll get to that in a moment. We'll actually see that there is another flow where we don't have the authorization code. But we'll also see why this is a bad idea. In this flow, there are several security features built in.
08:23
Which, of course, you cannot see by just looking at this diagram. Therefore, I have some callouts for you. Here is a check of the redirect URI, which means that Google checks that this redirect URI belongs to the identity of the client, which is also sent a net request, which I've not shown here.
08:44
So that, essentially, if Google asks, do you want to give access to photo editor app, it is ensured that this code is sent back to the photo editor app, because this was registered beforehand. So there's a registration step where the photo editor app says, this is my redirect URI.
09:05
Actually, oftentimes, you can also provide a pattern for a redirect URI. You can say something like a regular expression or some wildcards. You can say, okay, it's client.example slash something.
09:22
So this is the redirect URI check to ensure that the code only lands at the proper party, not at any party. Then there's the state check. Who knows what the state is for in OAuth? Anybody? It's for cross-site request for the protection. At this point in the flow, or rather at this point, the client invents a
09:48
state value, which is just or should be just a randomly selected value, a nonce. Now the user is being sent to Google and back and the state value all the time
10:00
must be exactly the same. And at this point in the flow, the client can check whether the state value it invented here and then store it, for example, in a session is the same one it received here. This ensures that nobody else can just redirect a user to a URI like this and the user would be locked in at the client,
10:21
which would force the user to be locked in on an identity that the user might not want to use. So this is essentially classical cross-site request for the protection at this point. And then there's another check. At this point in the flow, which is again a back-channel request,
10:44
the Google server can check whether the client is authenticated, which means that the client must present credentials, for example the password at this step, and only the client can know these credentials. That means that if somebody is able to steal that code, for example from your browser's history,
11:06
he will not be able to use that code because he would have to present the client credentials at this step, which he cannot because the client keeps these credentials for itself. If a client uses client credentials, then we call this a confidential client because the client can keep secrets.
11:26
This is why it's called confidential. Okay, this was the authorization code grant. This now is the implicit grant, which is often also
11:40
thought of as the simpler OAuth. Indeed, it is more simple, but it's also more insecure. We'll see why in a moment. It starts just like the other flow we've seen, but there's a difference here. Instead of creating the authorization code,
12:00
the Google server issues the access token immediately in this response, and it adds it to the fragment part of the URI, which means that the web application running in the user's browser here sees the access token and can use the access token directly from the user's browser, which is nice if you want to,
12:22
if you have a single page application, for example, with JavaScript, and that single page application wants to use or access resources at Google, then this single page application can just use the access token directly at Google server. Or it can, if it's not a JavaScript application in the user's browser,
12:43
it can send back the access token to the client, and the client can use the access token in the web channel. Okay, are there questions so far? So these are just the basics to get everybody on the same page. I don't see any questions so far. Okay, good.
13:04
So let's have a look at the security of OAuth. And in particular, what are the challenges that OAuth faces in 2019? Because OAuth was standardized in R3-6749 in 2012, so that's seven years of OAuth,
13:25
but we are still seeing security problems in OAuth. Why is that? Well, the first reason or the first challenge that OAuth faces are implementation flaws. Of course, nobody is perfect, so we will continue to see implementation flaws.
13:45
But the thing is, what we see are a lot of anti-patterns, known anti-patterns for OAuth that are still being implemented. It is very well known, for example, that you have to check the redirect URI carefully. Because otherwise, as I said before, you might end up sending secrets to an attacker.
14:05
You definitely don't want that. All the state parameter for cross-site request forgery protection that I've talked about before. We still see that this is not properly used, for example, people putting constant values in.
14:23
And you don't have any protection any longer. Or people just not using that parameter at all. And there's a lot of research on that topic. And so roughly half of the OAuth clients implement OAuth in a wrong way.
14:40
If you trust this research. So something needs to be done in this field. Of course, it would also be nice if a single implementation error would not lead to broken OAuth security. So we need more defense in depth.
15:03
But we also see something that is rather subtle. And that are technological changes. For example, in 2012, browsers handled this fragment part of URIs differently than they do today.
15:21
And this introduced a security bug in OAuth. So we see technological changes that bring new problems to OAuth. Challenge number two. When OAuth was invented, people thought of use cases like connecting your Facebook account to your, I don't
15:44
know, to some other website that where you can print your pictures from Facebook or something like that. Nowadays, we see OAuth being used in completely different environments, namely high stakes environments like banking, like e-government, like mobile identity and authorization.
16:05
We even see it in use cases like qualified electronic signatures that have to follow very high security standards and also e-health applications. This is not a bad thing in itself, because using a standardized protocol is oftentimes better than
16:23
inventing your own where you probably end up making the same mistakes as the people before you did. The problem is that OAuth was not built to be so secure that you can make, for example, monetary transactions with that. Yet, you might have heard of the PSD2 regulation by the EU, which forces banks to open up their users' accounts to third parties.
16:48
And we will see that almost every bank in the PSD2 regulation context will use OAuth or a variant of OAuth for that purpose. For example, we have the Open Banking Group in the UK, which also, or the standards
17:04
there, they are also used in other, so not only in the UK, but also other countries. We have the Open ID Financial Grade API, which is an international effort, including, for example, Japan, to build a security profile of OAuth suitable for open banking.
17:21
We see that in France or the Berlin Group in Germany, they are all using OAuth for access to your bank account. And this is definitely not something somebody thought about when OAuth was standardized in 2012. And the third challenge are dynamic and complex setups.
17:42
The setups used to be very simple. Usually, there was one client, for example, one photo editor app, connecting to one authorization server and maybe one or more resource servers. So, in your photo editor app, you were able to select exactly one option to get your photos into, and that was Google.
18:02
Nowadays, of course, you all know these buttons where you cannot only select Google, but also Facebook and Twitter and I don't know what. So, we have a range of authorization servers and resource servers that can be used, but they are also completely dynamic setups.
18:22
For example, when this is introduced in open banking. We will see something like 6,000 identity providers or resource servers and authorization servers all across Europe. And if you want to develop an application that you can use with open banking, you will have to connect or be able to connect to 6,000 IDPs.
18:44
That is a lot. So, we have dynamic setups and large scale setups with multiple authorization servers and resource servers for each client and, of course, multiple clients. And in these setups, we cannot be completely sure that not one of these participants might be malicious.
19:06
So, it might be that there is a resource server or an authorization server that has malicious intents. Still, if you are not using this one, the rest of the system should work in a secure manner, right?
19:22
And we have seen attacks that arise exactly from this setup. For example, there is an attack called the AS Mixup Attack. I don't have the time to go into the details, but the idea is that an honest authorization server sends the code that we have seen before to a malicious resource server.
19:46
Or, why are the clients? So, it sends it to the client, the client is confused and sends it to the malicious resource server. And this can only happen in dynamic setups. This is the third challenge that OAuth faces today. So, we have the implementation flaws and technological changes, we have high stakes environments and we have very complex and very dynamic setups.
20:09
How can we address these challenges? How can we make OAuth fit for the next years? Well, the IETF OAuth Working Group has decided to create a new RSC, the OAuth 2.0 security best current practice RSC.
20:25
This is a document that is currently under development at the IETF, hopefully finished soon, which provides refined and enhanced security guidance for OAuth implementers. So, essentially a document that you can take and follow these guidance is really actionable recommendations in there.
20:44
We already have a similar document, but it is from, I think, 2013, it is RSC 6819, so it does not cover all these high stakes environments and all these dynamic setups and technological changes. In this document, we provide an updated and comprehensive OAuth threat model to know which attackers to defend against.
21:10
We describe attacks that we know and suitable mitigations and give recommendations for implementers.
21:21
How did we come up with all the stuff in that document? Well, there were essentially two venues where this came from. The first one was from practice, people noticing problems in practice or just happening to stumble upon some security problem. And the other one is formal analysis.
21:40
We performed a formal analysis of the OAuth standard, which means that we built a logic model of the standard to find out whether it is secure or not. This is essentially an offline testing of application logic. It is not to be confused with a static code analysis, for example, because we do not write any code, we create a formal model.
22:07
And we are also able to find, for example, technological changes that lead to problems in OAuth. Formal analysis is new in this space. It has been successfully used for cryptographic standards, for example, for TLS 1.3,
22:30
which helped to write a precise TLS specification and also to find security problems very early in the process. It is not common yet for web applications or web standards, but we did it for OAuth.
22:44
And many of the problems that we will see came from the analysis. For example, the AS mixup attack that I talked about earlier came from the formal analysis. Okay, let's get to the interesting parts here.
23:00
I'd like to present to you the seven most important recommendations that are contained in the OAuth Security BCP. Any questions so far? There's one. Can we get the microphone?
23:23
Just a short question. Wouldn't it be better to program and deploy pluggable libraries to handle all the problems that arise that you're describing here? Good point. If you're doing OAuth, don't write it yourself, because everybody in the beginning
23:43
thinks it's very simple to use. But then it turns out you need this and that and this and that, and then it becomes a large code base that you need to maintain. So really, the recommendation is use libraries as far as possible. Of course, when using these libraries, you have to configure them,
24:05
you have to tell them what to do, and also oftentimes you have to tell them what features to activate and what not to activate. So these security recommendations, you really need to know about them to see whether or how to configure a library and whether also a library is suitable,
24:23
because some libraries don't have all the security recommendations implemented. Definitely don't write this yourself, but use libraries but know how to configure them. I mean, the use of other availability of libraries is one of the nice things of having
24:42
a standard. There's another question. It's about a dynamic setup. How do you find out these dynamic configurations? Is that part of the OAuth RFC or is this another RFC that you're using? There's a separate RFC for that,
25:02
the OAuth discovery. It was originally invented in the context of OpenID Connect, but it's not limited to OpenID Connect, so there's also an RFC for OAuth. And the idea is that you essentially have some fixed URI where you can go to get your configuration. As I said before, there's a step where you tell the authorization server,
25:27
this is my redirect URI and maybe some other metadata. This is called dynamic registration, so you can go there on a defined endpoint and tell them, this is my data, I'd like to register, and then they tell you, okay, here you go. This step was originally out of the scope of OAuth,
25:45
so for example, for Facebook, you have to go to Facebook register as a developer, then create your application and so on, and this can essentially be automated away. So there's an RFC for that, yes. Okay, let's get into the recommendations.
26:04
And the first recommendation is rather radical. Do not use the OAuth implicit grant any longer. As it turns out, the implicit grant lacks many security features.
26:20
So as a reminder, implicit grant was the thing where the access token is created in this step, no authorization code. The access token is sent to the browser and then from the browser, you can use the access token to access the resource server. This should not be used any longer. Why is that? Well, one thing is, it turns out, there's about a million ways how the access
26:46
token can leak from your web browser to some third party that can then misuse the access token. For example, of course, cross-site scripting. Very well-known problem, still not completely solved. Okay, we have content security policies, but still we see a lot of cross-site scripting
27:04
problems in the wild. So I think it's only two months ago that somebody found that by entering the correct string in the Google search bar, you could trigger cross-site scripting on google.com. So we are not considering this a solved problem. Browser history. If you do something like that,
27:23
this URI will end up in your browser history. If somebody can access your browser history, for example, if you have a shared computer, the access token leaks to somebody else. The access token is long-lived, so usually it lives longer than just a few minutes. So
27:41
if somebody gets the access token even half an hour after you use your computer, then you're screwed. We have proxies. Of course, this should all go over HTTPS, but still, for example, in some companies you have proxies which open up the TLS connections, which can then read all details. You have proxies also on the other side, namely at the environment where the
28:06
servers are running, which might open up TLS connections, which is very popular, for example, in the context of banking. We have operating systems and locks. The server will
28:20
likely lock this request or this response sent here, or your operating system might lock that request, especially on a mobile operating system, or interesting things might happen if you use a mobile operating system and some application registers on that domain. Then this application
28:40
might get hands on that URI, so the application might be able to read that URI, and then the access token can get to a malicious party. So there really are a million ways how this thing can leak from the browser. And really the problem here is that the access token is long
29:00
lived. It has all the power to do things at the resource server, so it's really the single point of failure, so to say. Then there's another problem here, namely access token replay. The thing is that the access token, if somebody gets the access token, for example, because they
29:21
set up a malicious resource server, they can use the access token at all the other resource servers, so there might be multiple, and if one of them is compromised, they can just use the access token wherever they want. Or if somebody else gets the access token, some way or the other, then they can just use the access token, because as we've seen before, the access token
29:44
is not bound to the client which uses the access token. It's just a token that can be used by whomever has the token. And finally, another threat here is access token injection. An attacker might be able to bring a user to send an access token to the client that is not the correct
30:07
access token, so one of the attacker's access token, or the other way around, an attacker might be able to use an access token of an honest user that is grabbed from some block file, for example, and send it to the client, and then the client will use the access token. So the client really
30:24
at this point doesn't know if the access token is the one that came from the authorization server, just sees some access token and will use that access token. There's no way to check that this is the access token that is coming from the authorization server. So several problems here,
30:42
and the problem is we have no defense in depth. If the access token leaks, it's game over. So again, the implicit grant sends the powerful and long-lived access tokens through the browser, which is a very vulnerable part of this whole system. We cannot send or constrain the access token. The access token can be used by anybody.
31:07
There's no detection for replay and ejection, as I said before, and no defense in depth. What should we do instead? Well, the good option is to use the authorization code grant
31:20
that we've seen before. There's a question. But in the authorization code grant, the single page application doesn't go directly to the resource server, but instead it goes
31:43
always over the client. Is that correct? There are actually several deployment patterns that you can use. Of course, you can, if you have this in a single page application, the single page application can exchange the code for the access token. Possible,
32:02
but I don't think it's a good idea. But as you said, typically it would need a backend to then exchange the code for the token. And in my opinion, this is the most secure way to do this, yes. So I think it's a good idea to do it, as you said. But there are actually, so there's no clear consent on how to do that yet.
32:28
Do you see the same problems if the implicit grant is used in an Android application, for example, instead of in the browser? Yeah, it's essentially the same set of problems. Some variations there, how the URIs can leak and other stuff. But yeah, there are also other problems on
32:47
mobile operating systems. It's a bit different. You have a different set of security features or lack thereof, because you don't have the browser or you only have the browser for the authentication slash authorization part. But in general, you have similar problems, yes.
33:03
Okay, the authorization code grant, where we first have the code and then we exchange the code for the access token. This can be improved by very nice security features. The first one is proof key for code exchange, short PXE.
33:23
PXE is a very simple security mechanism, but it's really powerful. PXE means that in this step, the client invents something called a code challenge. The code challenge is, for example, just a SHA256 hash of some random number, just that.
33:45
This is being sent to the AS in this step. The AS records the code challenge. And then when, so the rest works as we've seen before. There's a code created, the code is being sent back to the client and now when the client wants to exchange that code for the access token,
34:03
the client also has to present the so-called code verifier, which is just the plain text of that SHA256 hash sent above. Nobody can know what this plain text is, as long as SHA256 is not broken, unless they are the client who invented this value. Okay, so this is just the hash of
34:26
some random value and you have to present the same random value here again. Very simple mechanism but really powerful. If you think about it, it closes a lot of security bugs that you otherwise might have in a wharf. The most important thing, obviously, is that if somebody
34:41
steals the code, they cannot exchange that code for an access token by themselves. So this works also if you don't have client authentication here in this step. So if anybody can exchange that code in principle, they cannot do that any longer if they have pixie or if you use pixie.
35:02
So do use pixie. Second one, single use code. The code there can be made single use. That means that only once can it be exchanged for an access token. And if the code is being used twice, all the access tokens associated with that code are immediately invalidated.
35:24
That means if somebody steals the code that either the one who stole the code will try to exchange it for an access token but then the real user will do the same and all the access tokens will be invalidated. Or the other way around, the user will first exchange the code for an access
35:43
token and then the attacker will do that and all access tokens are again invalidated. Single use code, really effective mechanism. You also don't have that in the implicit grant. And the next one, with the authorization code grant, we can have sender constrained tokens.
36:03
We can say that the access token is bound to one specific entity that may use that access token. How do we identify that entity? Well, very simple mechanism. In this step, the client can use TLS client authentication or mutual TLS. So the client here can identify
36:29
itself to the server using some certificate. That does not need to be a certificate coming from a certificate authority. That is just some self-signed certificate sent here in this
36:42
connection. The important thing is that the AS stores the certificate and now every time the access token is used, the party using the access token has to present the same certificate again. So it is a very simple mechanism again to bind that request and all
37:03
the access token usages later. This is what we call sender constrained tokens. So it can limit the power of the access tokens. If you use the authorization code grant with pixie and
37:22
mutual TLS for sender constraining, we get protection against code and token replay and injection. So even if you stole a code, you cannot use it in your own flow, for example. We have sender constraining of access token. If the access token leaks, it is really limited to one specific sender who can use that and this all together provides very much a lot of
37:47
defense in depth. So the code can leak and still nothing happens. This is why the security BCP says clients using the authorization code grant must use pixie. So it is a must.
38:02
So we will see that hopefully in many OAuth libraries soon and authorization servers should use TLS-based methods for sender constrained access tokens. Okay, this was only number one in the BCP but the next ones are shorter. Second, prevent mix-up
38:21
attacks. Again, I don't have the time to go into the details but the point is for a mix-up attack, the client can get confused about which authorization server created a code or token and where to use that code or token. So clients must be able to see where the authorization
38:41
response with the code or token came from. You can use that, for example, or you can do that if each client uses a separate redirect URI for each AS it interacts with or if you have OpenID Connect you can check some specific parameter that comes with OpenID Connect.
39:00
And also clients must know which AS the user wanted to use, otherwise this protection is useless. Third, we still see many redirections that can go to an attacker. This must be prevented. So if there's a redirect URI or anytime the AS sees a redirect URI, this redirect URI must match
39:24
exactly with the redirect URI that the client registered. So no option for some strange parameters that send the response to somebody else or something like that. And clients must avoid open redirectors, that is a redirection based on a URI parameter. If a client does
39:41
something like that, this might lead to security problems. CSF attacks. Old topic, do use the state parameter correctly with a random number, not with a static string, and you get CSF protection. The funny thing is, if you use PXE, you don't need that any longer,
40:02
because PXE already provides CSF protection using just the mechanism we've seen before. So if you use PXE, you already have CSF protection, good thing. Access tokens should be limited as far as possible. So we've seen sender constraining, but there's also something
40:22
called receiver constraining. We have mechanisms to ensure that an access token is only valid for one specific resource server, and if you want to access a different one, you can get a different access token. And access tokens should be limited in their lifetime and in the scope and the
40:42
things you can do with that access token. There's a mechanism called refresh tokens in OAuth. Refresh tokens are, again, not a complex mechanism. They are just another kind of token, and if somebody exchanges a code for a token, they not only get an access token, they also get
41:02
a refresh token. Refresh tokens live longer than access tokens, so at some point the access token, after it has been used a few times, it expires because it's short-lived, maybe just a few minutes. And then the client can send that refresh token to the server and get a new access token.
41:22
This is a good mechanism because the access token that is sent around all the time is short-lived and may be limited in the scope, but the refresh token that can be stored securely, that is long-lived and can be used to get new access tokens. An important thing here is that the refresh token can also be bound to that specific client, so the client has to
41:47
authenticate itself to the AS to use the refresh token. If you don't have that for your access token, then you get an extra layer of protection here because anybody who steals an access token only has a token that lives for a few minutes. Refresh tokens must be protected
42:04
because they are long-lived, they are powerful. As I said, you can say that refresh tokens require client authentication. Any time this is used, you also have to present your client credentials, but you can also have sender constraining for refresh tokens, just as we've
42:22
seen for access tokens. So again, binding this to some certificate and then the refresh token can only be used by the holder of that certificate. Number seven, and this is an interesting one, there's a flow, an auth variant called the resource owner password credentials grant.
42:44
This works as follows, and I'm not joking here. The user sends her username and password for Google to the client, and the client uses that username and password for Google at Google to get an access token. I think I don't need to explain too much why this is a bad idea.
43:06
Can we get a microphone there? Microphone by proxy. I must confess that I recently implemented
43:26
that still. Thank you for being so open to us. For an enterprise client where we just can't use any other flow. Yes, especially in enterprise contexts, there are situations where you have to
43:44
do things like this. The thing is, we don't want to have the label auth on this. If you want to do that, do it. It's your responsibility. I cannot stop you. But then it should not be
44:03
according to the latest security standards for auth. So that is just not the label that we want to have on that. And we'll actually put text in the BCP saying you can do this if you really have no other option. But it's dangerous. Don't do this, actually. And you are on your own.
44:24
You were talking about mutual TLS together with OAuth. In my opinion, if you use mutual TLS, you don't need any OAuth at all, because you have already authentication mechanism using a client certificate. Also, the server can check the client certificate fields
44:42
to authenticate you not only cryptographically, but also the client certificate. What do you need OAuth additionally for? Yes and no. So are you thinking about mutual TLS where the browser, so the user on the browser, has a certificate probably issued by some CA and uses this on
45:05
different websites? If you have that set up, you don't need OAuth, that's right. Unless if you use it for authentication. For authorization, you still have that same problem, so you would need OAuth for that. But the important thing here is that the client certificate is not in the user's browser. The client certificate is only...
45:25
Oh, here in this scenario, where is the client certificate? It's by the client, and the client is the OAuth application using that. Okay. And the thing is, if you want to do that in browser, you have this bad user interface. You
45:42
have this download your certificate, put it in your browser, do stuff with that, which nobody understands. So this is something we're not proposing here. But if the client just invents some certificate on their server and then uses that, that is pretty... The OAuth client is not
46:01
a browser, it is an application, the OAuth application, yes. Okay. Other questions so far? I can't really see how the proofing works with Pixie, because an attacker could
46:21
pre-generate a hash of this secret value. The thing is that... Let me go back to where Pixie is. No, this is not Pixie. Yep. The client would need to get some signal from the user saying, okay, let's start
46:45
an OAuth flow. And at this point, the client would invent this value, right? So it would store this in the user session. And then this would go through to this point, and then here we have the protection, because nobody knows the code verifier, so nobody can forge this request,
47:05
which would cause this request, right? So that means that an attacker would be able to know which value the client invented in the user session. So the attacker cannot know what the
47:24
client did in the user session. So the attacker knows, okay, the client invented some SHA256 value, but the attacker just doesn't know what the code verifier for that value is. So that's the protection that we get here. Okay, thank you. Okay, so the resource owner
47:45
password credentials grant. The client sees the username and password for the user, bad idea. It's complicated or impossible to integrate something like two-factor authentication like this, because it's just not in this request, your second factor. Also, if you have things
48:00
that bind your authentication to your browser, like web auth, really new stuff, you cannot just do that here. And the grant name is very long, so too complicated. Okay, what else? So there are a lot of recommendations in that RC document. Some other recommendations are you should not use
48:25
the HTTP status code 307 for redirections in the auth context, because, as it turns out, it might end up sending your user credentials to an attacker. Bad thing. You must aim to prevent code leakage from stuff like referrer headers and the browser history. We have seen that we
48:45
now have some defense in depth against code leakage, but still you have to take care of a lot of things to ensure that these contents of the URIs do not leak to an attacker. And client authentication is a really good idea. So if you can use client authentication,
49:04
do use it. So if it's not a public client which you put on GitHub and use there, but if it's anything else that you can keep in your own server, you can use client authentication and you should use client authentication in that context. So this is the rough idea there.
49:23
So if possible, use it. So now you've seen a lot of things you have to do to operate OAuth securely. And you might end up asking yourself, should I even use OAuth? Because you see, there's all these security recommendations and there's all these things
49:42
that you have to take care of. Well, the answer is yes, absolutely. Why is that? Well, standards are good. We have battle-proven libraries that have closed more security vulnerabilities than you can even think of. We have some degree of interoperability.
50:01
OAuth is not something that is automatically interoperable, but if you have one library and the other library, you can probably both configure them to work together. Years of experience went into the OAuth standards and the OAuth implementations. We have a lot of security analysis by researchers, by practitioners on OAuth, and we have seen
50:26
many custom-built solutions that essentially solve the same problems as OAuth, but implement all the same vulnerabilities again. For example, the state value. If somebody does something that is OAuth-like, they often forget to include a CSRF protect at all, and then
50:44
they end up having the same issues again. We have a formal proof of the security of the OAuth standard, which is worth a lot, which helped us to close many security holes. But, of course, if you use something like OAuth, it's not something you get for free.
51:02
So, if you are a developer, if you are an architect, you really have to think about all the security advice that is given in the original RFC 6819 and in this PCP draft. You should implement the latest security features if possible, stuff like pixie,
51:21
and you really have to know your threat model. If you are on a mobile device, as we said before, you have a different threat model, because suddenly you have another application which can maybe see your eyes you're exchanging with the app. So, think about your threat model or do a threat modeling to implement OAuth securely, but do use OAuth if you have a problem that falls
51:45
into the space. For example, we have seen some developments in this banking context, where some countries essentially invented their own OAuth-like systems,
52:01
but without all the security features. So, it's really not easy to do federated authorization slash authentication, so do use OAuth, and do use OpenID Connect, and do use all the security advice that we have. This concludes my talk. Again, I cannot put all the details here that
52:22
are interesting. If you're interested in the attacks and mitigations, come talk to me, or if you're interested in the details on the formal analysis on OAuth, interesting topic, and if you're interested in working at Yes.com where we are developing an OAuth-based solution in the banking space, we are looking for back-end Java developers.
52:42
And then also come talk to me. And other than that, we have now time for questions. Thank you. There's one. I'm going to be faced with implementing some token-based
53:09
authorization soon, and there's this question JWG versus OAuth, and basically really not... It's not a versus. So, JWG is just the standard for encoding stuff,
53:26
essentially, in a string, and you can... For those who don't know that or are not familiar with JWG, it's essentially a JSON document that you can sign, that you can encrypt,
53:40
and you can... Oftentimes, this is used, for example, to store stuff in a browser. You can store it there because it's signed, so the server can check whether it's properly... Whether it was not changed in between. Or if you're talking about tokens, access tokens, they can take many forms, one of which is a random string, which just the server knows
54:05
what to do with. Another form is to use a JWT, which is then signed, optionally encrypted, and then used as the access token. So, this is not a versus. You can use it in the OAuth space, and actually, if you're interested in that topic, there's an RC under development on how to use
54:22
JWTs as access tokens in OAuth. Does that answer your question, or is there... Yes, thank you. Okay, so, if you're interested, we can talk afterwards, too. Anybody else?
54:55
Yeah, thanks for the nice talk. Is there a specific Java library that implements OAuth that you could
55:02
recommend? I know that we use connector ID for the for the AS part, the authorization server part, which is, as far as I hear from our developers, very useful, very well written,
55:20
and I know that it also supports the latest security features. So, that's something I can recommend for the authorization server part. For the client, I'm not so familiar with these libraries, but there are plenty of them. So, essentially, if you select the new library, you should especially check whether it supports the latest security features, like pixie.
55:50
Okay, I think that's it. Thank you.