Going Native... with Mobile App Authentication

Yeah, so continue on a little bit in the mobile vein here, but in this particular case, not so much about security, a little bit more about user experience and how does that play with standards? So a little bit about me. I'm a identity architect. Been doing consumer sort of in facing identity for a good while now, also a hobbyist photographer. This picture from last year here in Berlin, I have one more here in this deck as well.

Okay, so mobile authentication. Some of you may be asking, why are you talking about this? What does this mean?

Like, haven't we solved this already? And for some, for the most part, I was in that camp until last year at an identity conference like this. A senior product person came up to me from a very substantial company and said, Hey George, what do you think about someone doing the authentication steps in native UX within the mobile app? And that sort of started this journey that has combined with some other people in the industry to look at, can you do this on top of standards in a secure way? And what are the implications?

So to get started, let's look a little bit at what happens today in a normal mobile app authentication experience, right? First you get your app, you go to sign in, this is IOS's yay Apple mechanism. Like here's this little interstitial for user privacy and intent, you know, intent collection. Do you really want to log in using this particular iden? This really this domain, right? This is what they're asking you in this particular case. Example app is being asked the user of example, app is being asked, do you wanna log in with example.com, right?

Then you get this sort of funny full page ish kind of UI that has an back button on it and a little x that's effectively a web context. And I go through the web context, you know, maybe I'm doing MFA and then I get logged in.

So the, there's actually the sort of context switch between the native app and this web context. And you know, Android and iOS are trying to make that as convenient as possible, but it still is sort of there for the user. So from a sort of OA spec perspective, it works like this. The mobile app invokes some external context, whether that's a custom Chrome tab or an as web authentication session. That thing then talks to the authorization server, you know, the authorization server sends back some web response, a whole bunch of outta scope stuff happens, right?

Then you basically get back your code in your state and you can pass that back to the mobile app and now it can go get tokens. So that's basically the way OAuth works, right? Black lines being OA speck, red lines being out of scope.

So why, you know, what's the situation here? Why does it even work this way? In reality? And the reason it works this way is because OAuth and to some extent open Id connect built on top of OAuth were built for the context of federated authorization and federated authentication. So the classic example being I go to LinkedIn and LinkedIn asks me, Hey, do you want me to import your Google contacts so that you can find matches within LinkedIn? Right? LinkedIn and Google are completely different companies. They're completely different trust domains.

And we want to ensure that when the user LinkedIn gives permission via Google to, for this transaction to occur, that LinkedIn has no way to see the credentials of Google, right? When we're talking about mobile apps, if my mobile app just opens a web kit view or WebView within the mobile app, it's got full control of the dom, it can see everything, right? And so explicitly, your best practices for negative apps open Id connect are saying you must separate the contexts within the mobile environment so that there is no way for the, the one party to see the other party's credentials.

So that's kind of the, the rationale here behind what's happening. Now, do we get some benefits from this web context switch, right?

We're, we're in a web, we're we're in the native app, then we go to the web context, then we go back to the native app. So we do get some benefits, right? Because the authorization server is driving that experience, it can basically add anything it wants into that experience. And the mobile app is sort of agnostic, right? All it's waiting for is when you're done doing whatever you're doing in that outta scope stuff, give me back a code, right? So there's, you get that kind of mechanism. The did I cover all of 'em? Basically you, we've, I think I've covered all of 'em, so sorry about that.

The, you've got the secure, you've got that sort of separation. The cons is that generally the, the interactions is different, right? So the look and feel is slightly different.

The, the context switching is visible to the user. And in, in the, and specifically in the case of iOS, you get this in implicit prompt that is sort of outta scope. So if you think about it, the, that may be useful if I'm an example.app trying to log in with Google, but example.app, trying to log in with example.com, that feels a little weird to ask for that sort of intent situation. So for those in the audience, either developers or product owners, have you ever had this conversation as in why does the user have to log in in a WebView and raise a hands? So a few, a few of us, right?

I have had this conversation many, many times and it's always this sort of, well, you've got all this security stuff and you're doing it this way. And that's what the standards say.

So this, you know, this challenge to me last year really got me thinking, is there, do we have the mechanisms now in place that would allow us to, let's say, enable a native authentication mechanism? So before we get into whether you can do that or not, I, I need to sort of describe two aspects that have come into play in regards to mobile apps. And this is this concept of first-party apps versus third-party apps.

As I said, when we designed OAuth and Open Id connect, it was all about the federated context where I have two different trusts domains. However, as people looked at those protocols, they were like, these work great for my mobile apps, right? And so you've seen a lot of people leverage the protocols in what would be a quote unquote single trust domain environment. So we call those first party apps. So I spent many years working at aol, and when I left the company, it was called Yahoo.

