[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:

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

OIDC Redirect URI:

1https://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:

1https://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:

1https://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:

1https://whoami.example.com/

5. SafeLine correctly redirects to the Unified Authentication portal:

1https://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:

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

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

1https://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:

1&sl_check_uuid=

instead of:

1?sl_check_uuid=

As a control test, opening:

1https://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:

1https://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:

1https://whoami.example.com/

SafeLine should redirect to a valid URL such as:

1https://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:

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

Control test:

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

After authentication:

1https://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.

This issue is related to an older version. We recommend upgrading to the latest version and then checking whether the issue still persists.

Retested after upgrading to SafeLine 9.4.1 Global / English.

Both issues are still reproducible with the same traefik/whoami test backend.

Test 1: original URL without query parameters

Original URL:

1https://whoami.example.com/

After successful OIDC authentication, SafeLine redirects to a URL equivalent to:

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

So the first query parameter is still incorrectly appended using:

1&

instead of:

1?

and sl_portal_jwt is still added twice.

Test 2: original URL with an existing query parameter

Original URL:

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

After successful authentication, SafeLine redirects to:

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

In this case the URL structure is valid because the original URL already contained ?, but sl_portal_jwt is still duplicated.

So on 9.4.1:

• URL without an existing query string: malformed redirect still occurs.
• URL with an existing query string: redirect structure is valid.
• sl_portal_jwt: duplicated in both cases.

The behavior is unchanged from 9.4.0 in my environment.

Retested after upgrading to SafeLine 9.4.1 Global / English.

Both issues are still reproducible with the same traefik/whoami test backend.

Test 1: original URL without query parameters

Original URL:

https://whoami.example.com/

After successful OIDC authentication, 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>

So the first query parameter is still incorrectly appended using:

&

instead of:

?

and sl_portal_jwt is still added twice.

Test 2: original URL with an existing query parameter

Original URL:

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

After successful authentication, SafeLine redirects to:

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

In this case the URL structure is valid because the original URL already contained ?, but sl_portal_jwt is still duplicated.

So on 9.4.1:

• URL without an existing query string: malformed redirect still occurs.
• URL with an existing query string: redirect structure is valid.
• sl_portal_jwt: duplicated in both cases.

The behavior is unchanged from 9.4.0 in my environment.

Thank you for the additional information. We have successfully reproduced the issue and logged it in our internal tracking system. We’ll keep you updated as soon as there are any further developments.