Code flow for IdentityServer whose token endpoint is not reachable

[v1955908-rgb]

We are currently trying to connect our on-premise Duende-IdentityServer with Forgerock.
That means the customer should be able to log in to Forgerock using the DID.

The Implicit Flow is no longer recommended today. Also, receiving the ID token via FormPost in Forgerock is somewhat cumbersome. Is it possible to switch the solution to Code Flow instead?

So, in the ClientId definition, instead of
AllowedGrantTypes = GrantTypes.Implicit

specify
AllowedGrantTypes = GrantTypes.Code?

Then we still have the problem that Forgerock cannot reach the token endpoint of the on-premise IDP.
Is it possible, shortly before the on-premise IdentityServer returns the code and the state (in the redirect URI, where previously the ID token was included), to store the ID token, the code, and the state in the data center, and then Forgerock retrieves the ID token with the code, the state, and the serial number from the ARG, from this service?

That would then be a back-channel solution.

Would this solution from a security perspective be better, or significantly worse, because I am overlooking something? The new service would first validate the received ID token (just as the DP validates the ID token today). The ARG is validated by Forgerock before Forgerock starts the federation with the on-premise IDP.

[wcabus]

Would it be viable to open up access to the token endpoint for the IP range where the Forgerock service is hosted?

We cannot give recommendations regarding changing how the OAuth/OIDC flows work by breaking them up behind another service: IdentityServer implements the flow and exposes the various endpoints that are needed for these flows to work as intended.

If you wish to validate the workaround using another service as an intermediary for Forgerock, then we can connect you to one of our partners to help with this on a consultancy basis. Feel free to contact us for more details.