Using PKCE to Communicate Between React and Native Mobile SDKs

Hi, everyone. My name is Itay Hansky. I'm from the scope. And I came to talk a little bit about communicating between React apps or web apps in general and native applications or SDKs. I want to kick things off with a question so you understand where I'm going with this. So have you ever built anything that was for the web, was really nice, but you wanted really to use it inside of a native application? Well, that's exactly what happened to us at the scoped, where we offer authentication and user management as a service. And one of our coolest features is that you can customize your own authentication in our no-code editor including UI and everything, and with a few lines of integration, have a very nice, fully fledged login screen and authentication in your web apps, which is really, really nice, but we didn't want to leave our native application builders behind, so we thought, how can we bring this nice capability to our native builders?

I know some of you will relate. So the next thing we considered was, how about we just take it and embed it inside of our UI using a WebView? For those who don't know, a WebView is basically a UI widget which runs a miniature version of the browser, so we can just have the web code run in there. The problem is that WebViews are considered insecure, and actually, some of our authentication methods will simply not run if they're running inside of WebView.

So we were left with the browser, but fortunately for us, we can run the browser in an embedded mode, which feels for the user a little better. It doesn't feel like you're moving outside of the application when you actually switch to the browser. It feels like it's part of the application, even though technically we're running on a different process.

Okay, great. So we have our solutions set, so I guess all we have to do is launch our embedded browser, Safari or Chrome, and run our flow, and then get the callback somehow into our native code or run some JavaScript or hack into it. Well, unfortunately, mobile processes are completely sandboxed. That means in simple terms that you can't really access data between processes, and that's good news for us users of the mobile phone, because otherwise things would be a mess.

So what can we do? We can start the browser, we can launch it, right? So how would we get something back to the native layer? We can utilize deep links. Deep links is a way for mobile applications to declare that they can handle certain URLs instead of opening it in the browser. Think of the last time you got like a text message with a YouTube link, and when you clicked on it the application opened, right? Not the browser. So it's the same concept here.

Okay, great. So now we have a way to get back into our native code, but we can't simply send the session on the redirect URL because that's completely insecure. We should have some form of exchange protocol in place, and that's where Pixie comes in. Pixie or PKCE is a nice protocol. It stands for Proof-of-Key Code Exchange, and you can implement it any time you need. It's kind of geared toward mobile, but not necessarily so. I'm going to go over the Pixie principles in general just so we understand it, and then I'll show you how we used it to get flows running on our native applications. So, Pixie runs like this. The client generates the code. This is considered a key. It's just a random array of bytes and hashes this key. This hash is where everything starts. This is considered the challenge. This challenge is sent to the server. The communication is base64. But I don't want to focus on it, because it's just an encryption layer, and it's not interesting.

But I don't want to focus on it, because it's just an encryption layer, and it's not interesting. The challenge is then received by the server, it's saved, and the server answers with its own generated code. So it generates some random string. It's called the authorization code, and that's what it answers the client. To complete the protocol, the exchange, the client takes the authorization code just received and sends in the original key, the unhashed version. Now the back-end can compare codes and hash the verifier, the original key, and compare it to the challenge it had saved. If everything matches, we have a successful exchange, and everyone's happy. But if something is misaligned, everything's deleted and you have to start over. And the nice thing about this protocol, if you notice, the client never sends the same thing on the communication channel. You can't really deduce the verifier from the challenge, right? That's how hashing functions work, otherwise we'll all be in big trouble. So getting it in the middle of this protocol is quite hard, and it makes things very secure.