[Bug] Unified Authentication generates malformed redirect URL and duplicates sl_portal_jwt

What happened?

SafeLine Unified Authentication generates a malformed redirect URL after successful OIDC authentication.

Environment:

• SafeLine: 9.4.0 Global / English
• Identity Provider: Authentik 2026.8.0
• Protocol: OIDC
• Unified Authentication: enabled
• Test backend: traefik/whoami

Anonymized domains:

Unified Authentication Portal: https://oauth.example.com
OIDC Provider:                  https://auth.example.com
Protected Application:         https://whoami.example.com

OIDC Redirect URI:

https://oauth.example.com/.safeline/auth/api/callback/oidc

OIDC authentication itself succeeds, but the final redirect generated by SafeLine contains two problems:

1. SafeLine uses & instead of ? when the original application URL has no query string.
2. sl_portal_jwt is appended twice.

For example, SafeLine redirects to a URL equivalent to:

https://whoami.example.com/&sl_check_uuid=<uuid>&sl_portal_jwt=<jwt1>&sl_site_id=<site_id>?sl_portal_jwt=<jwt2>

The same problem was also reproduced with another protected application, so it does not appear to be application-specific.

How we reproduce?

1. Configure SafeLine Unified Authentication with an OIDC identity provider.

2. Configure Authentik with the following Redirect URI:

https://oauth.example.com/.safeline/auth/api/callback/oidc

3. Protect a simple application such as traefik/whoami with SafeLine Unified Authentication.

4. Open the protected application without any query parameters:

https://whoami.example.com/

5. SafeLine correctly redirects to the Unified Authentication portal:

https://oauth.example.com/?sl_site_id=<site_id>&sl_check_uuid=<uuid>&redirect=https%3A%2F%2Fwhoami.example.com%2F

6. Complete authentication through Authentik.

7. Authentik successfully redirects back to:

https://oauth.example.com/.safeline/auth/api/callback/oidc

8. After authentication succeeds, SafeLine redirects the browser to a malformed URL:

https://whoami.example.com/&sl_check_uuid=<uuid>&sl_portal_jwt=<jwt1>&sl_site_id=<site_id>?sl_portal_jwt=<jwt2>

The first SafeLine parameter is incorrectly appended using:

&sl_check_uuid=

instead of:

?sl_check_uuid=

As a control test, opening:

https://whoami.example.com/?test=1

avoids the malformed path issue because a query string already exists.

However, sl_portal_jwt is still duplicated.

The resulting URL is equivalent to:

https://whoami.example.com/?sl_check_uuid=<uuid>&sl_portal_jwt=<jwt1>&sl_portal_jwt=<jwt2>&sl_site_id=<site_id>&test=1

So the problem is reproducible in both cases.

Expected behavior

For an original URL without query parameters:

https://whoami.example.com/

SafeLine should redirect to a valid URL such as:

https://whoami.example.com/?sl_check_uuid=<uuid>&sl_portal_jwt=<jwt>&sl_site_id=<site_id>

The first query parameter should use ?.

sl_portal_jwt should only appear once.

If the original URL already contains query parameters, SafeLine should merge its parameters correctly using & without duplicating any authentication parameters.

Error log

There is no backend error log because the OIDC authentication itself succeeds.

Relevant browser redirect sequence:

GET https://whoami.example.com/
→ SafeLine returns 467
→ https://oauth.example.com/?sl_site_id=<site_id>&sl_check_uuid=<uuid>&redirect=https%3A%2F%2Fwhoami.example.com%2F
→ https://auth.example.com/...
→ https://oauth.example.com/.safeline/auth/api/callback/oidc
→ https://whoami.example.com/&sl_check_uuid=<uuid>&sl_portal_jwt=<jwt1>&sl_site_id=<site_id>?sl_portal_jwt=<jwt2>

Control test:

https://whoami.example.com/?test=1

After authentication:

https://whoami.example.com/?sl_check_uuid=<uuid>&sl_portal_jwt=<jwt1>&sl_portal_jwt=<jwt2>&sl_site_id=<site_id>&test=1

This behavior was reproduced using traefik/whoami, which does not perform its own authentication redirects or URL rewriting.

Start by tracing the Unified Authentication OIDC callback and the code that builds the final protected-application redirect URL. Reproduce both the no-query and existing-query cases described in the issue, then add or update coverage for correct query separators and a single sl_portal_jwt parameter. Done means both redirect forms are valid and authentication parameters are not duplicated.