Skip to content

Decoupling Identity from Authentication

September 5, 2013

Many mobile and web apps connect to web services to provide content to the user. This usually means the app developer has control over the web service. Some apps rely on 3rd party services, using OAuth to negotiate the connection. OAuth is an excellent strategy for 3rd party authentication, but that’s not the scope of this discussion. We want to focus on the direct connection between an app and the web service where one developer controls both the client and the service. Let’s look at a case study of the current status quo.

Case Study: Email Address As Login

The typical workflow for new and returning users is to show a sign up/sign in view on initial app launch to allow the user to enter authentication details to login or information required to create an account. In most systems, the vendor (probably you if you’re reading this) wants to collect information like email address and phone number, so they can stay connected with their customer. While that can be incredibly valuable to the vendor, it may not be necessary for the user to derive value from the app. Generally, the user needs only to operate within a persistent session that uniquely and distinctly identifies their actions as belonging to one user. We refer to this as the personal silo.

Users are quite familiar with providing an email address as a required field when creating an account. This strategy presumes the user wants to reveal this information to the vendor. In some cases, users will refuse to create an account because they don’t wish to reveal their email address. In that case, everyone loses. In order to provide maximum value to the user, it is necessary to adjust the on-boarding process to require absolutely nothing from the user. Again, for web apps, this is difficult (maybe impossible). For mobile apps, we’ve developed a strategy that enables vendors to allow the user to use their app without requiring any data entry from the user at all. Here’s how we do it.

Automatic Token-Based Account Creation

On first launch, the app establishes a connection with the web service to create a User object. This object requires no fields and has only a token to uniquely identify the user. At this point, the user is most likely still looking at a splash screen. Since most vendors take this opportunity to show some branding materials and force the user to wait a few seconds, we might as well go off and create the account while they wait. Once the account is created, we store the token on the device. This is the primary means of maintaining user session. This token is used for all subsequent API activity, as the app coordinates efforts with the web service.

Just-In-Time Access Prompting

Many apps ask for a bunch of access right up front, resulting in an unknown number of prompts stacked up when the user launches the app the first time. Often, developers incorrectly assume the user will allow access whenever the system prompts them. This is a slippery slope to a bad user experience. As a rule, your app should function regardless of user-authorized access. If the user declines the location services access prompt, the app should still allow them to navigate a map to find value. If they accept location services, the map should center on their location, but still allow them to navigate. The key here is that the app only prompts when the user has taken some action to achieve some task that may benefit from the services for which access is requested. For example, instead of prompting for push notification access on first launch, wait to prompt until the user has requested a messaging-related feature. That way, they maintain a perceptual context of their action, making it more obvious that they are being prompted for their convenience, as a mechanism for easing them through their current task.

Prefer In-App Messaging Over Email

Vendors like to keep in touch with their customers. This enables a richer, more interactive experience for the customer. Maintaining a conversation with users makes it much easier to guarantee consistent engagement. However, this need not happen via email. In some cases, such as newsletters and other infrequent scenarios, email may be the best choice. In those cases, prompt for access to user contact info only after the user taps the “Subscribe to Newsletter” button. Again, this improves the perception of value in the eyes of the user. It’s clear they are being asked to allow access to their personal information, so they don’t have to type anything. If the goal is to provide real-time information related to the app or the user’s app data, that should be done via push notification. In-app messaging solutions do not require any personal information to be shared by the user. All the major app platforms use anonymous tokens to coordinate messaging between server and device.

Emerging Best Practice

The goal of this strategy is to provide more ease and grace to the on-boarding process. By reducing barriers to entry and leveraging OS features for accessing device capabilities to eliminate the data entry tasks of setting up an app, we dramatically increase the quality of the user experience. This allows the user to dive head first into the value being delivered by the app. Use convenience features to reduce the cognitive load on your users, and don’t require them to do anything before they can use your app. Get them to the content as quickly as you can. They will thank you for it, hopefully with their wallets.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 123 other followers

%d bloggers like this: