Add an option to bypass extauth for OPTIONS calls to the callback

[djannot]

Is your feature request related to a problem? Please describe. When an Ajax call is sent with an expired token, Gloo Edge is redirecting it to the IdP. If the IdP considers that the session is still valid, a callback call will be sent, but CORS is involved, so an OPTIONS call to the callback URL is sent first. And Gloo Edge responds to this callback call with a 302.

Describe the solution you'd like Add an option to bypass extauth for OPTIONS calls to the callback

[github-actions[bot]]

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.

[lmaillet]

Hi, I probably have the same issue.

Here is the situation.

A user is connected and have a gloo-session cookie that last 20 minutes.

After more than 20 minutes of usage of our app, the user tries to call an API https://app.....talend.com/api/iam-server/users/... (gloo-session maxAge is exceeded).

Then the call is redirected (302) to https://iam.....talend.com/oidc/idp/authorize?client_id=aa...&redirect_uri=https%3A%2F%2Fapp.....cloud.talend.com%2Fcallback&response_type=code&scope=openid+refreshToken&state=...

It's not the same domain, so the redirection starts with an OPTIONS request. -> OPTIONS: request contains all CORS headers :white_check_mark: -> GET: with credentials: 'include' in the fetch options, so cookies are sent (mostly session that is used by OIDC) :white_check_mark:

Then the call is redirected again (302) to https://app.....talend.com/callback?code=...&state=... It's not the same domain, so the redirection starts again with an OPTIONS request. -> OPTIONS: CORS issues due to missing CORS headers :x:

The /callback answers with a set-cookie: gloo-session... and a location: https://app.....talend.com/api/iam-server/users/... So it's the expected response but it's too early. It should first answer to the OPTIONS request with the expected access-control-allow-* headers and send the new session in the following GET.

So the issue is quite similar to the one above. And I can't figure out how to make the /callback manage correclty an OPTIONS request.

[edubonifs]

an har file were I reproduced the issue the config of the /callback endpoint the config of the authConfig a few logs from the extauth

Files: https://drive.google.com/file/d/1cSNhpDC6N-SyVUKipHS49q3iHuLTRzxZ/view?usp=share_link

[lmaillet]

Knowing the config of the /callback route

- matchers:
    - prefix: /callback
  name: oauth.callback
  options:
    extauth:
      configRef:
        name: auth-config
        namespace: app
    cors:
      allowCredentials: true
      allowHeaders:
        - content-type
      allowMethods:
        - GET
        - OPTIONS
      allowOriginRegex:
        - ...
      maxAge: 1d
  directResponseAction:
    status: 200

Shouldn't Support CORS on Direct Response fix the problem ? It should be part of the version 1.15 and we are using 1.15.9.

[edubonifs]

For info, calling an API directly from a new browser tab (and not from some js code) is working quite well. The session is refreshed and a new cookie is received.

Reproducing steps for this setup, no issues found: https://drive.google.com/file/d/19y4LmeSxSXyB65fREjM8RqdVIm_bE_jM/view?usp=sharing

[lmaillet]

Yes, agree with you. The issue comes from the OPTIONS request made by the browser before doing the expected GET request.