Rename the WebAuthenticationUI framework library to more closely represent its intended purpose, and avoid confusion with WebAuthn authentication.

Motivation

The WebAuthenticationUI framework library was named during the initial development of the Client SDK, when only Swift and Kotlin were planned, and it was specifically targeting native application environments. It was also named to indicate its use as a UI-facing library. However, the SDK's modularization into logical layers has been refined since then, and encompasses not only UI-facing environments, but integration into other more abstact application development frameworks.

Another motivation is the upcoming support for Passkeys / WebAuthn, which could result in developers confusing the WebAuthenticationUI library with WebAuthn.

Fundamentally, the names of these framework libraries should represent the technology or framework being used. Web-redirect sign-in ultimately will always be web-based, so naming the library after "WebAuthentication" is redundant.

As a result, a clearer name should be adopted to address these problems.

Design objectives

1. Select a new name that more clearly represents the developer's use-case.
2. Ensure the name can be consistently applied across all relevant environments.
3. Pave the way for Passkey/WebAuthn libraries.

Proposed solution

The name this proposal recommends is: BrowserAuthentication. There are several reasons this name is chosen:

• This more specifically indicates that a browser itself will be used to enable user sign-in.
• The UI suffix is dropped as it's redundant.
• The name is generic enough that it can apply to both Apple/Android environments, native desktop applications, and potentially even Javascript environments (particularly within hybrid environments like React Native and Electron).

Detailed design

The library targets / names should be changed from WebAuthenticationUI to BrowserAuthentication, with the WebAuthentication class also adopting the name BrowserAuthentication. Compilers should be able to disambiguate the namespace from the class name, but in languages where that isn't possible another name can be considered for the class.

Implications on adoption

• This change would necessitate a major Semver version change, since this would represent a breaking API update (e.g. library/namespace names do not often support deprecation attributes in most languages).
  • In languages that support deprecation markers or type aliases, the class name itself can include these to simplify developer migration.
• Documentation and sample app updates would be necessary, to ensure the changes can be easily adopted by developers.
• Package managers may need to be updated explicitly to communicate the deprecation of the old framework names to developers.

Alternatives considered

Alternative names were considered, but within discussions among the Okta SDK engineers, this seemed to be the clearest and most platform-agnostic name that best communicated the library's intended purpose.

We also considered not making any changes, and leaving the name as-is. But with our future roadmap plans for expanding support for the Client SDKs to more languages and platforms, this seems like the perfect time to rename this library: the scope is currently limited to two platforms (Swift and Kotlin), but over time this will become increasingly difficult to change.