OIDC redirect and path restoration

[navkast]

Background

I'm using OIDC authorization code flow. I'm struggling to come up with a good solution. I'm on Quarkus 3.18.3.

• In a real environment, the frontend is being served by Cloudfront CDN, in mywebsite.url. The backend is in api.mywebsite.url. This means the frontend is making CORS requests to api.mywebsite.url
• In localhost, the backend quarkus server is in localhost:8080 and the frontend is in localhost:5173 (react vite).

Problem

The problem is the OIDC layer isn't working properly. I'm using OIDC powered by AWS cognito, and the cookies aren't being set properly in the way I'd expect them to be.

Here's what I'm trying, based on the available documentation:

Scenario	Config	Outcome in localhost
Set the redirect-path to a virtual endpoint (i.e., something with no real Java file pointing to it)	quarkus.oidc.authentication.redirect-path = /auth/callback quarkus.oidc.authentication.restore-path-after-redirect = false	404 on /auth/callback. No cookie or token state in browser.
Set the redirect-path to a real endpoint (i.e., create /auth/callback), making it redirect to home page	quarkus.oidc.authentication.redirect-path = /auth/callback quarkus.oidc.authentication.restore-path-after-redirect = false	Back to home, but no authentication has happened: no cookie or token state in browser.
Set the redirect-path to a virtual endpoint, but restore path after redirect	quarkus.oidc.authentication.redirect-path = /auth/callback quarkus.oidc.authentication.restore-path-after-redirect = true	404 on /auth/callback. No cookies

Ideally, I want Quarkus to do the OIDC token exchange flow for authorization code on a virtual endpoint, and then redirect the page (and set cookies), to the home page. Anyonw know what the best solution here is?

My application.properties:

# OIDC Configuration
quarkus.oidc.application-type=hybrid
quarkus.oidc.token.principal-claim=sub
quarkus.oidc.roles.source=accesstoken
quarkus.oidc.auth-server-url=https://cognito-idp.${aws.region}.amazonaws.com/${USER_POOL_ID}
quarkus.oidc.authentication.cookie-same-site=none
quarkus.oidc.authentication.cookie-force-secure=true
quarkus.oidc.authentication.cookie-domain=.${mywebsite.url}
quarkus.oidc.authentication.java-script-auto-redirect=false
quarkus.oidc.logout.path=/auth/logout
quarkus.oidc.logout.backchannel.path=/auth/logout
quarkus.oidc.logout.frontchannel.path=/auth/logout
quarkus.oidc.authentication.redirect-path=/auth/callback
quarkus.oidc.authentication.restore-path-after-redirect=true
quarkus.oidc.authentication.scopes=openid profile email
quarkus.oidc.client-id=${APP_CLIENT_ID}
quarkus.oidc.credentials.secret=${OIDC_CLIENT_SECRET}

# Crucial for avoiding infinite redirect loops, or else the OIDC redirect will be blocked by the security filter
quarkus.http.auth.proactive=false
# Public paths
quarkus.http.auth.permission.public.paths=/q/*,/openapi/*,/swagger-ui/*,/public/*,/auth/callback*,/favico.ico
quarkus.http.auth.permission.public.policy=permit
# Authenticated paths
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

# CORS Configuration
quarkus.http.cors=true
quarkus.http.cors.origins=http://${mywebsite.url}
quarkus.http.cors.methods=GET,POST,PUT,DELETE,OPTIONS,PATCH
quarkus.http.cors.exposed-headers=Content-Disposition,Location,Set-Cookie
quarkus.http.cors.access-control-allow-credentials=true

Some experimentation:

Localhost

In localhost, I am able to edit these lines:

quarkus.oidc.authentication.cookie-same-site=none
quarkus.oidc.authentication.cookie-force-secure=true
quarkus.oidc.authentication.cookie-domain=.${mywebsite.url}

# CORS Configuration
quarkus.http.cors=true
quarkus.http.cors.origins=https://${mywebsite.url}

to:

quarkus.oidc.authentication.cookie-same-site=lax
# quarkus.oidc.authentication.cookie-force-secure=true
# quarkus.oidc.authentication.cookie-domain=.${mywebsite.url}

# CORS Configuration
quarkus.http.cors=true
%dev.quarkus.http.cors.origins=http://${mywebsite.url}

AND add a route:

  @GET
  @Path("/auth/callback")
  public Response redirectToMainPage(
      @jakarta.ws.rs.core.Context jakarta.ws.rs.core.HttpHeaders headers)
      throws URISyntaxException {
    Response.ResponseBuilder responseBuilder;
    if (myWebsiteUrl.contains("localhost")) {
      responseBuilder = Response.status(302).location(new java.net.URI("http://" + myWebsiteUrl));
    } else {
      responseBuilder = Response.status(302).location(new java.net.URI("https://" +
 myWebsiteUrl));
    }

This works, but only in localhost, where mywebsite.url is localhost:5173. Why is creating an endpoint necessary? I thought a virtual endpoint would work.

Real environment

In a real environment, the frontend is being served by Cloudfront CDN, in mywebsite.url. The backend is in api.mywebsite.url. This means the frontend is making CORS requests to api.mywebsite.url. This is why I set the cookie domain to quarkus.oidc.authentication.cookie-domain=.${mywebsite.url}. However, that doesn't work - the state cookie doesn't register and I go on an infinte redirect. This seems to be a different problem.

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@navkast, Hello,

Ideally, I want Quarkus to do the OIDC token exchange flow for authorization code on a virtual endpoint, and then redirect the page (and set cookies), to the home page. Anyonw know what the best solution here is?

Quarkus OIDC does not, on its own, do redirects between different application endpoints (hosted on different domains or localhost ports), its job is to secure a single endpoint only.

The restore request path property supports this flow: a call goes to /a, or b, and many other /n URLs but the registered callback in the OIDC provider has only /callback - this is indeed a virtual address - given possibly an open ended number of the actual request paths, it would've been impossible to register all of the matching callbacks in the OIDC provider. Now, no matter what the actual request path is, the user is always redirected back to /callback once the authentication is completed and now, Quarkus OIDC is finalizing the authorization code flow and once the session cookie is ready, it restores the original request path by redirecting an already authenticated user to /a, or /b etc - all of it is happening within the boundaries of a single endpoint, for ex, the frontend.

Your custom route may help to support redirecting between different endpoints but since the OIDC code flow completes in one domain, mywebsite.url, and you need to redirect the user to another domain, api.mywebsite.url, the cookies are not propagated from the original domain during the redirect...

I'm not 100% sure how to handle it. Perhaps the cookie domain property can be widened to cover both domains ?
Or may be, when your custom route does the final redirect to another domain, this redirect can be intercepted in the SPA, and the script, would, given the permissions, get the current state cookie and propagate it to the final destination.

If that does not help, then please create a reproducer for the local host case, and I can look into it further.

Once it all works, we can look at what Quarkus OIDC can help with further, but right now more analysis in needed.

[sberyozkin]

You may also want to have a look at https://github.com/quarkiverse/quarkus-oidc-proxy, though I'm not sure it can fit your use case.
With the OIDC proxy, SPA logs into Quarkus managed proxy which redirects the user to the actual OIDC provider. After the authentication, the user can be brought back to the OIDC Proxy callback route and at that point it, the user is redirected to the configured external redirect URI, though the use case was about getting the user back to the SPA callback URL...