Security OAuth 2.0

everyone so yeah first one I'm gonna be talking about securing I off to just quick slide on who we are we're pay for blackberry I used to be a software engineer written plenty of vulnerable code in my time moves over to security back in 2004 Fraser is for my pen tester and moved into the security research group a blackberry contact details are on the bottom but we'll share the slides at at the end in terms of what we're gonna look at today just going to go over the basic protocol so roles tokens clients and endpoints and then have a look at the different what are called grants they're basically different ways that you can use OAuth to ultimately

have have an authorization to use resources somewhere else then we're going to have a look at attacking different implementations there's there's a massive Oh wolf threat model with 50 something threats but we're just gonna have a look at some of the stuff that's specific to 200 and some protocols so specifically around user authentication redirect your eyes and some cross-site request forgery attacks that exist in the protocol if it's not implemented correctly having done that we'll briefly touch on some of the other attacks that exist and then have a look at how how you need to secure it from the different from the different endpoints or the different roles within it terms of definitions I need to throw these up because strictly

speaking our author is an authorization protocol so that is determining whether a user oppresses is allowed to access a particular resource it's not actually specified as an authentication protocol which is identifying who you are all of that is actually left out of the standard so just so that we're clear we're gonna be we're going to be talking about both in within it but that's why I pop the definitions up and so if it's Fraser for the overview yep so boys all - yeah it's an authorization protocol so it basically allows one party to authorize another party to form actions on their behalf consists of four roles so we've got the resource owner which is must the

user you've got the authorization server and the resource server which provides some form of service to the user and then we've got a client which we want to also authorized to access this service not half so also allows the resource owner to authorize the client form operations on their behalf and the resource server and the authorization server is the mechanism used to provide this authorization so the resource owner has an account for the authorization server so for all of our examples we're going to be using a webmail provider so they've already got an account there they using this to send a receive email and the resource server votes api's for common operations on these on this

account so very example as they've got this read and submit this there's some form of implicit trust relationship between resource server and the authorization server so this is often rather than just the same system and then you call client which off the service that uses these API so in all of our examples it's gonna be male robot calm and the idea is this is an AI that lot is your email I can't then sends or is easy mail on your behalf so the advantage of is that our last client to access the resource owners resources without them handing over their password and which isin through control to scope of the actions their rights before and

the mechanism by which they do that is the access token so the main advantage is so if you're handing over your password to to the client they can do anything for all time if you give them an access token you can restrict that to say anyone need to be able to do these three things so once the resource lender said to the authorization server I want to give some client access the authorization server contains the client is token Elijah crisis these three functions this can be given an expiry so you can limit it to only allowing access for a week and you can reverse this so after a week it goes back and ask for another access - you

can also revoke so the resource owner at any time can say - the authorization server I don't want to have access anymore and then when the client tries to use the token - issued the resource of efficacy sorry that's been revoked okay so they flaunt their tokens briefly there's three main types so access token is is the main one is created by the authorization server as if you to the client and is used by the client to access the resources of the resource server so this is multiple use until it expires when it does expire we've got the Refresh token which again is created by the authorization server and if you to the client and it's used to request a

new set of tokens from the authorization server like well now this can either be single multiple use so you can use the same token to refresh every time i refresh kiss or you can also refresh the Refresh token over time this is also optional so you can do it without and vertical the authorization code so this isn't always used in every mode of operation but say it's crazy again by the authorization server issued to the client and is used by the client to exchange for an access token are the old server this is a single user short-lived token and it's not used in every single so gonna take a quick look at the communication between the three parties

and risk of how this works so the first thing the resource owner does is curse the client and requests that they have their their webmail account connected the client redirects the resource owner the browser off to the authorization tab and at this point they authenticate in or thrice to authenticate login authorised is typically a confirmation prompt like the other one was green there see press yes to say you want to give access to these parts of European I think you can get redirected back to the client with the authorization code yes and often time and then the client opens a direct connection and to the authorization server and sends off this code that is received the authorization

