The Future of Identity in the Mobility Market

The Future of Identity Mobility Market: At Coord, we spend a lot of time trying to connect systems together to make life easier for users and developers, and one of the biggest challenges we face is how to handle identity. Every time a user has to enter a password, they have to take time and mental effort away from the task they want to accomplish. And every additional piece of information you need to remember makes your life harder: did I change my credit card number on the bike share app yet? What about with my favorite ride hailing service?

Users want identity to be seamless but under their control: it’s rarely at the front of a user’s mind, but when it is, it’s very important that they have full ownership of their own information. For us to make this happen in the mobility market, we have to let users manage their identity easily across multiple systems. This means that unlocking a bike from an operator you’ve never used before shouldn’t involve entering your email address, password, and credit card information all over again. This is even more complicated for shared mobility services than it is in other industries because of liability and the law: drivers’ licenses, age verification, and insurance checks can often make account creation quite involved.

Luckily, web standards are increasingly allowing users to easily and securely connect their identities to be across apps and the services they depend on. Below, I’ll describe how we think identity should work in a modern mobility marketplace, and what we’re doing to make it happen.

From Social Sign-On to Open Identity

You’ve probably seen a dialog like this on a website:

This dialog uses the OAuth 2.0 standard. This standard was built to allow users to delegate authorization from one service to another: it helps you tell a service you’re using what data it’s allowed to see and what actions they’re allowed to take on your behalf. But these days, you mostly see it used for social sign-on: the only authorization you give is for an app to see your name and email address.

Here’s a simplified view of how OAuth 2 normally works:

An OAuth 2 permission flow

This process is great at helping users sign up speedily with new apps, but it doesn’t solve our problem. In particular, this flow is optimized for services that the user already has an account with. If the user doesn’t have an account already, they will need to create a new one, just as if OAuth weren’t there. Since this can be a complicated process, OAuth only gets used in practice with services that billions of people have already signed up for, like Google or Facebook.

The apps we’re working with have the reverse problem. If your app connects to multiple different mobility services, you don’t want to ask the services who the user is, since you probably know that already. Instead, you want to tell them who the user is! But how can we do that?

Luckily, a new standard called OpenID Connect, built on many of the same technologies as OAuth, was released to the public in August 2017. OpenID Connect describes a format for encoding identity information called a “JWT”, which stands for JSON Web Token, and a standard mechanism for validating that a trusted app issued the JWT. As long as they trust the issuer, a service can use a JWT from any OpenID Connect compatible application to authenticate the user who’s sending it. Better yet, apps that use frameworks like Firebase or Auth0 support OpenID Connect out of the box already!

This solves exactly the problem we have: an app that already has a relationship with a user wants to connect with multiple services, each of which may or may not have such a relationship.

Here’s how this flow works:

While the user still has control over their account with the service, since they always have the ability to deny or revoke an app’s permission, their interaction is much more seamless. There are no more passwords to remember, and they don’t have to enter the same information again if the app they’re using already has it. This means that the user can get where they’re going much more quickly. Once the auth flow has finished, the app can use the services APIs to access services right away; for instance, the user could unlock a shared bike directly through the app.

Where Coord Comes In

Even though OpenID Connect makes dealing with user identity much easier than it used to be, it can be challenging to support as part of an existing system. At Coord, our Users API handles sending only the necessary user information to each service while automatically tracking which users have access to which services. Because all Coord APIs, regardless of the underlying service provider, handle authentication uniformly, you can add a new service to your app with hardly any new code. Linking an existing user to a new application takes just a single HTTP GET request, and requires no new credential management for your app.

Also, Coord’s platform serves as a compatibility layer for service providers and for applications, allowing any provider or app to become standards-compliant without making any technical changes to their underlying system.

Finally, and most importantly, OpenID Connect doesn’t solve the problem of building trust between app developers and service providers. Going through Coord’s platform makes sure that only trusted services get access to user identity, and that only trusted applications are granted access to a service provider’s API, all without any change to the core app or service.

We’re excited to work with you to make Coord’s identity platform work with your application or service! Chat with us on coord.co to get started.

The article is published on medium.com by Jacob Baskin, Engineering Lead, Coord, and is republished with the author’s permission.