BSidesMCR 2018: Securing OAuth 2.0 For Native Apps by Jonathon Brookfield and Fraser Winterborn

afternoon everyone so quick introduction I'm Jonathan I currently lead the security research group of blackberry moved into product security back in 2004 prior to that software engineer and this is present I think I'm a security researcher in the security research group library and youth work for emotions and written data so in terms of what we're gonna be talking about today we're to be talking about oath to give me a note give you giving an overview the protocol specifically focused on native apps so how how it's used on mobile we're going to go through some of the authorization grants these are the different ways that others can be can be used then we're going to dive into three

three of the many areas that it can go wrong so we're gonna look at redirect your eyes embedded browsers and carrefour cross application request forgeries then at the end we're just gonna rattle through a few of the other things if you're implementing OAuth as a mobile on a mobile client or on a server some things you have to think of got some references at the end just various various bits that we've read in or whilst writing this presentation so before we start I offers an authorization protocols so it's probably it's important that stick up the standard definitions of authentication and authorization so just reading from the slide authentication is the process or action verifying the identity of a

user or a process and authorization is the process or action of verifying that user or process is allowed to access a resource or allowed to perform an action normally you need to be authenticated in order to be authorized but with all things are a little bit different in that you can be authorized to do something but you're not affected will that's because you delegate authentication in the in the protocol but we'll explain more on that later so over to phrase us for an overview yep I hope toy sales take both rotational protocol so it exists foot will have one party to authorize another party to perform actions will never have a consists of four main roles so the

resource owner which is either the authorization server in the resource server and this is some service that provides a service to the resource owner so in our example this can be a web-based email provider and then we've got a a client which is the the third party that we want to authorize perform actions on our behalf but because we're talking about native bills - this is going to be an application running on a device so also knows the resource owner sore throats client for my operations on their behalf that the resource server and the authorization server is the mechanism their users to do this so the resource owner has to have some existing account of the authorization server so

our example the webmail calm its and these are signs into a word based email provider and in the received email the resource server provides some api on this account and which can be used for common operations so we've got list mail remail and some mail here there's some form of implicit trust relationship between the resource server and the authorization server and this is often achieved when in being the same on the same system and then the client offers a service that uses these api's so our example the mail robot which is an app's and logged in to your email account and we sent a receipt email for you the vintage Hoovervilles - is allows to

access the resource owners resources without the resource owner having to reveal their credentials so being purple we've got at the bottom here and if you hand over your password you're giving full access to the client to do whatever they like if you give them an access token which restricts in 23 actions you deliver to the scope of what they can do in your account and the access token is used to go out to dinner so the other event if you're an access token is it can be given an expiry so the authorization server went out there is only valid for a week so as soon as that's expired the client doesn't have access anymore but they can

also be refreshed so the client come back through your throat session server after the access token expires and request the new one and as long as still authorize no get Neve access token they can also be revoked so the resource owner at any time can go to the authorization server and say I don't want this client access my account anymore and then when they go and try and use their access token to to use an API in the resource server the resource server can send a sub mention tokens there's three main types and the primary ones the access token this is great to leave your relations of and issued to the client it's used by the client to

access api's in the resource server so this is used every time the client wants to access the API and therefore it's access token there's multiple years we've got refresh tokens which are created by the your server and issued to the point and these are used when the access tokens expires they found over their refresh token the authorization server observer in your access token and this is single or multiple you seek I never have one refresh token which you use every time you want to new access token or you refresh the Refresh token and less than we've got the authorization code this again right away all server issued to the client and it's a very short-lived token which is just

used for the client to exchange for an access token and so it should be a single-use and it's not always used depending on which mode of operation available theory so the basic flow is is called the authorization code grant so because we took my native OS the resource owner of an apple on the phone first thing they do is poke me up and request the connect up to their they webmail account the client then invokes the operating systems browser using a URL that we're going to more detail on the four contents of this later but the important part is handed over to the right insistence browser and when the browser goes in purchase like URL it

gets a indication from the salient and then we go through a thorough zation prompt and this is where he's where you're granting the authorization to the client so there the scope has been given here is access to the mailbox and sending email on their behalf so human that successful the visa process yes the bill throws a since it was under redirect back to the browser to their to send it to a URL with the auth code embedded in the URL this this URL has already been claimed by the operating system so the browser when it receives this URL invoke snap at the app receives the URL pulls the authorization code out and then it can make a direct connection