server responds with the access token and the Refresh token and now we've got an access token and the client can make API calls to the resource server as long as is valid then some climate prices and the access token expires and then we can use the Refresh token again user tokens back up for the authorization server so this connection on the right here is is performed directly between the client and the legal service so that leads to two different types of client so we've got ones that can store secrets and one that can't store secrets and that controls whether this connection is authenticated or not so a confidential client is this one that's able to source secrets so this is

typically a server-side application so this is able to store secrets so the authorization server can authenticate all connections and that's done using a client secret and then the opposite of that is once accounts or secrets so that's a JavaScript application running in a browser and that's a public so the client secret is it's something that's created a registration time so once the developer develops their client they get it to the service provider that was for ization server and signups their client they create a secret which is then used multiple times possibly until the yeah the last time was client too deep this was authenticated we've also got the concept of endpoints so these are basically the URLs at the

authorization resources of a where things happen so got the authorization endpoint is where the user locks in and also roses touken endpoint which is where the client exchanges its opens so it was code for access and refresh for access and then the resources which is the stuffs client will store access so this is a combined authorization and resource server or you can split them and have author on the Left resource on the room that's now going to take a quick look at I do my our applications just show this works this our my mail robot offers to signing options see what the local sign in option so using your mobile robot credentials to sign it or you can sign

in using web not so responded he then has to associate your webmail account so clicking a lot drugs a softy webmail but we suddenly using a webmail event authorized to be access and then this returns our authorization code this step usually would probably just happen straight away we've broken out just to them just to demonstrate it so what's the matter once the client receives the ORS code it makes the direct connection to the service to exchange the authorization code for access token and then call the API and then there is all the egg toys you say yes just got simple objection the appeal has been called

so now you're going to take a look at some of the grants the most operation so a lot of the the the original spec was really primarily for web servers and so either web server side applications or JavaScript JavaScript based applications for that there's actually there are four different types of authorization grants these are just the motor operation for for our auth you have the authorization code I which is the one that Fraser is already already worked walk through again mostly used for server-side web apps where they can make direct connections to the server you don't have what's called implicit this is used for client-side JavaScript apps that don't have don't have any any server-side

components there are two others one is the resource owner password credentials this is sort of written as an intermediate one where you actually hand over your credentials to the authorization server sorry to the client get it right and then it will actually use your credentials for to get access tokens and refresh tokens it sort of and then to mediate one allows you to migrate say a native app to to a more web-based focus the last one is the client credential grant and this is literally for the client to be able to go to the authentication server in the resource server and be able to access resources for itself so in the instance of site mail robot may be there as a

global directory that exists on web mail that you don't need to be authenticated for and it could use that back to actually access them in terms of what they what they look like that's the authorization code flow with the various components components within it one important thing too sorry everything a lot of the all of the authorization code flow is controlled through greeter at your eyes so you'll see a lot of the information bouncing back from the from the client and they all server via the via the browser just it's just worth pointing that out for talking about it's looking about later on the implicit flow so this is the one that's different from while phrasal is

just what Fraser demonstrated earlier the main difference sorry everything is the same up up to and including the authorization point okay yeah up to the authorization point here but rather than redirecting an axe an authorization code here what so she had what happens is the access to an access token is passed back in the anchor tag of the URI and then that's how she picked up by the client-side JavaScript from the Dom so that's the main difference if there isn't a there is no direct connection from the client to the authorization server but then the client client-side will then use the access token to access the resource server directly terms of the resource owner password credential

grant quite a mouthful the resource owner provides credentials to the client there is no authorization step here it will just you the client will use them directly to connect to the all server to get access tokens and refresh tokens and the scope scope is actually the set of allowed actions in this in this case that's fully controlled by by the client and then having got an access token it will then use it to get resources and do things on behalf of the user client crew the client credential grant pretty straight forwards client connects to the or server is authenticated using the client ID and client secret that we talked about earlier and then he's given

them access token and then from there it can connect to the resource server T to access whatever resources it wants as as itself when it comes to native clients so here we're talking mobile apps and desktop apps there are there are three authorization grants that are possible but only one has actually been specified in an RFC which is the authorization code flow but it's been adapted for native native clients there's still the client still use redirect to your eyes to get information back from the browser so the idea is the user authentication and authorization on the all server also say web my health always happens through a browser and then the browser has to then