So you, if you wanna track that trajectory, you, you can do that as a, as a fun experiment or as fun investigation. So we had lots of mobile apps, right? And so our mobile, our AOL mobile app would effectively use OAuth or Open Id connect to get logged in from the AOL authorization server. This is kind of a first party app. The third party apps, right, are then the ones that sort of cross trust, trust domains. And this is really critical when we think about whether it's feasible to enable a native authentication experience because a first party app is in the same trust domain.

If it sees the credentials, that's not the same ex security exposure as a third party app in a different, you know, in not the same trust domain as the authorization server open. Id connect provider seeing the credentials. So what might be a path forward as we think about this sort of problem space? So the first thing here, right, is that what we're trying to do is we're trying to create delightful user experiences for first party apps. And I sort of wanna call out that first party apps because that is the, the sort of the constraint on the overall problem space.

We're not talking about third party apps though. Maybe if we have time at the end, we can talk about could this even work in a third party case in very, very narrow scenarios. But generally this is a first party app kind of space. And what do we need to do in that context? Then we have to have a secure way to identify a first party app. So that's a sort of critical component. We need a way for the app to sort of inform the authorization server that it wants. This kind of an authentication mechanism, challenge response sequence kind of a thing over the standard web environment.

And if you think about what often happens, and you think about Ian's talk yesterday about ceremonies and moving toward recognition, the, the MFA concept or the step up authentication mechanism would be really, really convenient if it could be done in a native way today. If you think about it, I have my mobile app, it's got tokens, I'm doing stuff now I go to do a transaction. That transaction requires a higher level, I have to reopen the web kit. I don't actually have a good way to pass context of my current session into that web kit or I mean into that sort of web experience, right?

So that it can sort of like transition the, the level of security I have already into this sort of web experience and then, you know, get the extra level of security and then get me back in, right? If the app could just open up something, you know, maybe that's even, you know, leveraging past keys or FI or whatever that says, do a touch ID or a face ID and then I'm done, right? But yet still all based on standards, that would be a really delightful experience. So this is maybe not the best way to represent this ui, but you know, here's an example, right?

I hit, you know, I need to sign into my app no more back buttons or X's just ask me for my credentials and are my code and I'm in. You could think about this if you want in that sort of password list, kind of a world where the sign-in button little pop-up says, Hey, log in with face, ID click yes, face ID is done, I'm logged in and that's it, right? But yet still all based on top of all of the goodness that we've built and the security mechanisms that we've added around OS and Open ID connect. So that first step is how do we securely identify a first party app?

And the OS vendors have added things within the last couple years that make this possible. So the first thing is an app attestation. The app attestation gives you, let's call it a function of the key that was used to sign the app for it to go into the play store. And if you have that func, you know, if you have that function, a key fingerprint or the key itself or what the public key itself, right? You get that in the app attestation, you can compare that against a list of things that, you know, as first party apps.

There's a device attestation, which gives you some, you know, level of assurance, maybe not complete level of assurance that the device hasn't been jailbroken, right? And you can combine both of those things with dynamic client registration in a way where the mobile app creates a public-private key pair. We saw that mentioned a little bit in some of the criteria in the last talk and, you know, registers as part of the dynamic client registration, a public key. So now I have a very strong cryptographic way to prove the identity of this particular app instance.

So that would give me a good way to do the sort of identification of first party app. For the standardization part, it really falls into two sort of key elements. One of 'em is that signal to the authorization server that hey, I want to do a native based authentication. And the other piece is, okay, if the authorization server says, yes, you're a first party app, now what mechanism do we use to do this challenge response protocol? And you know, so those are two key components.

If we were, if we standardize this and there's a, a couple of questions that come in here, should we just standardize the first part, which is how I do the signal, but we leave the rest of it somehow outta scope and an authorization server could document, here's the pro, here's my challenge response protocol that I'm gonna use, and then the app developer, you know, just meets that, but we leave that outta scope from a standardization perspective, or would we want to go all the way to define a challenge response mechanism and to be in my conversations that I've had and the other people have that I'm working with, the jury's a little bit still out there.

I think, you know, for sure we'd like to do one, whether we need to do two or allow further the, you know, people to document the second option or not. It's still something. So if you have a strong opinion on that, I'll have my contact information at the end of this talk and would love some feedback. So if you think about today in the OAT specification, well actually it's actually in the open Id connect specification. We have this parameter that we call response mode. And effectively it amounts to how do I wanna get the data back, right?