to your throws ocean server and exchange levels code or an access token and a refresh token so now it's got an access token it can make API calls to the resource server there's some time passes the access token expires and it then uses its refresh token it's gonna get new access token and a refresh token option so this bit where the client exchanges its authorization code for its access and refresh tokens is optionally authenticated and this gives rise to two different types of client we've got public clients which all native ovals falls under and in this case there's there's no authentication so he goes resolution server O'Connell's then to get the client and it's because the

client cause can't store any secrets and click you embed a secret an app and then distributed to the users it's not secret and the other type is confidential clients and this is more when they're but it's the other client of the web application so it's on the server the yeah the server can store secrets and the main advantage of this is a allowing as the authorization server to perform association between the codes that is handed out and the client and the lack of this in public and local native is certain cause of some of the issues we're gonna be looking at later the method of authentication is called client secret and it's just a password which exists between the two of

them which is usually created at registration times when the app developers building the wrapper they create a secret that this is early and so now we're going to take a look at the authorization code grant and in practice and for the purposes of this talk we've got 3 demo applications through skill mail robot which is not malicious and it's been implemented using the mitigation agree that talked about later but in secure mail robot which is again it's not malicious but it's not taking into account any of the security mitigations and then but mail robot which is actively malicious and will be the source of a number of the attacks so if I open up the mail robot app the

first thing they see is the option to pick your email provider so forgets a web man at this point the the client will redirect to the operating systems browser where that URL with some parameters in it and these have been broken out here but usually if this be completely transparent but sample of the client ID the top left which is the unique identifier identifies this client the redirect URI which is a URI this app is claimed any once it's coded to come back to and then a couple of state parameters which we'll go into more detail later so if a Bress redirect authorization server invoke the operating systems browser and sign it and then we're asked to

authorize is happening press yes when I handed back from the browser to the the app and received its authorization code press exchange for access token this is gonna go off and make a direct connection to the authorization server and exchange that authorization code for an access token and a refresh token okay and when I press save tokens is going to go away and use the access token it's got two and call 8p hours on the resource server I know we've got the apps but it's access token and it's there it's signed into user or prepared outcomes account doubt it well that's nonsense going to go into a bit more detail on some of these grants okay so the groups are the

different ways that you can use use others so far we've just been talking about the the authorization code code crime this is actually the only one that's been modified specifically for for native apps to add some protection to the authorization code that we'll talk a little bit more a little bit more we will talk about more later as well as that there is the implicit grant which doesn't protect the access token in the same way that the that the authorization code protects the protective orientation code both the implicit grant and the next one which is the resource owner password credential Clark grant I'll actually define for mobile but we put them we put them up for the purposes

of explanation because you may you may run into them the resource the recent owner password credential grant which is quite a mouthful is actually built or provided as as I sort of stated Barham aware where if you're migrating an application from just using username and password award you can start using this this grant and initially and then move it over to one of the other ones in in time normal although off defines four different grants but it's also reversible to to extend these all to change to change these and Open ID Connect defines two or three other grant types which are just different ways of getting access tokens or refresh tokens so this is the authorization code grant

very similar very similar to the sorry exactly the same as the one that Fraser just showed so you have the authorization request here they're going from the climb app to the browser you have the request being had handle to the passed on to the authorization server here the authorization and authentication part here and then a return of the authorization code from your server to the tooth browser and then to client app then grabbing the change in the client code for access tokens here and then using the access token to access resources here and then you have after timers past you have the access to the Refresh token being used to get grab new access tokens so moving

on to the implicit grant just a highlight the difference is so here at the start it follows a very similar similar flow to the authorization code runs you have an authorization request that goes from the client app to the users browser then we go through then that goes from the browser to the authorization server then the authentication and authorization steps happen but in the implicit grant rather than returning an authorization code an access token is returned returned directly this this thing gets to the user agent and is ultimately redirected back to the client app obviously one of the differences here is there's no refresh token so when the access token expires the client app will have to go

through the whole authorization step here again this was originally written for JavaScript based web apps that don't that don't have any any way of persisting refresh tokens but it's as the most simple of the grants you may run into it sometimes in in mobile so the next one is the resource owner password credential grant and here the resource owner or the user just enters their credentials straight into the client app and then the client will just pass those credentials and the request is to go straight to the authorization server obviously this grant doesn't separate me it doesn't separate the credentials from the client so the client has as well as access queue credentials full control over what