pass either the authentication code or the access code back to the client now on Android and iOS you have custom your eyes and the ability to claim HTTP your eyes within the OS but on Windows you're looking at loopback interfaces and there's some there's some interesting challenges in here that we don't go into too much but they're not unique so unlike a urls in the browser don't actually guarantee you'll go back to the right client because you can have multiple apps registered with them in terms of what the authorization code flow looks like because the app is a public client rather than a confidential client it can't authenticate to the authentication server is very simple

flow for this there's a couple of extra bits here that called pke and basically the client creates the secret here sends a hash of that secret to fire the user agent ultimately to the authorization server and then when it's redeeming the authorization code here it provides the original value and the idea is to tie together these two requests effectively buying those two requests other than that that flow looks exactly the same as the authorization code flow for a web app only obviously these your eyes are redirecting from a browser to a native app yes yeah so just just to recap there's two types of clients there is confidential client and that is a client that can keep a secret because it

can keep a secret you as the authentication server or webmail can authenticate said client there are also public clients those are native apps or apps that live within the client side apps that live within the browser for those you can't authenticate the client because they can't store a secret they have historically there have been a bunch of native apps that had secrets embedded into them and there's been papers on that and people have since moved away from that as an idea because it was relatively easy to reverse engineer the the app pull out the secrets so that's that's a protocol at a high level and now we're going to talk a little bit about some of the protocol

level issues that exist within it if it's not implemented either correctly on the client or the authorization server so either on web mail or on mail robot briefly touched on this in the in the introduction there's a massive threat model for a wolf if you're using if you're either implementing your own authorization server or implementing your own client it's well worth read because it has a set of different threats that apply to different scenarios and then a set of recommended countermeasures and mitigations and if you walk through that it's pretty pretty comprehensive you should cover you against most things so first thing we're going to talk about is user education initially I Worf was meant to

authorize a user to access resources but a number of people thought that they could also use it to authenticate a user so in this case the the resource server so in this case web mail has to provide some kind of identity API where you can go where a client can go and say okay cool I've got this access token or I've got this authorization code who are you and then you can get back identity information for that so that's that's like the dialog here with these sign into signing to webmail option now if you if you're implementing this as an authorization server you you have to you have to you have to be able to bind

either the authorization code or the access code to the client that it was issued to if you can't you can swap clients so a malicious client may be able to use a token from a different user well we'll go through the flows for this in a minute authorization code wise you as the authorization server so web mail have controls have control within that pattern because if you can bind an authorization code to a client which you can through that through the flow you can you can control you will see an authorization code being used from a malicious client if you can't sorry so on the implicit fly unfortunately you can't and we'll show why that doesn't

work now so if if an attacker you there's a malicious client so in our instance we're gonna have evil mail robot com could be anything it could be another client that you know just has a sign in through signing through a web mail option and somehow the attacker through fishing or whatever convinces the user to connect to to this client easily goes through standard implicit authorization flow and authorizes the malicious client and at that point the authorization server will send back an access token but in our example rather than using that access token to actually access resources we pull it out the dom and send it to the attacker control server so at this point the attacker has an

access token that allows them to access resources on that users behalf of their client but because the access token isn't that isn't bound to a client the attacker can then connect to a valid client so that in this instance male robot and go through the standard oil's flow but when it gets when it gets to the access token just swap out to the one that he got from the original user at this point the attacker goes to the client the client trusts the access token and goes who are you at this point that access token has been bound to the original user not the attacker and so you get the you get the user information

back for that user client goes okay I know who you are you're the user and the attackers locked in as the as the user and to make that a little bit hopefully a little bit clearer Frazer will demo that okay so now we've got Sam on the rise our attacker on the left is the victim so the attackers cloned male robot and created evil male robot and so the first thing we wanna do is get the client or the victim to to login to their their evil going so phishing attack so now there aren't evil male robot and they go to sign in using their webmail again I've already signed in from from earlier so it's just going to ask us to to

