Introduction
FME Form provides secure support for accessing a wide variety of web-hosted resources through its use of FME web connections. Many FME web connections follow the OAuth 2.0 protocol, often requiring user authentication to establish a safeguarded, encrypted channel between client (eg. FME Form) and the target resource server.
Authentication in FME Form has typically involved the use of its shipped, embedded browser to fully test and authenticate web services and connections. While FME Form's embedded browser has served its purpose well, the decision was made to shift away from embedded browser use, and instead leverage the user's system default browser for authentication purposes. This shift to external browser authentication has two key benefits:
- it allows FME users to employ the supported browser of their choosing for authentication purposes in FME Form; and
- it improves FME Form's alignment with modern data and system security best practices.
This article will introduce the new external browser authentication experience in FME Form, available as an option for our OAuth 2.0 Authorization Code compliant web services and connections, and SAML-based FME Flow connections.
Please note, instructions for configuring individual web services and connections will not be included in this article. The main purpose of this article is twofold:
- to provide a general overview of what users and authors can expect to see in FME Form 2025.2+ with the new external browser authentication experience, and
- to highlight some key points about migrating older web services and connections to capture this new functionality in FME Form 2025.2+.
Requirements
- FME Form 2025.2+
- Where connecting to FME Flow from FME Form 2025.2+ via SAML is concerned, users will require at minimum FME Flow 2025.2, configured for SAML, to capture the external browser authentication functionality. It is required that the <year.major> version of FME Flow and FME Form match to ensure product compatibility.
- A system default browser must be specified. The following OS-Browser combinations have been tested internally by Safe Software:
- Windows OS: Google Chrome, Microsoft Edge, or Mozilla Firefox
- macOS: Google Chrome, Microsoft Edge, or Apple Safari
- Linux: Google Chrome, Mozilla Firefox
New Redirect Strategy Parameter on OAuth 2.0 Web Services in FME Form 2025.2+
Support for the new external browser authentication functionality is being offered by way of a new web service definition parameter. Web services which can offer support for the new external browser authentication experience in FME Form 2025.2+ will include this new parameter, located just below the web service's familiar Redirect URI parameter.
This new parameter is called the Redirect Strategy parameter, and includes three drop-down choice options:
-
Proxy Redirect (Safe Software): authentication will make use of a Safe Software-hosted redirect web page. Under this strategy, users will perform the login to their web service provider via external web browser, and the service provider will redirect its response to the Safe-hosted redirect page. Then, the hosted redirect page will relay the response to FME Form, allowing the authentication process to complete. This strategy is particularly useful when http://localhost is not supported or unavailable for handling redirects.
- selecting this strategy will set the Redirect URI value of the FME web service definition to: https://fmeauth.safe.com/v1/oauth2
-
Loopback Interface Redirect: authentication will follow the Loopback Interface Redirect strategy, fully documented in Section 7.3 of RFC 8252 OAuth 2.0 for Native Apps. Generally, the loopback redirect strategy uses http://localhost (a special address that points back to your own machine) to let FME receive a response from the web browser after you log in to a target service. Most modern web service providers or APIs designed with desktop/native apps in mind offer support for http://localhost as a redirect URI; in fact, http://localhost is often the only permissible non-HTTPS redirect URI for client/app registration.
- selecting this strategy will set the Redirect URI value of the FME web service definition to: http://localhost
-
Embedded Browser (Deprecated): authentication will occur via FME Form's embedded browser. This strategy has been the only redirect strategy made available in FME Form prior to FME Form 2025.2. Users who have tested web services or authenticated web connections in FME Form 2025.1 or below will be familiar with the in-product pop-up browser window that appears for user authentication.
- the Redirect URI parameter will accept any value when this strategy is chosen. Users are cautioned against choosing this strategy, as the embedded browser redirect strategy will be fully removed from FME Form in a near future release.
Deprecation and Full Removal of the Embedded Browser Redirect Strategy in FME Form
As of the official public release of FME Form 2025.2, the embedded browser which ships with FME Form will be considered deprecated. This deprecated status means that the embedded browser will no longer receive active development efforts, with the full removal of the embedded browser to follow. Currently, the full removal of the embedded browser from FME Form is planned for the release of FME Form 2026.2.
To bring attention to the embedded browser's deprecated status, users will see the following non-dismissable banner appear within the embedded brower, while testing web services and authenticating web connections which make use of the Embedded Browser (Deprecated) Redirect Strategy:
Users who upgrade to FME Form 2025.2+ are strongly encouraged to begin migrating their older web service definitions over to a Redirect Strategy which makes use of the external browser authentication functionality, following the guidance below. Additionally, it is recommended that users do not choose the Embedded Browser (Deprecated) Redirect Strategy for any new web services created in FME Form 2025.2+.
Both of these recommendations will ensure that users' web services continue to function as expected once the embedded browser has been fully removed from FME Form. Full embedded browser removal is currently planned for the release of FME Form 2026.2.
Migrating Older OAuth 2.0 Web Services and Connections
By default, OAuth 2.0 web services that were built in FME Form 2025.1 or below, and opened in FME Form 2025.2+, will have the new Redirect Strategy set to Embedded Browser (Deprecated). This ensures these older web services will function in FME Form 2025.2+ as they did in FME Form 2025.1 or below, by continuing to use FME Form's embedded browser for user authentication.
It is important to note, however, that web services which continue to make use of the Embedded Browser (Deprecated) redirect strategy will not function as expected once the embedded browser is removed from FME Form, where full embedded browser removal is currently planned for the release of FME Form 2026.2. This is why users are strongly encouraged to promptly begin migrating their older OAuth 2.0 web services away from the Embedded Browser (Deprecated) redirect strategy in FME Form 2025.2+.
To migrate these older web services to the new external browser authentication functionality of FME Form 2025.2+, the Redirect Strategy parameter on these web services should be adjusted to a value of either Loopback Interface Redirect or Proxy Redirect. When this adjustment is made, users will notice that the web service's Redirect URI parameter value will change on its own.
A web service definition originally created in FME Workbench 2024.1, opened in FME Workbench 2025.2. The left-side image shows the default Redirect Strategy value applied, while the right-side image shows the Redirect Strategy adjusted to Loopback Interface, and the accompanying Redirect URI value adjustment.
This is intentional behavior, to ensure the Redirect URI specified on the web service definition meets the requirements of the chosen Redirect Strategy. For example, choosing Loopback Interface Redirect as the value for Redirect Strategy will also adjust the Redirect URI to http://localhost. As localhost is the standard expected redirect URI for the loopback redirect strategy, FME Form will smartly populate the Redirect URI parameter on the web service definition accordingly, to meet this need.
After adjusting the Redirect Strategy on the web service definition to one of the external browser authentication options, users must ensure that the client registration (a.k.a app registration) in use by the web service includes the newly populated redirect URI value. Otherwise, testing the web service will result in an error on mismatched redirect URIs. During FME web service migration, it is recommended that users copy the value which populates for the FME web service's Redirect URI parameter, and then paste this value into the client registration's list of approved redirect URIs. This copy-paste will ensure a match between the redirect URI on the client registration, and the redirect URI on the FME web service, thereby avoiding any redirect URI mismatch errors at web service testing.
Once the adjusted OAuth 2.0 web service tests successfully with the external browser authentication flow, web connections which already make use of the adjusted web service will not need to be reauthenticated; these web connections will continue to work as expected. If a web connection which makes use of a migrated web service is reauthenticated, user authentication will occur using the external browser authentication functionality.
Building a new web connection from a migrated OAuth 2.0 web service is simple. In FME Workbench 2025.2+, users can navigate to Utilities > FME Options > Web Connections, and select the plus (+) button below the Connections table to add a new web connection. In the dialog that opens, choose the newly migrated web service, give the connection a meaningful name, choose the desired connection visibility, and then select OK at bottom right. Users will then be directed to follow the external browser authentication prompts, and finally return to FME Workbench once authentication is complete.
OAuth 2.0 Web Service Migration Examples
The following two examples highlight the differences users will see in FME Form 2025.2, while working with an already built web service that does support external browser authentication vs. an already built web service that does not support external browser authentication. Users should follow the guidance offered in Example 1 to migrate their own OAuth 2.0 web services over to external browser authentication, where supported.
While these two examples focus on web services associated with the SharePointOnlineConnector only, it's important to bear in mind that any FME OAuth 2.0 web service and connection can be migrated to capture this new external browser authentication functionality, following the guidance provided in Example 1.
The examples below highlight web services that ship with the SharePoint Online FME Package. FME Packages are add-on components, and so are not included with an install of a core FME Platform product. Users interested in viewing the web services mentioned in the following two examples must ensure that the SharePoint Online FME Package has been installed to their FME Form 2025.2+ core product. Please see our Introduction to FME Packages article for instructions on downloading and installing FME Packages.
Example 1. Microsoft SharePoint Online (safe.microsoft-sharepoint) Web Service Migration
This example will demonstrate the new external browser authentication functionality as it applies to the Microsoft SharePoint Online (safe.microsoft-sharepoint) web service.
As this web service ships with the SharePoint Online FME Package, users will require an install of the is package for FME Form 2025.2+ to apply external browser authentication to this web service.
Users who have already built a web service definition from the Microsoft SharePoint Online (safe.microsoft-sharepoint) web service will see something similar to the following image upon accessing the web service in Manage Web Services dialog of FME Workbench 2025.2+:
This OAuth 2.0 web service definition includes the Redirect Strategy parameter, and so will support the new external browser authentication functionality offered in FME Form 2025.2+. To migrate this web service over to utilizing the new external browser authentication functionality, the Redirect Strategy parameter must be adjusted to a value of either Proxy Redirect (Safe Software) or Loopback Interface Redirect.
After selecting either Proxy Redirect or Loopback Interface Redirect as the Redirect Strategy, the Redirect URI parameter's value will automatically adjust to a value that supports the chosen redirect strategy. This newly populated Redirect URI value must be applied to the client registration in use by the web service.
In the case of this SharePoint Online web service, the Azure app registration linked to the Client ID value of the web service must have http://localhost (for the Loopback Interface Redirect strategy) or https://fmeauth.safe.com/v1/oauth2 (for Proxy Redirect strategy) added to its list of permissible redirect URIs.
After changing the Redirect Strategy value to take advantage of the external browser authentication functionality, it is strongly recommended that users copy the Redirect URI value that auto-populates in the FME web service, and directly paste this value into the appropriate location of the associated client registration. Doing so will ensure that the Redirect URI value of the FME web service exactly matches a permissible redirect URI listed on the client registration, which will, in turn, help avoid encountering authentication errors in FME related to mismatched redirect URI values.
Once the Redirect Strategy value has been changed to either Proxy Redirect or Loopback Interface Redirect, and the auto-populated Redirect URI value on the FME web service has been added to the permissible redirect URIs on the client registration, users can select Apply on the web service definition to save the changes, and then select Test to see the external browser authentication experience in action.
Example 2. Microsoft Graph (App Only) Web Service - External Browser Authentication Not Supported
This example uses the second web service that ships with the SharePoint Online FME Package, to demonstrate an FME web service which does not support the new external browser authentication functionality. The purpose of this example is to clearly demonstrate how to determine whether a target FME web service should support this new functionality in FME Form 2025.2+.
The following image shows the fully configured default definition of the Microsoft Graph (App Only) web service, which ships with v1.2.1+ of the SharePoint Online FME Package.
It's important to take note of a few key web service parameters that are not present on this Microsoft Graph (App Only) web service, as compared to the parameters present on the Microsoft SharePoint Online (safe.microsoft-sharepoint) web service highlighted in Example 1, above. It's these missing parameters which indicate that the Microsoft Graph (App Only) web service does not, and should not be expected to support external browser authentication in FME Form 2025.2+.
These key missing web service parameters include:
- the Redirect Strategy parameter;
- the Redirect URI parameter;
- the Authorization Parameters URL
These three parameters are all involved in user authentication. If these three parameters are not present on a given web service definition in FME, then user authentication is not necessary for the web service to function as expected. If user authentication is not required, then neither the embedded browser nor the external browser will be required to fully test the web service and build the follow-on web connection.
Generally, web services and connections that did not require the embedded browser for successful use in FME Form 2025.1 or below, will not support the new external browser authentication functionality in FME Form 2025.2+.
FME Flow SAML Connections in FME Form 2025.2+
FME Form web connections to FME Flow which follow the SAML protocol for user authentication will, by default, make use of external browser authentication in FME 2025.2+. This means that users who choose to connect to FME Flow via SAML, from FME Form, will now authenticate their FME Flow connection using their system default browser, and not the embedded browser which ships with FME Form 2026.1 and below.
If users wish to use FME Form's embedded browser for SAML authentication of FME Flow web connections, the FME Flow Connection prompt in FME Form 2025.2 - FME Form 2026.1 will include a Use Embedded Browser (Deprecated) option that can be enabled.
It is highly recommended, though, that users create their FME Flow SAML connections in FME Form 2025.2+ using the default external browser authentication functionality, and not the embedded browser, as the embedded browser will be fully removed from FME Form beginning with the release of FME Form 2026.2.
External vs Embedded Browser - Successful Authentication Messages
Users will receive different confirmation messaging when testing web services that employ an external browser redirect strategy vs embedded browser redirect strategy for authentication. When the Redirect Strategy parameter is set to Embedded Browser (deprecated), users will still see the familiar Test Successful pop-up dialog appear after a successful test of the web service has been completed.
When the Redirect Strategy parameter is set to one of the two external browser options (Loopback Interface or Proxy), users will see a slightly different pop-up dialog appear upon successful web service test completion.
This is expected behavior. Since FME Form's embedded browser has been deprecated, its related log messaging and pop-up notifications in FME Form 2025.2+ have not been changed from those present in previous FME Form releases. The new external browser authentication process has its own log messaging and pop-up dialogs, which differ from those associated with the embedded browser. Once the embedded browser is fully removed from FME Form, users will only see the external browser authentication log messages and pop-up dialogs while testing FME web services and authenticating FME web connections that support this functionality.
Timeout Warning Messaging with External Browser Authentication in FME Form 2025.2+
FME Form 2025.2+ web services and connections which make use of the new external browser authentication functionality, will have an initial 30-second time period applied to the authentication flow. In other words, users will initially be given 30 seconds to complete the authentication flow following the external browser prompts. If authentication is not completed within this initial 30-second window, then users will see the FME OAuth 2.0 Authorization pop-up dialog in FME Form display the following timeout warning message:
The timeout warning message will look the same for SAML-based FME Flow connections in FME Form, where external browser authentication is not completed within the initial 30-second time period:
This timeout warning message is meant to redirect the user's attention to their web browser, to complete the authentication prompts therein. It is not meant to warn about an upcoming timed out request; the authentication flow will not time out on its own. If the user does not follow through with completing authentication via the external browser prompts, then this FME OAuth 2.0 Authorization dialog will persist in FME Workbench until manually cancelled by the user.
Concluding Remarks
The shift to external browser authentication as of FME Form 2025.2 will allow users to make use of their preferred browser for web service authentication, while aligning FME Form with more modern security best practices. It is important to bear in mind, however, that only OAuth 2.0 web services and FME Flow SAML connections are affected by this shift. Users can readily recognize those web services which will support external browser authentication in FME Form 2025.2+, as these web service definitions will have the new Redirect Strategy parameter included, just below the familiar Redirect URI parameter.
Users who upgrade to FME Form 2025.2+ are strongly encouraged to begin migrating their already built FME web services over to making use of external browser authentication where applicable, and to ensure newly built web services which include the Redirect Strategy parameter do not make use of the Embedded Browser (Deprecated) option for the Redirect Strategy parameter's value. Following these two recommendations will ensure that web services continue to function as expected once FME Form's embedded browser is fully removed from FME Form. Full embedded browser removal is currently targeted for the release of FME Form 2026.2.
If you encounter any technical issues migrating your web services over to make use of the external browser authentication functionality in FME Form 2025.2+, or while creating new web services in FME Form 2025.2+ with a Redirect Strategy that supports external browser authentication, please submit a Safe Support request. Be sure to indicate your FME Form version and build number in support requests, as well as a detailed description of the technical issue encountered with screenshots and translation logs where possible.
Related Resources
Working with FME and Web Data, Services and Protocols