access it requests to Europe your account when the authorization server gets those and validates the credentials it'll then pass back an access token and a refresh token and at that point it's exactly the same as the the authorization grant so now we're going to move on to talk about the redirect URI and some of the vulnerabilities that exist in with it specifically on on mobile so when the client is making an authorization request it sends a URL of the following form as you can see on the top within within the URL we have the client ID which is just a unique identifier for the client and we also have the redirect URI so this is the

address that the client wants to receive the authorization code or the access code there are two types on mobile there are system your eyes which are any protocol and then there are claims your eyes which are either HTTP or HTTPS so what happens when having passed the redirect URI to the authorization server once the use has been authenticated and authorized the authorization server will then pass back the auth code or the access token appended to the redirect URI in the form you'll see here and then that'll pass from the authorization server back to the browser and then to the client and then the client can use the authorization code or the access token as needed so now I'm going to pass over

- Fraser to talk a little bit more about the details of what the euro eyes looked like and some androids the the client help registers its redirect URI in the androidmanifest.xml file and this is the data section here so for a custom your eyes scheme mandroid you can use HTTP HTTPS or anything you like so here we fair we Peter walls is the skin and we've got the E and then we've got the rest of the components to the URL there and this is completely unbearable anyhow can register whatever it likes and but when you the first time you go to visit one of the earth links or this on the browser tries to free right

interval and proper to pop up saying which app you want to use to open this so say you want to use your own system browser or do you want to use web is installed is registered it I'm clinging to your ice this is this can only be HTTP or HTTPS and the difference is it's got this all through verify it was true and attribute in it and basically this course is the operating system install time to go off to this your air to the URL you mentioned and try and verify the Europe actually owns this URL a consequence of that is the browser have mobile operating system has more trust in it so it doesn't have to do because

that so come with article you redirect into your app on the server side said this is what this looks like so it has to be a valid HTTP URL invalid certificate and then you put a link location in the well-known folder and inside is the package name of the application and the shaft to 4/6 certificate lubbers use destroying the application and as long as this is overlays in the OS can see this it'll let you automatically handle those those URLs in your iOS offers pretty much exactly the same thing and custom URL schemes they're a bit more restricted in you have to use a custom protocol you can't claim HTTP or HTTPS and this is

done by embedding this in the being photo penis club this is again is completely unverified and when you go to browse to one a piece on iOS it'll pop with do you want to open this in this app promise there's no picker and because there's no picker it does attempt to try and have some state so the lowest that went into the browser will be the one it tries to come back from there's also associated domains and this is almost identical to Android you have to be HT to PhD yes it's verified in school time and this is in Sophie project settings super site again very similar has to be valid HTTP URL in the apple app so I've associated

gob and in here you move to the bundle ID with developer ID and one difference on iOS is he registered pads as well as he don't just claim the the domain you can claim the sort of person true it's now we're gonna pick so the reason we went through all of the explanations is ultimately if as a client if you're using the incorrect type of URL a malicious app on the on the same device can have already claimed to know have already claimed the the URL that your the your client sorry that you want your authorization codes or access codes to be redirected to and if you've already accepted that application then a well-behaved application so the

malicious application will be able to intercept the authorization codes or the access tokens for another app that's installed on on your phone now because the authorization code can then be swapped for access to your access to your mail it effectively means something a malicious application can grab can gain access to your resources in terms of the the different URLs if you're using custom your eyes that you'll generally vulnerable to this because there's no way to claim ownership in terms of claims your eyes on Android if you haven't proved or claimed ownership you may be vulnerable as well on iOS it's not possible he's a clean dri without providing without proving ownership so ultimately you need to prove ownership or ideally

you prove ownership to prevent this but there are other ways which we will talk about now in terms of what that looks like so here we have client app performing a standard authorization request to the browser then a standard exchange between the the browser and the authorization server here but at this point when the authorization code comes back to the user agent it gets redirected to the to the attacker controlled app or in our case bad male robot and then that application can exchange the the code for some access tokens and then ship them off to an attacker controlled control server and then once the attack once the attacker has your access tokens he can use them or pay to use them to

access resources on the resource server and if they've got refresh tokens persist for they can persist access to your account for as long as the Refresh tokens are valid so but Ephrata to show you what that looks like in practice so in this example we're gonna go t-pins to kill my robot and refuse the web mail and you notice here we've got the point many of CTL male robot and then the redirect here i were using is a customer it's say there was two protocol and and then from far away and skill and this is also been arranged with my bad male robot so when I go through rewrite to the ortho rotation server same process