authorize so we authorize and get an access token back now at this point because the attacker controls evil male robot they have this token so the attacker can go to real site all the same flow log in using their and webmail account authorized and now they can substitute the code that they've stolen from the victim and now their clients can win the back back-end and it's made a request that resource server asking who does this and this Isis token belong to and it's responded we've user one so now we're trusting that that response the the Poway client has trusted that information and now we're logged in as the attacker is usable so nice we can look at some

attacks that use the redirect URI so as I as we we mentioned in the when we're going through the authorization grants the authorization code and the implicit code flow redirect the either the authentication code or the access token using a redirect URI via by the browser what should happen is that a client will register should register a full a full redirect URI with the authentication server and then during during various stages of the the grant order the particular flow the authentication server should check that sec redirect URI matches the one that has been registered if that's not the case then then an attacker can provide their own redirect URI and obviously at that point they can redirect authentication codes

or access tokens to a different server so in exactly the same way as we were talking last time with if you if you're mister stuff for a fishing through a fishing tackle or something of that ilk you can you can grab either a either a code or an access token and once you have one of those connect user to connect your account to the U at your account being you the attacker to the user that you've stolen it from so for the authorization code so the attacker sends a phishing link to to the user and that look that looks like a standard request - sorry a standard OAuth flow for the for a trusted clients worst case

scenario if the if the user is already logged in to the client all of this all of this could actually happen in the background without the client knowing which point the or server will then issue a code back to the user agent but rather than redirecting as it should do to the client based on the redirect URI that came in here its redirected back to the attacker always point the attacker has a valid access sorry authorization code runs through a standard login with the with the client so this would be male robot and rather than using the code from the code that was issued to the attacker he switches the code out for the one that he obtained from affect

him and at this point he's looked into it that will then be used by the client so male robots connect to the or server and access the users mail resources in terms of how that looks on the implicit flow same same mechanism fishing link you go through the OAuth flow but and you get redirected but rather than stealing an authorization code because this is the implicit flow you still an access to an access token instead and then once you have said access token the attacker goes through the same same I will flow with the client client substitutes the access token here and at which point the client application running in the attackers browser is accessing resources on the resource

server as the as the user and phrases going to demo that well now so in this attack we were a few mean that the user is already signed into their robot which point the the attacker is going to sign into them male robot okay and then going to take the the link that's used to redirect it to connect your webmail account and to see all that and then within this link is the is the address that we want the the authorization code to go back to so the attacker can change this from male robot - people murmur over

through a phishing attack to get the user to to excuse 'land yes and the authorization code goes back to evil met robots over the attackers attacks caucus code they can then follow the same same investment flow on here and substitute code for the one they've fed they've taken from the victim task exchange for an access token access tokens used to call the API and we have the attackers account at male robot associated with the users account a webmail comm so now the phrase devices any of their resources that's the next we're gonna look at is of course a request forgery

so there's the ability to do a cross-site request forgery against the authorizations response in the in the protocol the the protocol actually talks about this in the RFC and there's mechanisms for dealing with it in in using a state state parameter which is exactly the same way you'd deal with any cross-site request forgery attack normally the things slightly different about about this one it's the consequences it allows it's a it's the complete inverse of the other two attacks that we've demonstrated and it allows the attacker to connect their resources at the resource server to your to the users account on mail robot so if I as a user I had logged into my robot and this attack was performed against me

the it would be the attackers account I'd be sending mail through or listing mail so there may be circumstances depending on the the api's where an attacker could use this to monitor actions that are happening from from a particular client it's in terms of how how it actually works assuming the client is very assuming the user is already logged into the client here we the attacker walks through a standard I will flow to grab a coat an authorization code that they need and then they do a blind post either through phishing or or an iframe on another website - the redirect URI so this is the the authorization response from the from the user to the client at

that point the client goes ah ok that's an authorization code I'll switch to using this this account and so even though the user if the user is logged in here to client the resources guess the resources that are accessed on the resource server gets swapped and now the client is using the attacker controls resources the briefly destruction occurs we don't we don't go back to these diagrams later what should happen is when you when the client might in terms of mitigating this when the client makes the Azzurri when when the users browser makes this request of this redirect there should be a state parameter in here state parameter then goes from the client to the users browser to the or

