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.