again so we can applause Fry's house insecure male robot he gets passed off by it's about my robot now it's called the authorization code change that's the access second

and then let's take a look in your speak access token to go and login take you to my mail becomes an email account it's now we're gonna look at Annette to get this so within the when the the client is making an authorization request will be O of two own native RFC they defined a new part of the protocol called the proof code exchange and the idea is that this allows the authorization server to associate a an authorization request with a token exchange so what the client does is it generates the secret thank generator hash of the hash of that secret and sends that in the PK seee variable to the server the code challenge method is just the the hashing

method that's used so then don't consent to the authorization server and after the user has been authenticated and authorized the authorization server will then keep that pkc e information and associated with the authorization code that it returns when the client is then requesting requesting access token and a refresh token using the authorization code that it's been given it then sends the the secrets of the PK c e in the Claire at which point then the authorization server can look at the access code and the hash secret that it's been given complete the the hash secret and compare it to the one has just been given by the client and at that point is bound the authorization

code that was issued to this client at request and if they Mac then it returns the authorization code to the clients so the idea here is if I as a malicious app get hold of your authorization code I don't know the secret therefore I can't read her I can't supply the correct secret during token redemption or sorry token request and therefore won't be able to convert an accessed sorry an authorization code into an access token and a refresh token so just as a summary for on native apps the clients must use pke and the authorization server must require pke for public clients and perform the appropriate validation during the token request for redirect URIs in general the

client must register a full euro with the authorization server there's a previous talk the phrase from I did I will native for web and we talk about that a lot more but if you don't have a prerequisite of your eye you have got a similar problem the the authorization codes can be redirected anywhere for implicit things are much more constrained so the only way to use the implicit grant correctly or securely is to use claims your I therefore the redirect URI and ensure that the client has proven ownership of that URI because again otherwise any other client will be able to register the claim claim euro and the same rules for generally for implicit apply in that it must register

a full register a full redirect URI would be with us with the authorization server so moving on to the the most vulnerable T this is this is using using embedded browser within your your native app so up till now all of our examples have shown the client using the the system browser however if you just if you decide to use well for you or malicious decides to using webview then the browser part and the client are part of the same process so at that point the client site is able to interact with the webview so access information that's passed and interact with all the pages so it can still Ukraine shut this gap sorry it can steal

your credentials and it can do things like automatically authorize automatically authorized user are you seeing the authorization dialogue it will just it will just click on here what's must be for you in terms of what that looks like so here we have bad male robot we have we have the client app part and we have the webview but they're both within the same process so the client starts an authorization request and that that goes to the webview webview them requests the login page and then the user enters their username and password here and in webview they go to the authorization server but also they get recorded by the client app and then the authorization server returns the

authorization page but rather than being displayed to the user it's automatically posted by the by the client app and at that point we just move into a standard authorization code flow so freezers can I show you what that looks like in practice so in this example ham user has been posting to installing the robot up with it installed accident and they're gonna follow the standards has standard flow so the request and to connect a web mail and notice these parameters are identical to the ones that was hanging in the secure case so it's like it's spoofing the schema our robots client ID and redirect URI and it's sending all valid state information so I would pkcs

in there well I guess redirect and you know that doesn't go off to the you know browser it stays inside bad mail robot process user signs him yeah prompt that to me operating system so the clients and installing it and that the authorization was automatically advanced without me doing anything again so in that send that off the North code off to the authorization server and with a ballad pkc and we get access tokens a refresh token back so if those and their battle male robot is going to be associated up to the user or webmail that comes account and as I existed arena and then can we're going to cook medication with a set okay so the mitigation for this one

is fairly straightforward it's where possible use the the system browser but because actually the root cause of this is malicious apps you're unlikely this this particular mitigation probably won't work so you end up having to fall back or user education so ensuring that they only install trusted apps it may be possible to educate users as to the difference between a webview and a system browser but it's quite subtle so not really sure how how that one would work so now we're going to move on to cross cross request forgery very similar to cross-site request forgery but this time in the working in the context of native native apps so the interior with cross-site request forgery is an

attacker gets a an authorization code from from connecting to the authorization server so they look the attacker logs in using their account and then they capture the authorization code and then they send the authorization code direct to the client using the redirect URI as as shown here so what this allows the attacker to do is to connect their their session - oh sorry their account on the client to the user's session so if you if you had already logged into mail robot and an attacker formed this attack on you it would then switch the account that you were using from your account to the attackers the idea being if with the mail robot it could the attacker could then monitor