server and then it's returned here at which point the client can validate the state parameter here is the same one that is issued here just wanted to show that because we don't go back to this later same idea with the implicit one user has logged in our flow and then you pass in the the access token through cross-site request forgery here and the application swaps using the attacker control resources so Fraser's gonna demo that

so in this attack we've got the head the victim signed into their account on male robot and got the attacker also signed into their account so they can follow the implicit grant which returns with an access token so this URL here contains the access token so again we launched phishing attack to get our victim to ask you that URL containing the access token that was issued to the attacker so now user has this this this goes through and because that access token was issued to the attacker we've now associated the users account with your tax account or by mail so any email that's turned to received it's gonna be sent by their account all they

need to do is go and log in directly and they can give this an item's to see see all the users tried to send so we're not going to take a look at some more attacks

so one of the other the other side of our author is it's about granting authorization so in exactly the same way that an application not Android or iOS can ask too many permissions a client can ask for too many permissions so in the in this example like the universe and everything it might be asking you know for additional access to calendar various other parts depending on what functionality is is available on the on the resource server you also obviously clients have names and as soon as you introduce namings for anything you introduce home homograph attacks so substituting characters having things that are similarly named there was actually an incident about six months ago where someone did this on google

they created a client for Google Docs or something of that ilk and there were various emails flying around where this was popping up a you know do you want to associate your account with Google Docs so a similar example to this obviously we have valeted mail robot on the right and slightly shoddy document on the good mail robot on the left dog you want on the right so all the standard all the standard authorized actually problems that you have in any in any system that's asking for asking for permissions just touched on some of the some of the other areas client credentials obviously these passwords sometimes it's stored in the clear in the database they shouldn't in the

authentic authorization so this database they shouldn't be tokens there are a few different types of tokens but assuming you're using a handle base token so random number these obviously need to be big enough and if they're not generated cryptograph from a appropriate cryptographic source they might be guessable all the standard stuff that applies to certain cookies tokens especially things like the access token the Refresh token they're equivalent to all their credentials to get into into an account so if you're storing them in the clear in the database you a database of the authentication authorization server sorry you'll have similar similar problems the RFC is pretty explicit about using TLS everywhere if you don't obviously you've got codes and access

tokens flying around don't really need to go into any more details than that and then also you've got all the standard vulnerabilities that exist in web apps and native apps that if present may allow someone to steal an authorization code or an access token I offer mobile I briefly talked about the problem with redirecting your eyes not being unique there's also no currently no specified way for one application to hand a token to the other application and establish trust there are ways of doing it but there's nothing nothing specified and it's an area that some security white papers have looked into and found and found various problems in so for the last bit we're just going to

run through the four the four types we talked about and basically how how it should be secured and briefly touched on some of the other security security mechanisms that that you can use so in terms of user user authentication the key is to wait for the authentication code it's about the authorization server has to be able to bind the authorization code to a client so it knows who it was issued to on the implicit flow it's actually the responsibility of the client so the client there needs to be an interface on the authentication server that allows the client to take an access token and go was this issued to me and if not it needs to be able to

throw away the access token and I'm just reject reject that login this is actually what some of the bigger identity providers like Google and Facebook do for their implicit flow when you're moving to the authentication code on native the pkc II that was a bit the additional parameters that I showed of the of the code challenge me and the code going through and that that it that is allowing binding of two requests again there's also a new spec that's come out in the last probably two or three years called open ID connect that is building an identity layer on top of OAuth and it does this by issuing ID tokens in different parts of the flow so

it will issue them alongside access tokens and these are JWT tokens they they're signed and within them they have an audience parameter and the audience is basically the client that the token was intended for so you as a client when you receive a an ID token can look at it and go oh it's that me and if it's not you can obviously discard it in terms of the redirect your eyes from the client perspective you need to register one at which point is pretty much the responsibility the authorization server to check that the redirect URI had different the appropriate points in the in the protocol is the one that was the one that was registered there's two

point in the authorization code flow there's two points the first one is on the first redirect and then the second one is during the token request when the client is connecting to the authorization server it can provide the redirect URI that with the the code came in on as a as a secondary check same with the implicit meet it's down to the authorization server to check it for the cross-site request forgery within the protocol sorry within the RFC for the protocol there is a state parameter it's documented that it's intended to deep to mitigate this particular attack so obviously the client needs to need to include said state parameter the resource server needs to send it back

