Standard OAuth2 extauth support (non-oidc)

[ky-rafaels]

Version

1.12.x

Is your feature request related to a problem? Please describe.

Customer has a legacy non-oidc OAuth2 server they would like to have supported via Gloo Edge extauth. It's a high priority for them to replace the code in client apps that is performing the auth exchange with their OAuth2 server and offload this responsibility to Edge extauth.

Describe the solution you'd like

• Support OAuth2 workflow with ability to add custom scope and state value in authconfig to meet Fitch's requirements (cannot use openid scope value) ~~- Verify the JWT token presented in cookie by UA using symmetric key (HS256) method~~ ~~- Retrieve the symmetric key associated with the client - k8s secret?~~

Describe alternatives you've considered

Attempted to use an oidc authconfig and spoofing the /.well-known/openid-configuration and /jwks endpoints using directResponseAction. We also then attempted to make http transformations to perform the auth exchange.

Here is a slab doc with further details on workarounds attempted: https://soloio.slab.com/posts/oauth-2-non-oidc-issue-44jvdrdv

Additional Context

Here is an outline of the calls that are being made from a working client authenticating to OAuth2 without extauth: https://soloio.slab.com/posts/o-auth-flow-diagram-and-calls-v17fbw2b

Refresh Token Grant: There is an expiration timestamp in the token. If access token is expired, the application will be responsible for making a call to /oauth/token endpoint with grant_type=refresh_token along with the client_id and client_secret of the app and receive back a new access_token and refresh_token. From his assessment it appears we need to do nothing for the refresh grant process

The refresh grant process seems to be what is documented here: https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/

Customer has a deadline of about mid September to begin testing a solution

[ky-rafaels]

In this request, customer has confirmed that they have no need to validate the token signature after the access token and refresh token is returned. They would like to continue with their current implementation of doing a soft verification handled by the client app.

[ky-rafaels]

Attempting to deploy via helm from gloo-ee-test-helm repo, helm release: 1.13.0-beta1.dev.13.

Here is where we left off in testing:

• New images for this test beta release are not publicly available which is causing imagepullbackoffs for several Edge components (extauth etc). These images need to be made publicly available to continue testing
• A code change needed to be made to look for access_token (instead of fc_auth) being returned from OAuth server.

[inFocus7]

Released in Gloo EE 1.13.0-beta4.

[nfuden]

This needs to go into 1.12 branch

[inFocus7]

Released in Gloo EE ~1.12.25~ 1.12.26 (last friday).