Forum Discussion

Kevin_Davies's avatar
Kevin_Davies
Icon for Nacreous rankNacreous
Feb 22, 2026

API Pre-Authentication

Some time ago I was dealing with legacy web applications being retrofitted with modern authentication. As you can imagine this opens up a world of pain when the developers of said applications have long since left. In this particular case we had an application migrating to a new API which was secured behind a non-f5 reverse proxy. The difficulty was API authentication.

First the user would SSO to access the application but this was only for web application access. The API used by the application was hosted in a secure environment behind the proxy and there is no support by the standards for any authentication flows under the hood. I refer to fetch() and XHTMLRequest() calls by the application.

Key: Redirect = >

Issue Flow
User requests web application >
   Federated auth >
Web application loads in user browser context and starts making API calls which fail.

I did not have LTM handy to whip up some awesome solution to resolve this which would have been ideal case so had to figure out how to solve this another way. 

The Non-F5 Solution
All authentication requests have to occur at the user level so the only way in this scenario, was to redirect them. They were redirected to a dedicated endpoint on the proxy which automatically triggered an auth redirect for federated authentication. This would see the user has already logged in and issue the relevant proxy credentials (as a cookie) to the client who would then return to the proxy with these credentials. The only issue with this flow is everything about the original redirect from the client is lost during the authentication process. The only thing that remains is the original URL the user requested. 

Prototype Solution
User requests web application > 
   Federated auth >
Web application Loads - API Access? No > 
   Proxy >
        Federated auth >
   Proxy > ?

Javascript handling
Developers add javascript calls to API endpoint and if the return code is XXX redirects the user to proxy with parameter ?return=current url

Final Solution
User requests web application > 
   Federated auth >
Web application loads - API Access? No > 
   Proxy with return URL > (No Authentication)
       Federated auth > (Adds Proxy Authentication Cookie into Users Browser)
   Proxy with return URL > (Redirect user to return URL)
Web application loads -  API Access (Using Proxy Authentication Cookie) ? Yes, proceed as normal.

Since that time there may have been new standards that make this challenge simpler to navigate. Are you aware of any? Moreover which of the various F5 offerings would have been able to assist us with this issue?

4 Replies

  • APM would provide solution on this, especially in cases where application itself cannot handle modern auth by itself.

    But as I understand the case. If you have used oauth for both user and api calls it should be easier.

    So user goes to web app -> redirect to idp ->  authenticates -> gets access token, id token etc -> login to web app -> web app use access token to access apis

    And this should work with any vendor solution.

    • Kevin_Davies's avatar
      Kevin_Davies
      Icon for Nacreous rankNacreous

      Not both. The first form of auth to web application front door was SAML. The second form of auth to the proxy was a JWT. The third form which I didnt discuss was an OAuth/OIDC mechanisim between the Proxy and the IDP used to get the JWT for the Proxy. As the IDP was the source of the original SAML authentication the proxy simply needed to go back to the same IDP and the user would be recognised as being logged in.

      • Injeyan_Kostas's avatar
        Injeyan_Kostas
        Icon for Nacreous rankNacreous

        Oauth saml bearer assertion flow might also been used in this case. So saml assertion could be exchanged for an access token.