maybe the your usage of the api's or the mail that you were sending as as per cross-site request forgery there are different ways that you can perform this attack so URL and a phishing email URL and a webpage or if you have a malicious app on the almost on your mobile and could just perform as a direct direct IPC call in terms of what that looks like so your client app has has already performed full o flow here the attacker connects to the authorization server they authenticate and authorize for their account but Rob redeeming the code for tokens they send that code to the client application the client application then gets the code and goes

I've got a new authorization code and swaps that for access tokens and refresh tokens and then start using the access token of a refresh token that belong to the attackers account and so for is going to demo what that looks like so in this one and the attacks start off by present even the the web version of the web my authentication authorization Crump's and then something with their own religions and then the authorized access to their own account and in response they get back an authorization code which they can go and embed in their own website so this URL here it's is rewriting practice here in skill mail robot with the LS code that they've just

generated so now using some fishing method or managed together the the victim to visit this website and they click a link this automatically invokes in secure mail robot which will rush to commit process the earth code and exchange it for an access token and then once it's got that access token is going to automatically seminar and access the resource service api s-- and because this is an access token that belongs to the attacker or FC signed into the attackers account now so we have access to their mailbox but anything that we send is also going to go to their account so if they were to go to the web position of webmail and login they'd see

everything we were sending their mates in descending again you look at the medications that's all so very much like the mitigation for cross over cross site request forgeries the mitigation for cross application request forgeries is a value that the client the client knows so specifically the state parameter so we on the authorization request the the client now adds the state parameter which is around the values to to the redirect to your right this thing goes from the client to the system browser and then on to the authorization authorization server and once the client has been authenticated and authorized the authorization server returns the redirect URI to upend the state parameter that was previously provided to the redirect URI

this goes then back from the authorization server to the browser and to the client and at that point the client combined the authorization request to the authorization response so the other bouncing back briefly the other the other thing to note is the pke does and indirectly prevent this this attack as well where where the client sends the the hash the hash of the secret in the authorization request because when it when it when the client then comes to redeem the authorization code if the the authorization code has been provided by by the attacker there is no way that the client will know the the correct secret so the redemption of the authorization code during the token

request will will fail for the implicit grant though you are completely reliant on our state so just in in summary the authorization sorry the client must include a state parameters in the redirect URI and the authorization server must return that state parameter and then the client the client must validate that they match for as I previously mentioned pkc will also prevent this for on the authorization code grant the other the other thing that a client can do to partially mitigate this is to not accept unsolicited authorization codes or access codes while it won't mitigate it completely it reduces the window so it's it becomes that erase can erase between the attacker and the user whenever

they're performing an authorization request so we've we've looked at three of the more tricky complicated vulnerabilities within with an OAuth there's actually a full threat model for a wolf on web which is RF RFC 681 nine within their the threat model has 50 different threats and countermeasures and their section 5 which is the security considerations has a lot of detailed detailed countermeasures the next RFC is 8 to 5 - which is o of T for native apps and in there they go bad an additional 12 specific security considerations to think about for for native so the next couple of slides just to give you a point there of some of the other things to think about with OAuth so if you're

using if you're using OAuth on Windows or Mac they don't have the concept to claims your eyes or system your eyes so you have to use the loopback device and there's this is complicated our author is actually an authorization protocol although it's been co-opted to be turned into a user of a user authentication protocol if you're not very careful about how you bought the binding between access token and the client it's quite easy to to fake or to end up being authenticated as a different user there's all the classic issues with authorization such as asking for - my client asking for too much access and some homograph attacks there was one two or three years ago on Google that made

the made the headlines in terms of client credentials as with any anything that's the password storage of them is it's a problem token generation obviously the access tokens and refresh tokens and authorization tokens need to be not need to be sufficiently large and cryptographically strong so they're not they're not guessable also they're stored now they'll need to be stored essentially in the authorization server again for things like the refresh tokens these are equivalent to long left passwords so you need to be mindful about while storing as during them in terms of transport all the all the RFC is recommend T's TLS obviously if you don't you can have fun and steal them using a variety of

