logo-green.png
Explanation of OpenID as a federated identity system, its role in third-party authentication, and the security concerns addressed through TLS connections. Emphasis on the challenges faced by first-party mobile applications, the preference for backchannel authentication, and the limitations of browser redirection. Insights into the need for a backchannel OAuth Code Flow grant for multi-step authentication processes, highlighted by the IETF draft, OAuth 2.0 for First-Party Native Applications. Additional security measures discussed include proof of possession tokens, app attestation, and the use of FIDO authentication for enhanced end-user security

Enhancing Secure Mobile Authentication with OAuth, Dynamic Client Registration, and DPoP

đź”’ Discover the latest insights from Mike Schwartz on authentication protocols, including OAuth, Dynamic Client Registration, and DPoP, in this thought-provoking blog post.

OpenID is a federated identity system designed to support a third party that needs to verify a person’s identity within your domain. For example, an e-commerce website may wish to offer social login, leveraging the identity provider (“IDP”) of Google or Apple. However, third-party authentication raises significant security concerns; we cannot allow the third party to access the user’s password. This is why the home IDP displays the login page via a TLS connection, a process that the RP (Relying Party) cannot intercept.

For first-party websites, using a federated identity protocol is very convenient, even though it was primarily designed for third-party authentication. It’s natural for first-party websites to utilize browser redirection via TLS, enabling the IDP to perform authentication and centralize other domain-specific business logic. However, for first-party mobile applications, OpenID is a square peg in a round hole. The browser redirect experience is subpar, with confusing popups that bewilder end-users, and domains cannot customize these system messages. Most mobile developers prefer a backchannel authentication mechanism, allowing them to keep the entire login experience within the app. Yes, they can access the password, but since it’s a first-party application, security concerns are somewhat reduced.

If passwords were the sole solution for human authentication, the OAuth password grant would suffice. However, most modern authentication technologies involve a series of requests and responses, i.e. they are multi-step. What we truly need is something akin to a backchannel OAuth Code Flow grant, where an authentication workflow can occur, and upon completion, the client can reference it with a code while requesting a token. A new IETF draft, known as OAuth 2.0 for First-Party Native Applications, addresses this need.

There are a few other measures that can enhance security: (1) using “proof of possession tokens” to prevent unauthorized usage in case a token leaks; (2) employing app attestation to mitigate the risk of app tampering; and (3) utilizing FIDO authentication to leverage hardware biometrics for end-user authentication — currently the best alternative to traditional passwords available.