We have the following setup for Gitlab in Azure. Giltab is installed and running on a VMSS in Azure. We have configured Azure AD app proxy with an external URL which the users enter on their browsers and an internal url which is pointing to the Gitlab running on the VMSS. Any inbound requests to gitlab go through the proxy.
We have enabled OIDC on Gitlab by following OpenID Connect OmniAuth provider | GitLab to use the Microsoft IDP.
Following behavior was observed:
- User hits the external App proxy URL on their browser
- App proxy does the OIDC dance, authenticates the user with Azure AD which returns an Access token to App proxy.
- App proxy then redirects the token to Giltab, which starts its own OIDC dance.
- Gitlab does not honor the access token it got from the App proxy and starts its own OIDC flow, talks to Azure AD, does a token exchange, validates the token and then redirects the browser with a gitlab cookie which finally renders the page.
As you can see, there 2 OIDC flows in picture here
- App proxy OIDC flow which does a token exchanged with Azure AD
- Gitlab OIDC flow which does a token exchange with Azure AD
Gitlab will only honor an access token it requested, not one provided out of the blue. In the UI experience this results in a redirect to the idp, which having already authenticated, sends you back with a new access token that gitlab stores.
Question: Is it possible to setup Giltab in a way where it honors the token sent by App proxy in the first place? something similar to a OBO flow. This way we force Gitlab not to do the second OIDC dance and honor the token it gets from App proxy