network attacks in terms of some of the mitigation so if you're doing anything to do with Windows Mac on native apps is best to read the RFC there's a lot of complexities around the loopback device user authentication we covered this in detail in presentation pieces leaks you have to basically ensure the active the access token was issued to your client on the authorization side of things it's mostly just about providing a UI such that the user can manage everything manage all of their authorization so notify users when you ones happen etc etc client credentials we talked about they should only be issued to web clients are not native token generation its standard stuff strong PRNG 128 bits

or greater in length in terms of storage if you're using high entropy tokens you can get away with just just a single sha-256 on them fine rather than using a much larger more complicated function like a script or bcrypt because they've got a they've got a very high entropy I'll skip a bit about token binding so we talked a bit about some of the tokens about how how often they should be used that's or until ears and things like that again all considerations that you do you need to think about if you're running an authorization server the other thing that the threat model talks a lot about is monitoring so there are various things that if

you're running an authorization server you could spot such as an authorization code being used twice or if particular bindings that you know should happen so if an authorization code issues by a client that shouldn't have access to it it means something has gone wrong so all of these are in the you can monitor for and they're indicators there's been that there's some compromise or something strange is happening within your your environment in terms of revocation revocation strategy this is basically if something goes wrong how do you deal with it so if an access token or a refresh token leak what is your well if your mechanism for dealing with that have a client secret leaks what if your

mechanism for dealing with that and [Music] finally the mob is one use TLS there's a couple of pages of references I'll leave them up there for a few seconds I will will try and put the slides up and I believe the videos will be up anyway so yeah and with the exception of one thing so currently just a very quick one BlackBerry's Cranberry so security researchers Security Response section ears program managers developers if you're interested come join us and thank you very much

thank you very much that guy's is really interesting do we have any questions yes we do problems come on Damon follow these stairs you got a shower there but up until we've got to use the mic maybe the kids just run a little like an idea just a quick question on the redirect URI attack I didn't really get how the malicious application thumpers with the legitimate applications redirect URI to change it to some malicious Kanto state with irregular I could dump it with more because the malicious applications registered that prince is a good new alright with the operating system so if he was installed first the unregistered got one before we would want it so he gets redirected on do have any

other questions Rafi I am so for the first party applications who might not necessarily want to open up the web browsers you want to provide a better experience to the user what would you recommend to be using for accessing the earth's resources and there is narrowing iOS sound and you can embed the operating systems brozen with an application which i think of it because it's a bit more complicated but it's it gets the same effects have having the pros where they can process but you can still invent it within your application procedure to bring come out on the application and for them because if the different process doesn't help up primitives over as opposed to using my

credentials where you just provide the username and password because it's the first party up anyway so it's less of an issue provide credential to staff you say

you mentioned that some of the security depends on the user entering data into the the system browser how is the user supposed to recognize the system browser from an actual malicious attempt to look like the system browser I had but the trick is if you know education and it's not anything what to solve and that probably no technical solution to this in Android developed some stuff nowadays for showing trusted dialogues so she think there's a potential for something like that that would launch a browser in a way that the user is guaranteed to be able to recognize again if definitely either knowing the loss while they're there interacting with so thank you do we have any more questions don't you

thanks for talk mitigations one of the medications you consider for the authorization server which gives the tokens out I mean because obviously that's potential attack and also you talked about knowing behaviors which were unexpected so what's what implementations have you got to sort mitigate against that so all of the stuff at the end is basically a very high-level summary the stuff that's in the threat model the the threat model we'll go through in detail when what you need to validate when you before you hand out an authorization to an authorization code so in the instance of a web client you should be authenticating the client before you authenticate the client and you check that the authorization code was actually

issued to for that particular client the native side it's it's it's about using pke so you're always you won't you only issue an authorization code to an authenticated user and then when you're swapping your when you're when the client is redeeming the authorization code depending on the scenario so with web you authenticate the client with native you authenticate that it was issued to the same the same app all of the behaviors so what to look for our reference in the threat model one thing to know on the implementations that I've looked at none of those none of the monitoring was actually there so yeah absolutely the I've looked at a few internally and they haven't had though they haven't had

the the monitoring that you would expect yeah I mean obviously it's about policy then in terms of what you decide to do in the instance of all that happening but they just didn't have they didn't even have the hooks for for they in there so you can you're going to end up writing you writing it yourself superb any more questions so my billing to what you just mentioned there around some of the investigations you've done but with UK banks now having to open up their services for our API and I was particularly being utilized for payment service providers account service providers have you happen to do any research and identify how well or otherwise all these providers are

implementing their apps no idea zooom any other questions nope so just can we put our hands together for trying to bring praise I thank you