I need help with Authentication with APISIX, OIDC, and External SPA

[BorisBeker]

How do I authenticate a person attempting to access (let's say with a GET request) a protected route in APISIX using the OIDC plugin? I'm trying to use the Authorization Code Flow.

Since there's no session cookie, the user is redirected to Auth0's Universal Login, they authenticate, and then they are redirected back to the APISIX URL. Instead of this, it should redirect to the frontend and continue with the access to the protected resource. If I manually paste the frontend URL into the browser, and I have the session cookie, the GET request is attempted and works perfectly.

Trying another configuration, I end up with an infinite redirect to the frontend.

This is the configuration I provide through the APISIX dashboard:

{
  "cache_prefix": "oidc_storage:",
  "use_pkce": true,
  "set_access_token_header": true,
  "session_contents": {
    "access_token": true
  },
  "access_token_in_authorization_header": false,
  "set_id_token_header": true,
  "discovery": "",
  "set_userinfo_header": true,
  "set_refresh_token_header": false,
  "ssl_verify": false,
  "redirect_after_logout_uri": "/callback",
  "client_secret": "",
  "renew_access_token_on_expiry": true,
  "introspection_endpoint_auth_method": "client_secret_basic",
  "token_endpoint_auth_method": "client_secret_basic",
  "bearer_only": false,
  "session": {
    "secret": "",
    "cookie": {
      "secure": true,
      "samesite": "None",
      "httponly": true
    }
  },
  "accept_none_alg": false,
  "accept_unsupported_alg": true,
  "access_token_expires_leeway": 0,
  "force_reauthorize": false,
  "use_nonce": false,
  "access_token_expires_in": 3600,
  "revoke_tokens_on_logout": false,
  "timeout": 3,
  "jwk_expires_in": 86400,
  "logout_path": "/logout",
  "jwt_verification_cache_ignore": false,
  "iat_slack": 120,
  "redirect_uri": "/api/v1/clients/callback",
  "post_logout_redirect_uri": "/callback",
  "introspection_interval": 0,
  "client_jwt_assertion_expires_in": 60,
  "unauth_action": "auth",
  "scope": "openid profile email offline_access",
  "client_id": "*********",
  "realm": "apisix"
}

[dosubot[bot]]

Hi @BorisBeker! I'm Dosu and I’m helping the apisix team.

To authenticate users with APISIX, OIDC, and an external SPA using Authorization Code Flow, you need to pay close attention to how the redirect_uri is configured and how session cookies are handled.

Redirect URI:
The redirect_uri in the APISIX OIDC plugin must be a dedicated callback path that does not conflict with your application's business routes or the protected route itself. If you set the redirect_uri to the same path as your protected resource or a valid entry point in your SPA, APISIX will return a 500 error and you may encounter infinite redirect loops. Instead, use a sub-path (like /api/v1/redirect) or a reserved path (like /.apisix/redirect) for the callback. This ensures APISIX can handle the OAuth callback and establish the session correctly [docs] [issue].

Session Cookie:
The session cookie must be present and properly configured (e.g., SameSite: None, Secure: true) for cross-site scenarios, especially when your SPA and APISIX are on different domains. If the session cookie is missing during the callback, APISIX will not find the session state and will keep redirecting to the login page [docs].

SPA Integration Patterns:

• If APISIX manages the OIDC flow and session (bearer_only: false), the SPA should initiate requests to protected routes, and APISIX will handle redirects and session cookies. After authentication, APISIX proxies the request to your backend, and the SPA continues as normal.
• If you want the SPA to handle authentication and token management, set bearer_only: true in the plugin. APISIX will only verify access tokens sent by the SPA, and you avoid redirects and session management in APISIX [discussion].

Troubleshooting Infinite Redirects:
Infinite redirects usually mean the redirect_uri is misconfigured or the session cookie is not being set/sent. Make sure:

• The redirect_uri is a unique callback path, not the same as your SPA entry point or protected route.
• The session cookie attributes are compatible with your SPA's domain and protocol.
• The SPA does not directly handle the OIDC callback unless you are using bearer_only: true.

Example Configuration:

"redirect_uri": "https://your-domain.com/api/v1/redirect",
"session": {
  "secret": "your-very-long-secret",
  "cookie": {
    "secure": true,
    "samesite": "None",
    "httponly": true
  }
},
"bearer_only": false,
"unauth_action": "auth"

Or, for SPA-managed authentication:

"bearer_only": true

For more details, see the official docs and related GitHub issues.

Let me know if you want a diagram of the recommended flow or have questions about session sharing or advanced scenarios!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[BorisBeker]

n my case, the callback URL is a route in APISIX, which does not collide with any other. What happens is that upon login, it does not return to the SPA, but instead redirects the browser to the protected route in APISIX, which results in an inconsistency. I don't need the user to be redirected to that route, but rather for the SPA to be able to access the protected resource.

Should the redirect URI be the frontend URL or the APISIX URL?

[dosubot[bot]]

The redirect URI should be an APISIX route (a dedicated callback path, like /api/v1/redirect or /.apisix/redirect), not your frontend SPA URL, when APISIX is managing the OIDC flow and session. This allows APISIX to handle the OAuth callback, establish the session, and then proxy the request to your backend. If you set the redirect URI to the SPA URL, APISIX won't see the callback, and you'll either get infinite redirects or authentication failures because the session state is missing or not established by APISIX [docs].

If you want the SPA to handle the OIDC callback and token processing directly (for example, using a library like oidc-client in the frontend), then you can set the redirect URI to the SPA URL and configure APISIX with bearer_only: true. In this mode, APISIX only verifies bearer tokens sent by the SPA and does not manage sessions or redirects [discussion].

For most APISIX-managed OIDC flows, keep the redirect URI as an APISIX callback route. After login, the user lands on the APISIX callback, the session cookie is set, and subsequent SPA requests to protected resources will work as expected if the session cookie is present [docs].

If you want the user to always land on the SPA after login, you’ll need to implement a custom flow: after APISIX handles the callback and sets the session, you can configure your backend or APISIX to redirect to the SPA root as a final step. But the OIDC callback itself must be handled by APISIX for the session to work.

Let me know if you want a diagram of the recommended flow or have questions about SPA-managed authentication!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[BorisBeker]

How can I perform that final redirection to the SPA from APISIX?
I tried using response rewrite with $status = 302$, redirecting to the SPA URL with /dashboard, but that ends up in infinite redirects.

[dosubot[bot]]

Redirecting to the SPA using response-rewrite with a 302 status causes infinite redirects because the SPA route is still protected by the OIDC plugin—when the browser lands there, APISIX sees no session and restarts the authentication flow, creating a loop. The openid-connect plugin expects the OAuth callback (redirect_uri) to be handled by APISIX itself, not by the SPA or a protected route, so it can establish the session and proxy the request upstream. Forcing a redirect before the session is set breaks this flow and triggers repeated authentication attempts (source, source, source).

The recommended pattern is: set the OIDC redirect_uri to a dedicated APISIX callback route (like /api/v1/redirect or /.apisix/redirect), let APISIX handle the callback and set the session, then proxy to your backend or SPA. If you want the user to always land on a specific SPA route after login, have your backend (or the SPA itself) perform a redirect after the session is established—not via response-rewrite on the callback route.

If you want the SPA to handle authentication and tokens directly, set bearer_only: true in the OIDC plugin and point the OIDC flow to the SPA URL. In this mode, APISIX only verifies bearer tokens and does not manage sessions or redirects (source).

Here's a diagram of the recommended APISIX-managed flow:

sequenceDiagram
    participant U as "User"
    participant SPA as "SPA (Frontend)"
    participant APX as "APISIX"
    participant OIDC as "OIDC Provider"
    participant BE as "Backend API"

    U->>SPA: Access protected resource
    SPA->>APX: GET /api/protected
    APX->>OIDC: Redirect to OIDC login (if no session)
    U->>OIDC: Authenticate
    OIDC->>APX: Redirect to /api/v1/redirect (callback)
    APX->>APX: Establish session, set cookie
    APX->>BE: Proxy request (with user headers)
    BE->>APX: Response
    APX->>SPA: Response (user is now authenticated)

Loading

If you absolutely need a final redirect to the SPA after login, consider having your backend respond with a redirect after the session is set, or let the SPA poll for session status and redirect itself. Avoid using response-rewrite for this purpose on the callback route, as it will almost always cause redirect loops if the SPA route is protected by OIDC.

Let me know if you want a config example for either flow or have more details about your SPA/backend setup!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}