Native Apps: OAuth 2 + Native FIDO2: Best practices?

[Lukas Westermann]

Hi all,

With the availability of native FIDO2 / passkey APIs on both Apple and (soon) Google, I was wondering if there are already best practices out there on how to best interop with OAuth 2. Now, I did a cursory search through this mailing list, Stackoverflow and the web, but most threads or discussions are 2+ years old.

Today, the recommendation for native apps is to use OAuth 2 (or OpenID Connect) Authorization Code flow with PKCE[0]. On both iOS and Android there are APIs like ASWebAuthenticationSession (iOS), Chrome Custom Tabs (Android) - usually leveraged via the AppAuth libraries or IAM vendor-provided SDKs. The flow in a very simplified manner is along the following:

1. User installs the app - and opens the app the first time.
2. The user clicks on login - then an "overlay" system browser is opened, i.e. starting the Authorization Code flow, opening the browser to something like: "https://login.example.com/authorize?..."
3. The user then uses the browser for the initial sign-in, performs a social login or uses the overlay browser to sign-up a new account etc.
4. On success the overlay browser is closed - and an access token and (optionally) a refresh token is returned, for the native app to use.
5. The app stores the refresh token in a secure manner (i.e. iOS Keychain or similar), so that when the user opens the app a second time the refresh token can be used to get another access token, without the browser-overlay-part (or the user actually noticing).

If we add now into this mix passkeys and the native FIDO 2 APIs, the question revolves around the following:

1. How to best handle the initial FIDO registration?
   I think this is solvable (or already solved), as here the overlay web browser is a perfectly okay and one can use the web browser to register the passkey that is later usable in the app natively too: so initial login or registration works.
2. For future authentications: Like when opening the app again - how to combine the Native FIDO2 APIs and OAuth 2 token refreshing. In this scenario: I think nobody wants the overlay browser.

Are there any best practices already established, especially for the second part question? The only thing that comes to my mind is to attach the FIDO attestation to when trying to get an OAuth 2 refresh token - or a new token endpoint that requires FIDO attestation.

Looking forward to learn from your experiences, approaches and ideas.

Sincerely, Lukas

[Ki-Eun Shin]

For the second use cases, you can get access token with the refresh token without a user interaction like the conventional flow.

Do you want to authorize or authenticate again when the user visits again?

If you are a RP side, there are two ways to leverage this.

First approach is that register and use passkey credentials for your own site and app regardless of OAuth2 provider.

1. Providing your own authentication mechanism (passkeys) with OAuth2. E.g, after OAuth authorization (or onboarding process), you provide the way for users to register passkeys on your site (your domain, RP id, and your app).

   -> Meaning is that generated credential is only bound to your site and app. (not to a OAuth2 provider)

2. Then, if the user visits your app or site again, if they need to re-authenticate, then trigger passkey authentication in your site or app (You don't need to redirect to the Idp.) This is not related to Oauth2 refersh or access token.

Just leverage authentication mechanisms provided by OAuth2 provider, if they provide passkey authentication, then you can leverage as it was. 

1. If OAuth2 provider offers passkeys somehow, user might register the passkey in somewhere.

2. When, the explicit authorization or authentication is needed on OAuth2 provider, as you mentioned, perform PKCE flow. Then, the OAuth2 provider triggers passkey authentication if they provide.

[Arshad Noor]

Hi Lukas,

Your question reminded me of a conundrum I have little understood. In light of what FIDO brings to the authentication space, I am going to try to challenge you (and others) to question your premise around "single sign-on" (SSO) technology. The goal is not to put anyone on the defensive about any specific SSO technology, but to debate whether SSO is even necessary in light of what FIDO offers.

You have to step back into the late '80s and early '90s to understand why SSO was really needed. Enterprises had a mish-mash of technology solutions: mainframes running SNA LU6.2, mini-computers with DECNet and other proprietary protocols, Netware LANs, a smattering of UNIX systems running TCP/IP, and OS/2 with LAN Manager, etc. Everybody was using usernames and passwords. And, everybody had different schemes, algorithms, and protocols for dealing with them. The complexity of managing this was daunting enough that companies were investing serious money to solve this problem.

As networks were starting to coalesce around TCP/IP and public-key cryptography made a splash, for a while in the late '90s, it seemed that the password problem could be eclipsed by that original passwordless authentication protocol - SSL ClientAuth - with X.509 v3 digital certificates. But, that bubble broke with the dot-com crash; and passwords that were restricted primarily to enterprise networks at the dawn of the internet, exploded to affect every consumer that needed to authenticate to a restricted website. Leading us to where we are today: a mish-mash of SSO protocols and schemes.

FIDO is, essentially, a reboot. An advanced authentication technology that:

• Does NOT depend on "shared secret authentication";
• Is designed to protect the privacy of consumers;
• Can optionally leverage simple to sophisticated "user verification" schemes;
• Eliminates password phishing attacks;
• Is supported on every modern client computing device (many with secure elements);
  
• Is supported on every modern browser; and
• Most importantly, is simple enough that it can strongly authenticate users with the touch of a button.

If a FIDO server can authoritatively return an authentication token in a few seconds to any web/mobile application, why burden the application with a legacy SSO protocol that adds yet another "band-aid" to what was already a band-aid from the previous century? Why not cut the crap in the middle and just get an authoritative answer from the source?

SSO tokens - whether they are SAML, JWT, etc. - must be verified thoroughly because they represent a "man in the middle" of the authentication flow; why introduce or maintain a man in the middle when the protocol was designd for privacy. Why add the legal burden of determining who is responsible for privacy violations when the MITM is breached?

Ah! The answer is "legacy applications". SSO was written into applications in an age when passwords ruled the world and companies needed to alleviate the burden of users who were forced to authenticate to dozens of systems within the enterprise. The cost of SSO was less than the loss of productivity and consumer frustration with password management that SSO is accepted as a defacto standard. But, when passwords have been eliminated and strong authentication has been simplified, does it make sense to continue carrying that cost of SSO? The technical compexity? And, the legal burden in a world that is increasingly regulating privacy? (Note that similar questions arise when considering the issue raised with passkeys held by platform vendors).

It may be useful to step back and ponder whether it may actually benefit the internet to eliminate the SSO burden - and its associated risks - when an application can get an authoritative answer from a FIDO server directly with the simple touch of a button, faster than we can verify the authenticity and integrity of an SSO token.

Arshad Noor
StrongKey

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/6daf5cfa-95ba-4f35-a964-3a000b130df9n%40fidoalliance.org.