and then the client needs to validate it when it gets the appropriate requests in terms of granting authorization a lot of the driving too much authorization or homograph attacks are actually quite hard to defend against one probably one of the best ways is as an authorization server having a sufficiently comprehensive UI that you as a user can manage which applications are which clients you've granted permissions to which resources have been accessed and things like that so again if you go back to some of the big identity providers like Facebook and Google you'll be able you can go into your account there and you can see which which applications or which clients are associated with what

what features and for some of them you can actually see what they've been doing as well in terms of other mitigations client credentials we talked about why you should only issue client client secrets to clients that can store them safely token generation again if you using random tokens standard such as standard website and rules apply hundred twenty eight bit its minimum strong PRNG storing the token and the client secrets if they are they should be hashed if that's a high entropy so 128 bit random numbers they don't actually need to be hashed using something strong like decrypt just because there you can't guess you can't brute force 128 bits so you could use something quick like show

up to five six there's a lot of a lot of binding information I've talked about in the context of the other attacks there's also we talked about authorization codes being single-use actually enforcing that on the authorization server so removing it from say the database or the data table once you've used it is it's a good thing within the RFC there's also a bunch of stuff on actually monitoring so if you start seeing authorization codes that were issued to one client coming in from another you then as an authorization server that you need to be flagging that so that you do then something appropriate don't know what the song something appropriate will vary depending on yeah depending on your

policies but it's yes something to monitor likewise if you're getting if you're having refresh tokens that have been issued to a particular client turning up but being used by another client something something has gone wrong tokens of leaked somehow and and obviously the classic one you know brute-forcing against access tokens refresh tokens or client credentials you need to be monitoring for a number of failures and take appropriate steps sorry boom right the other one is have a revocation strategy so if if user account is compromised can you clear all the access tokens Refresh tokens that exist first set account if a client is compromised how do you how do you recover from that for for random tokens so that where they

just around my team you always have to go back and look them up in the database that's relatively straightforward you can just clear the tokens but if you are using other tokens such as sign tokens where you've got no record of them and they're controlled by their signs and the validation is done just based on public keys then you have a different problem in terms of revocation you need to push information to your resource servers or to your authentication servers and obviously the last one is a huge TLS the references will share the slides afterwards but there's a ton of it there's a ton of RFC's about this and a couple of other papers the these two are

really good in talking about the user authentication problem in and how it applies to both web and native and then at the bottom if you want to see how Facebook and Google do it and their various steps they there's very detailed instructions on how to implement stuff there you can see a lot of how they're mitigating a lot of these these threats and that's it so over to you guys any questions I

haven't really looked it's more a case if they are very big I didn't you know a lot of people have a Google account a lot of people have a Facebook account so I I don't want to make any comment on the quality or not I suspect they're very good because they are Facebook and Google and if they were other people would have looks but

yep delicious yes not just the crust so rather than just you essentially make a fake locking potentially yep users can

essentially authenticate the locking screws making sure that so just a well sorry just to rephrase that question is there anything you know or that can be used to prevent phishing attacks not really you're you're down to the classic training your users to only you know only trust HTTPS sites validate the URL etc etc beyond that there's nothing unfortunate

so you can have the just a question for the for the video is there anything in the spec that mitigates stuff through time there are recommendations within the spec within the threat model for things for the different tokens so authorizes the authorization code is of one use token and that depending on your implementation you could enforce an expiry time on that fairly short may say me five minutes or so access tokens that's a configuration call based on your your decision as an authorization provider you know if you're if you're if you're very worried too you can push that down to say an hour or two hours or three hours if you're if you're more if

you're happy with access tokens being around longer you could push it up refresh tokens are the most long-lived ones and the idea then then it becomes a trade-off between how often do you wash your users to relent ik 8 and reauthorize versus that is not and if certainly if you look at how most apps that are using this hour refresh tokens are a long time I mean if I don't think I've seen requests arre authenticate or reauthorize very frequently with with with apps or websites that are linked

any other questions and which case with that thank you very much [Applause]