How to Provide the Best Authentication Experience for Your Customer Apps

When you have a customer experience (CX) team involved in the development of your web and mobile apps, you're often expected to provide a very specific experience that's consistent with your brand. Even if you don’t have a dedicated CX team, your ability to provide a consistent and seamless customer experience is critical to your business.

But obstacles stand in the way of delivering the authentication experience that's often expected, even required, in today's mobile-first world. Even modern identity protocols like OAuth present limitations. For example, OAuth often requires directing customers away from your application to authenticate and then back again. This is particularly noticeable with mobile apps, where the user experience can be impaired by variable network conditions and disparate styling between the app and the identity provider.

There isn’t always a clear-cut solution to this dilemma. Often it comes down to striking the right balance between cost and CX to meet your organizational requirements. For example, if cost is your primary driver, using out-of-the-box UIs may be good enough. They could realistically deliver 70-80% of the desired experience for 20% of the investment. This may suffice for your needs.

For many organizations, though, CX has become a competitive differentiator. When your customers’ experience is paramount, nothing less than 100% of the expected digital experience will do.

OAuth has become an invaluable tool in the identity toolbelt. If you’re using it as a way to share user data between two companies, it fulfills this role very well. For example, OAuth makes it possible for a user to let Slack access their Google services such that:

1. They don’t have to provide their Google credentials to Slack.
2. They have control over what Slack is allowed to see and do on their behalf.
   
   

As you can see, OAuth was designed to be an authorization protocol. It doesn’t address authentication and assumes it has already occurred. This has two key implications relating to authentication experience:

1. OAuth provides no actual means of authenticating a user.
2. OAuth relies on bouncing users between identity providers and applications that consume identity.
   
   

Relying on OAuth to provide your authentication experience therefore results in the following compromises:

1. Authentication experience is controlled by the identity provider rather than application developers, often creating organizational overhead.
2. The redirect experience isn’t particularly smooth or seamless.
3. Because application and login experiences are managed independently, the styling can feel disjointed.
   
   

While these compromises may seem minor to some, when you’re working on customer-facing apps, CX is critical. You need a better solution than “good enough” to deliver the frictionless and consistent experiences customers expect. 

Enter the Authentication API in PingFederate.

With the Authentication API, your application team can deliver superior customer experiences. By embedding authentication directly into applications and allowing you to drive the CX directly from your apps, the Authentication API lets you avoid awkward redirects and deliver smoother experiences, even on shaky mobile Internet connections. You can also retain tight control over your apps’ look and feel, while maintaining compatibility with OAuth and OIDC standards.

So let’s talk about how the Authentication API is structured. You can think of your Authentication API calls as occurring across three phases:

I like to think of it as an authentication sandwich with OAuth sourdough. You start with a standard OAuth initiation, go through the steps required to authenticate and then (once authenticated) finish by picking up where you left off in the OAuth flow.

It’s worth noting that the example endpoints shown above are all that’s required for a simple authentication scenario. In practice, though, your application will need to handle various states, such as requiring MFA, locked accounts, forgotten passwords and so on.

It’s also important to note that the Authentication API handles customer data, including passwords and OTPs and is therefore suitable for use only within your organization. It is not safe for third parties to use your Authentication API.

The PingFederate Authentication API supports two deployment modes. Which one you use depends on your use case, but they are not mutually exclusive. It’s plausible to use the first mode (the redirectless flow) for mobile apps, while also using the second mode to build a central authentication portal that allows single sign-on (SSO) for web clients.

Application Embedded (aka Redirectless)

This mode of deployment is useful when you want to manage the login experience within your mobile app without redirecting users to an external IdP. It’s perfect for controlling the login experience of a single application. Further, because the API uses very small payloads it performs noticeably better when mobile users have a poor signal.

If, however, you have advanced workflow requirements or you’re looking to create a centralized service (e.g., because you need SSO rather than just authentication for a single app), you may wish to consider the next deployment mode.

Authentication Portal

PingFederate provides incredible levels of extensibility. Velocity templates allow for pretty much any degree of look-and-feel customization using HTML, CSS and Javascript. The availability of configuration options like data stores, local identity profiles, password credential validators and authentication policies allow for a highly adaptable authentication flow.

However, there are situations where an alternative approach is preferable. Examples include:

• You want an identity abstraction layer to prevent vendor lock in.
• Extensive business requirements and system integrations mean it makes more sense to manage the login experience as a separate entity.
• Your company has a mature DevOps practice with battle-tested tools, processes and technologies, so it makes sense to leverage these rather than building out a new technology domain.
  
  

A custom authentication portal might be the answer to these scenarios. In this mode of deployment, applications are still configured as clients in PingFederate, but rather than authenticating using out-of-the-box templates, users are directed to the authentication portal. The authentication portal presents the desired look, feel and workflow, while authenticating users to PingFederate via the Authentication API.

Because this is done using the authentication sandwich I talked about above, all flows are OAuth/OIDC compatible and benefit from PingFederate capabilities such as SSO and multi-factor authentication (MFA).

Now that you understand the Authentication API, your next step is to start delivering exceptional authentication experiences. Learn how to get up and running with the Authentication API in PingFederate by reading the how-to guide.