Ports needed for OAuth integration in restricted network

[Blaine Ott]

We have successfully implemented OAuth integration into a couple of our FileMaker servers with our custom IdP.  We're now hoping to implement it on server in a heavily restricted network.  We have allowed traffic in and out on 443 between the FileMaker server IP to our IdP IP, but we can't get a successful verification of our custom IdP.  When clicking the Verify Your Identity Provider, we are sent to our IdP to authenticate and then after a successful login and releasing the information, the browser spins for 120 seconds, then the browser URL switches to a local FileMaker server address and sits for another 30 seconds before reporting failure saying the access token or ID token cannot be retrieved.  It feels like some necessary traffic communication is being blocked and eventually timing out.  We can visit the Authorization Code Endpoint address directly (that includes the Client ID and Client Secret along with the servers oauth/redirect address) and get a code.  Using that code, we can use a curl command to the Authorization Token Endpoint address and get JWTs for both an ID and an Access tokens, all within a couple of seconds.  Is the FileMaker server looking for traffic on an additional port to complete the transaction or translate the JWT from the IdP?  The IIS logs suggests FMS is getting the code from our IdP, but hitting an error 25022 trying to verify the response:

2022-10-31 04:04:03 10.136.150.14 GET /fmi/admin/internal/v1/extauth/getoauthurl provider=General&trackingID=3b6c5364-b919-4c29-ac0c-1c7fb0256e7d&address=tts-fm-pdb2.trinity.duke.edu&X-FMS-OAuth-AuthType=4&returnURL=https://tts-fm-pdb2.trinity.duke.edu/fmi/admin/api/extauth/oauth-verify&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=a1d6fc12-a5a2-404e-bbf7-46a242a64cf6&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/admin-console/app/administration/externalauthentication 200 0 0 3048

2022-10-31 04:04:03 10.136.150.14 GET /fmi/admin/internal/v1/extauth/getoauthurl provider=General&trackingID=3776f529-da96-4a1a-9a8e-6492a3fcee62&address=tts-fm-pdb2.trinity.duke.edu&X-FMS-OAuth-AuthType=4&returnURL=https://tts-fm-pdb2.trinity.duke.edu/fmi/admin/api/extauth/oauth-verify&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=aa7b851b-4fef-4b1a-bc63-71094bce9a78&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/admin-console/app/administration/externalauthentication 200 0 0 2600

2022-10-31 04:06:34 10.136.150.14 GET /oauth/redirect code=enA7mZ&state=WC1GTVMtUmVxdWVzdC1JRD1GNkU1MEJFNTMwODVCRUM2QjI4MDFCMUJCNTAyRkQ0NA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9RHVrZU9BdXRo.WC1GTVMtT0F1dGgtQXV0aFR5cGU9NA%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vdHRzLWZtLXBkYjIudHJpbml0eS5kdWtlLmVkdS9vYXV0aC9yZWRpcmVjdA%3D%3D.&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=bf36b5e5-d157-4d64-9c9f-fbafc7056152&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://oauth.oit.duke.edu/ 200 0 0 122281

2022-10-31 04:06:34 10.136.150.14 GET /fmi/admin/api/extauth/oauth-verify trackingID=3b6c5364-b919-4c29-ac0c-1c7fb0256e7d&identifier=-1&error=25022&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=ab6302f0-8a37-4f60-879a-283809e7da5b&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/oauth/redirect?code=enA7mZ&state=WC1GTVMtUmVxdWVzdC1JRD1GNkU1MEJFNTMwODVCRUM2QjI4MDFCMUJCNTAyRkQ0NA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9RHVrZU9BdXRo.WC1GTVMtT0F1dGgtQXV0aFR5cGU9NA%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vdHRzLWZtLXBkYjIudHJpbml0eS5kdWtlLmVkdS9vYXV0aC9yZWRpcmVjdA%3D%3D. 200 0 0 10

[Wim Decorte]

since you can get the JWT from cURL, have you inspected the JWT to make sure it contains what it should?  Perhaps this isn't a ports issue at all.

Also, using the browser's dev tools should tell you what network calls are being made and potentially blocked.

If you are using the OIDC flow then there is no further communication after receiving the JWT.  If you are using the full OAuth2 flow then there is one more call to to IdP's user profile endpoint.

[Blaine Ott]

Wim, the JWT that is returned from the direct curl using the code from the verify log is exactly what we get from our public servers.  I do have to export that JWT to another machine because I can't get to https://jwt.io from the server.  Also, like our public servers, we're using OIDC flow.  I'm not that familiar with the dev tools, but watching the network tab shows pretty much what is shown in the IIS log.  Nearly immediately, there is a call to  the https://tts-fm-pdb2.trinity.duke.edu/oauth/redirect?code=XXXXXX&state=<long_string>.    On our public servers, that call to the same, server appropriate link, is very quickly verified, where the private server takes about two minutes before failing to verify.

[Wim Decorte]

I would suspect some networking issue, perhaps DNS resolution or routing going haywire.