And we have things like form post and we have things like query and we have things like fragment. So one option would be ex, you know, add a new value into the response mode mechanism that would say, Hey, I want, I want the response in a native way as opposed to in sort of a web-based way. Whether again, we need a mechanism parameter to say what mechanism you're using or not, so that the authorization server can determine that there's a bunch of things outstanding here. This is sort of the nascent beginning of how might we, you know, turn this into a spec. So what would this look like?

Now you notice we only have two parties. The first diagram with OAuth, we really had three mobile app browser context or, and the authorization server. Now we just have the first party native app and the authorization server. And so I can send in my authorization request again, debate in the community on whether this should be its own unique endpoint.

It should be something that's the par endpoint for those who are wondering what par is, it's pushed authorization request and it's a special endpoint where you can basically submit in a back channel way your authorization request and get back a context that you then pass to the authorization server. Should we sort of extend that or do you do something and extend the authorization endpoint today itself?

So, but effectively the mobile app is posting some data or making a request, direct request to the authorization server, right? It gets back the, you know, maybe it gets back a ask the user for their username or you know, do a pasky, you know, Fido web authentic challenge or whatever it is, right? The sequence starts, I can handle authentication, I could handle mfa, I could handle consent if necessary.

Though, in first party apps, consent is normally turned into implicit consent, whether it should be or not, that's a different question. You know, if there's a fix up flow, like, hey, something happened on your account, you need to take some sort of action. All of that could be managed in effectively a native way. And then at the end I get my code and I can get my tokens via the token endpoint. So if we do this right, there's a couple of things that are important.

One, we need to keep the domain constraint to the first party apps. We have to be able to securely identify those first party apps. I think it's really important to understand that we're creating a tighter coupling between the authorization server and the mobile app. If the authorization server decides it's going to add some new authentication method that the mobile app doesn't know how to represent the user in a native control, you can't really use that. So what does that mean for the authorization server?

You know, is there a mechanism that it needs to remember, oh, it's this partic, you know, this particular instance of this particular mobile app only has these capabilities, so therefore I can only interact with it in these ways. I'll, I'll get to a potential mechanism for that. But there is a tighter coupling. It's important to remember that we must have a fallback to a webflow. So this could sort of handle that, like, oh, you need to do something new. That old process is somehow invalidated. I need you to do something new that you don't do.

You know, I, I need you to sort of fall back to the web view so that I can actually get you logged in. And then as in all of these sorts of scenarios where you're doing logins, you don't want to create an environment for the user where they're consistently logging in with the same credentials in environments or in UX that is widely disparate. Because at the end of the day, that makes them more, more, what's the word suspect, not suspect susceptible. That's the word I'm looking for. They're more susceptible to phishing attacks. So for next steps, this is sort of what's happened so far.

I've been working with Aaron Perk and Peter Castleman bring, you know, i, I dunno, maybe it's my age. On, on this, we presented some ideas at ITF one 16, we're planning to have sort of a draft spec for one 17 and the link to the presentation for I F one 16 is there in this deck. And if you're interested, watch the OAuth list serve When we get something that we think is ready for, you know, input and issues and those kinds of things, we'll be posting it there.

So with that, I'll wrap up thanks to one of my colleagues at Capital One, Josh for some of the visuals and obviously Aaron and Peter for their collaboration on this work. Thank you. Thank you.

George, maybe we have time just for one question. If not, you can always talk to him during the coffee break. Anyone? One question.

Okay, Thank you. In the first party context, why do we do still wanna do this O off dance? What advantage would it have when the native developer just do whatever, what the heck a native app did in the past, they, whatever they've been doing so far. So I think that's a, it's a interesting question. I look at it as oftentimes when native developers just make something up, they actually miss some of the security best practices that are out there that are, have been documented by the standards. And so you tend to not have as secure an environment.

Absolutely you could, you could do that, right? But then you have to sort of reinvent kind of everything, right? You have to reinvent the step up mechanisms. You have to reinvent the, you know, a challenge was, well it's not so much that, but yeah, you have to reinvent things like if you wanted to do a, you know, the, the rich authorization request by sending extra stuff, right? You have to reinvent a way to do that.

And generally what happens, at least what I've seen is that when people reinvent things right, they tend to cut corners and then the bad guys come in and, you know, take advantage of those corners. So for, that's why I would much prefer to enable this kind of capability on top of well-defined, well-proven mechanisms as opposed to proprietary ones that may or may not meet the necessary criteria. Thank you George. Maybe another round of applause.