Title
Implement System Browser Authentication (RFC 8252) for Universal Passkey Support across All Platforms
Platform
N/A
Is it related to an issue?
There have been a number of prior bugs and FRs broadly related to this topic, and this issue has also been discussed in unrelated tickets. However it appears that there's still confusion over the underlying issue, root cause, and scope, and so I wanted to lay this out in full, so there's one place for discussion.
Currently, Termix utilizes an embedded WebView for authentication flows. While this works for web logins, it is not compatible with modern authentication methods - specifically WebAuthn (Passkeys) used by identity providers such as Pocket ID, Authentik, Authelia etc.
Because standard WebViews are sandboxed and lack the necessary hooks to communicate with the hardware security module (biometrics/FIDO2 keys), users are unable to log in using modern security standards.
The Standard
As detailed in the RFC 8252: OAuth 2.0 for Native Apps, the use of embedded user-agents (WebViews) is explicitly discouraged (Best Current Practice). The RFC establishes the use of the system browser to perform the authorization flow.
From Abstract:
OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.
From Section 4: Overview:
For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user-agent (typically the browser) rather than an embedded user-agent (such as one implemented with web-views).
Previously, it was common for native apps to use embedded user-agents (commonly implemented with web-views) for OAuth authorization requests. That approach has many drawbacks, including the host app being able to copy user credentials and cookies as well as the user needing to authenticate from scratch in each app.
Aside from the security benefits, the RFC notes other clear benefits in moving to a compliant flow:
From Section 4:
Native app authorization requests that use the browser are more secure and can take advantage of the user's authentication state. Being able to use the existing authentication session in the browser enables single sign-on, as users don't need to authenticate to the authorization server each time they use a new app.
Crucially, RFC 8252 is platform-independent; the requirement to move away from embedded WebViews applies equally to Android and to iOS.
Current Stance
This issue has been discussed previously, many times. The author's current stated position is as follows:
Pocket ID relies on a technology called WebAuthn, which is a library for performing authentication. However, this library does not support being rendered inside a web view inside an application, which is what happens inside the desktop/mobile app.
AFAIK, there’s really no way around this, so for the time being, Pocket ID just is not supported until they can provide a fix.
Based on this, my assumption is that they are waiting for one of two things to happen:
1. Pocket-ID "fixes" this.
This points to confusion over the root cause - as stated the current flow is not standards compliant, and there is no way that Pocket-ID will implement a workaround that makes their solution less secure.
Furthermore, WebAuthn is a web standard and browser API, not a standalone library. Expecting an identity provider to "fix" a browser-level security API's inability to run in a restricted WebView doesn't make sense.
2. WebAuthn fixes this
WebViews will likely never support WebAuthn because doing so would undermine the security model. As noted:
Embedded browsers, such as those found in certain applications or devices, have inherent limitations when it comes to capturing and saving essential information required for the authentication process to function smoothly. These limitations can impact the authentication flow and result in unexpected behavior or errors.
And:
Webauthn requires a web browser, as embedded browsers do not support webauthn.
As such, there is no fix coming from the library or identity providers - the only proper fix is a change to Termix itself, to adopt a compliant flow.
A Final Note
As a tool providing SSH access to remote infrastructure, Termix is inherently a high-sensitivity application. As such, for professionals and homelabbers alike, the strength of the authentication stack and its compliance with the relevant standards is a key consideration.
As passkeys and FIDO2 increasingly become the baseline expectation for secure remote access, maintaining an architecture that limits these methods may become a hurdle for wider adoption. Implementing RFC 8252 compliance would align Termix with the current security standards, and allow the full range of hardware backed security.
The Solution
The only way to properly resolve this is a change to Termix itself, to adopt a compliant flow across all supported platforms. While the recent implementation for iOS (Termix-SSH/Mobile#16) is a big step forward, the limitation remains for Android, Windows and macOS.
On Apple platforms, the fix is to utilize ASWebAuthenticationSession. On Windows and Android, the equivalent 'System Browser' contexts (Custom Tabs on Android) should be used. This ensures that hardware-backed security is accessible regardless of the device.
In summary, implementing the same "Authorization Session" logic currently being merged for iOS across Android, Windows and macOS would resolve the issue in full and across all platforms.
Additional Context
No response
Title
Implement System Browser Authentication (RFC 8252) for Universal Passkey Support across All Platforms
Platform
N/A
Is it related to an issue?
There have been a number of prior bugs and FRs broadly related to this topic, and this issue has also been discussed in unrelated tickets. However it appears that there's still confusion over the underlying issue, root cause, and scope, and so I wanted to lay this out in full, so there's one place for discussion.
Currently, Termix utilizes an embedded WebView for authentication flows. While this works for web logins, it is not compatible with modern authentication methods - specifically WebAuthn (Passkeys) used by identity providers such as Pocket ID, Authentik, Authelia etc.
Because standard WebViews are sandboxed and lack the necessary hooks to communicate with the hardware security module (biometrics/FIDO2 keys), users are unable to log in using modern security standards.
The Standard
As detailed in the RFC 8252: OAuth 2.0 for Native Apps, the use of embedded user-agents (WebViews) is explicitly discouraged (Best Current Practice). The RFC establishes the use of the system browser to perform the authorization flow.
From Abstract:
From Section 4: Overview:
Aside from the security benefits, the RFC notes other clear benefits in moving to a compliant flow:
From Section 4:
Crucially, RFC 8252 is platform-independent; the requirement to move away from embedded WebViews applies equally to Android and to iOS.
Current Stance
This issue has been discussed previously, many times. The author's current stated position is as follows:
Based on this, my assumption is that they are waiting for one of two things to happen:
1. Pocket-ID "fixes" this.
This points to confusion over the root cause - as stated the current flow is not standards compliant, and there is no way that Pocket-ID will implement a workaround that makes their solution less secure.
Furthermore, WebAuthn is a web standard and browser API, not a standalone library. Expecting an identity provider to "fix" a browser-level security API's inability to run in a restricted WebView doesn't make sense.
2. WebAuthn fixes this
WebViews will likely never support WebAuthn because doing so would undermine the security model. As noted:
And:
As such, there is no fix coming from the library or identity providers - the only proper fix is a change to Termix itself, to adopt a compliant flow.
A Final Note
As a tool providing SSH access to remote infrastructure, Termix is inherently a high-sensitivity application. As such, for professionals and homelabbers alike, the strength of the authentication stack and its compliance with the relevant standards is a key consideration.
As passkeys and FIDO2 increasingly become the baseline expectation for secure remote access, maintaining an architecture that limits these methods may become a hurdle for wider adoption. Implementing RFC 8252 compliance would align Termix with the current security standards, and allow the full range of hardware backed security.
The Solution
The only way to properly resolve this is a change to Termix itself, to adopt a compliant flow across all supported platforms. While the recent implementation for iOS (Termix-SSH/Mobile#16) is a big step forward, the limitation remains for Android, Windows and macOS.
On Apple platforms, the fix is to utilize
ASWebAuthenticationSession. On Windows and Android, the equivalent 'System Browser' contexts (Custom Tabs on Android) should be used. This ensures that hardware-backed security is accessible regardless of the device.In summary, implementing the same "Authorization Session" logic currently being merged for iOS across Android, Windows and macOS would resolve the issue in full and across all platforms.
Additional Context
No response