`gloo_urlToRedirect` not handled post auth in oauth2.oauth2 authconfig

[ky-rafaels]

Gloo Edge Product

Enterprise

Gloo Edge Version

1.13.51 - 1.15.x (tested versions)

Kubernetes Version

v1.21 - v1.25

Describe the bug

When using an authconfig of type oauth2.oauth2, the requested path url for a service is not respected post auth for the redirect. By default after auth, the redirect is to the root path for service, not requested path.

I have tested an app to where I request path http://httpbin-opa.kyle.consultsolo.net/get. Extauth properly redirects to keycloak auth page and gloo_urlToRedirect parameter is properly set as request path. State parameter is the encoded url root path http://httpbin-opa.kyle.consultsolo.net/

After auth, the browser redirects to the root service path instead of the requested path before auth. This seems to be due to decoded state parameter being used for redirect

Expected Behavior

Gloo edge should be redirecting post auth the initial request path for an authconfig of type oauth2.oauth2

- apiVersion: enterprise.gloo.solo.io/v1
  kind: AuthConfig
  metadata:
    creationTimestamp: "2023-09-07T17:22:19Z"
    generation: 5
    name: httpbin-oauth
    namespace: gloo-system
    resourceVersion: "78959345"
    uid: 6bc382d8-d89c-4f6f-8cb2-7bb9eada9385
  spec:
    configs:
    - oauth2:
        oauth2:
          appUrl: http://httpbin-opa.kyle.consultsolo.net/
          authEndpoint: http://keycloak-opa.kyle.consultsolo.net/realms/master/protocol/openid-connect/auth
          callbackPath: /callback
          clientId: httpbin
          clientSecretRef:
            name: client-secret
            namespace: gloo-system
          scopes:
          - openid
          - email
          session:
            cookie:
              allowRefreshing: true
          tokenEndpoint: http://keycloak-opa.kyle.consultsolo.net/realms/master/protocol/openid-connect/token

Steps to reproduce the bug

1. Expose a service via virtualservice through edge gateway
2. Create authconfig of type oauth2.oauth2
3. test via browser by requesting a path other than / to your service
4. you will be redirected to auth service however post auth be redirected to root of service and not requested path

Additional Environment Detail

No response

Additional Context

No response

[sam-heilbron]

Internal notes around this problem: https://docs.google.com/document/d/1u6BV6_gb4v_yenft-SECoaEE-6xbJQzUfUvFYjRZfQ0/edit#heading=h.r8hm9hqzk8yx

[isihu]

Running into the same issue with oauth2.oidcAuthorizationCode

Edit: Restarting ExtAuth and Redis Pods solved this issue

[inFocus7]

I will begin investigation/work on this by Monday (12/18/23).

[inFocus7]

This seems to be due to decoded state parameter being used for redirect

I think it's more specifically using the appUrl (although the encoded appUrl is currently being used as the state as well). Although may want to add more debug logs to confirm.

The two instances where we default to the defaultAppUrl if nothing (gloo_urlToRedirect, or AfterLoginPath) is set/found:

• https://github.com/solo-io/ext-auth-service/blob/421f04715d6c486cf3720d732fd4a33521ce5e6f/pkg/config/oauth2/callback.go#L73-L82
• https://github.com/solo-io/ext-auth-service/blob/421f04715d6c486cf3720d732fd4a33521ce5e6f/pkg/config/oauth2/callback.go#L41-L43

[inFocus7]

Progress

• I have a test image that should resolve this by using the state to store base64(originalUrl) for redirection (thanks to Sam for the initial work on this).
  • Ext-Auth PR: https://github.com/solo-io/ext-auth-service/pull/700
  • EE PR: https://github.com/solo-io/solo-projects/pull/5598
• From some investigation, I noticed some extra security stuff we could handle. This has been separated to another test release + PRs, in case this solution won't work for the user's use case.
  • Ext-Auth PR: https://github.com/solo-io/ext-auth-service/pull/704
  • EE PR: https://github.com/solo-io/solo-projects/pull/5607

I still need to work on reproducing locally because I haven't had time to after the second finding/bullet point above. We have the ball rolling for the user to test these images out.

Slack Context

[inFocus7]

Moving to Blocked while awaiting for feedback on test images I created.

[soloio-bot]

Zendesk ticket #3085 has been linked to this issue.

[sam-heilbron]

Added @jswinner09 as an assignee to track that he is taking the next steps on this issue to gather feedback on the test images per: https://github.com/solo-io/gloo/issues/8673#issuecomment-1875518192

[inFocus7]

I'm un-assigning myself while I work on other priorities. If this gets picked up by another engineer, here is the documentation I have with the current progress + follow-ups.

• Internal Document

[DuncanDoyle]

No longer an issue in 1.16.x. Closing

[nmnellis]

I am unsure this made it into any release. customer is currently giving conflicting answers

[DuncanDoyle]

As discussed, assigning to @inFocus7 to provide 1.16 dev build with this fix.

[sam-heilbron]

Slack thread outlining the results of a meeting: https://solo-io-corp.slack.com/archives/C03L190TQDA/p1708455831533669

[sheidkamp]

PR Review of ext-auth changes: https://github.com/solo-io/ext-auth-service/pull/717#pullrequestreview-1909568347 solo-projects changes to get tests passing: https://github.com/solo-io/solo-projects/pull/5868

Will review with @inFocus7 and appropriate others on Monday.

[sheidkamp]

In an Edge-team discussion this morning, we reviewed the current state of the ticket and plan on taking the following steps:

Review of PRs linked on Friday: https://github.com/solo-io/gloo/issues/8673#issuecomment-1973924662

These contain the client-validated Oauth2 updates, and they will be prepped for release.

Meanwhile, we will create a test release branch with the "extra security stuff" identified here: https://github.com/solo-io/gloo/issues/8673#issuecomment-1866494110. Target is to have this ready March 5.

We would prefer this version of the code as it will be more secure and inline with how we handle signing/verification of state in our OIDC flow

Finally, we will document the differences in our Oauth2 and OIDC implementations with the hope of eventually sunsetting the Oauth2 implementation. This work will not hold up any release.

Summary:

1. Reviews of current PRs. These are client-validated but less secure.
2. Test release with more secure state signing
3. Document differences between our Oauth2 and OIDC implementations.

[sheidkamp]

Next steps from: https://solo-io-corp.slack.com/archives/C03CE4PJ6HW/p1709683179769449?thread_ts=1709651074.622189&cid=C03CE4PJ6HW

• Introduce just the basic state already validated into 1.16
  • ETA: March 8
• Introduce those changes, plus some more to prevent CSRF attacks, in 1.17
  • ETA: +2 days - March 12
• Introduce some improved testing in 1.17
  • ETA: Timebox - March 15

The enhancement outlined in https://github.com/solo-io/ext-auth-service/issues/729 to mitigate against CSRF attacks is out of scope.

[sheidkamp]

Functionality validated in test release now available in solo-projects 1.16.x branch and will be part of the next 1.16 release.

[sheidkamp]

Update:

• Updated state signing in approval process, should merge 3/13.
• We are not moving forward with Keycloak e2e tests, more context here: https://github.com/solo-io/solo-projects/issues/5473#issuecomment-1992466090

[sheidkamp]

JWT signed state code in main/1.17 of solo-projects, no tasks outstanding