gitea-mirror-1 | Using BETTER_AUTH_URL: https://gitmirror.redacted.com
gitea-mirror-1 | Trusted origins (static): [ "http://localhost:4321", "http://localhost:8080", "https://gitmirror.redacted.com",
gitea-mirror-1 | "https://auth.redacted.com"
gitea-mirror-1 | ]
gitea-mirror-1 | [Deprecation] The "oidc-provider" plugin is deprecated and will be removed in the next major version. Migrate to @better-auth/oauth-provider. See: https://www.better-auth.com/docs/plugins/oauth-provider
Originally created by @DunklerPhoenix on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/306
Originally assigned to: @arunavo4 on GitHub.
Heho
You wrote in your doc https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/SSO_TESTING.md that the env `DEBUG=better-auth:* bun run dev` will enable debug mode for sso.
I tried it, but neither in docker logs nor in browser console are more informations.
The problem I have is that a click on sso just bring me back to the login screen again and I don't understand why.
How can I debug this?
SSO Provider: Authentik
Browser log:
```
card.hkr9-JM4.js:1
GET https://gitmirror.redacted.com/api/sso/applications 401 (Unauthorized)
card.hkr9-JM4.js:1 [HTTP Client] Authentication failed for /api/sso/applications
card.hkr9-JM4.js:1 [HTTP Client] Response: {"success":false,"error":"Unauthorized - Please log in"}
```
console log at start
```
gitea-mirror-1 | Using BETTER_AUTH_URL: https://gitmirror.redacted.com
gitea-mirror-1 | Trusted origins (static): [ "http://localhost:4321", "http://localhost:8080", "https://gitmirror.redacted.com",
gitea-mirror-1 | "https://auth.redacted.com"
gitea-mirror-1 | ]
gitea-mirror-1 | [Deprecation] The "oidc-provider" plugin is deprecated and will be removed in the next major version. Migrate to @better-auth/oauth-provider. See: https://www.better-auth.com/docs/plugins/oauth-provider
```
@DunklerPhoenix looks like there is an email linking issue. I will also take the chance to migrate the soon to be deprecated oidc plugin.
<!-- gh-comment-id:4569601641 -->
@arunavo4 commented on GitHub (May 29, 2026):
@DunklerPhoenix looks like there is an email linking issue. I will also take the chance to migrate the soon to be deprecated oidc plugin.
<!-- gh-comment-id:4587523584 -->
@DunklerPhoenix commented on GitHub (May 31, 2026):
Heho
The only thing that changed is a new step inbetween.
So:
1. I click on SSO
2. get redirected to authentik
3. Accept the login in authentik
4. come back to GM
5. see new this url: https://giteamirror.domain.com/?error=UNKNOWN
6. get redirected to /login
EDIT2 (sry):
```
gitea-mirror-1 | Using BETTER_AUTH_URL: https://giteamirror.domain.com
gitea-mirror-1 | Trusted origins (static): [ "http://localhost:4321", "http://localhost:8080", "https://giteamirror.domain.com",
gitea-mirror-1 | "https://auth.domain.com"
gitea-mirror-1 | ]
gitea-mirror-1 | 2026-05-31T17:43:38.039Z WARN [Better Auth]: Please ensure '/.well-known/oauth-authorization-server/api/auth' exists. Upon completion, clear with silenceWarnings.oauthAuthServerConfig.
```
EDIT:
image: ghcr.io/raylabshq/gitea-mirror:pr-307
Heya — fixed in #307, now merged and released as v3.17.0 (ghcr.io/raylabshq/gitea-mirror:v3.17.0).
Root cause was a chain: the account-linker was refusing to attach your Authentik identity to your existing local admin because (a) your local account isn't email-verified (we don't run a verification flow), and (b) Better Auth's adapter was silently stripping the trust field before the check could see it. The ?error=UNKNOWN you saw was the production error page sanitizing the real account not linked message.
Heads-up when you upgrade: in your SSO provider settings, make sure the Domain field matches the email domain of your Authentik users (e.g. yourcompany.com). Auto-linking is now scoped to that domain — it's how we avoid blanket-trusting every IdP for every email. Docs: SSO-OIDC-SETUP.md → Account Linking.
Thanks for the detailed repro — the ?error=UNKNOWN URL + the BETTER_AUTH log warning is what let us trace it.
<!-- gh-comment-id:4599276113 -->
@arunavo4 commented on GitHub (Jun 2, 2026):
Heya — fixed in #307, now merged and released as **v3.17.0** (`ghcr.io/raylabshq/gitea-mirror:v3.17.0`).
Root cause was a chain: the account-linker was refusing to attach your Authentik identity to your existing local admin because (a) your local account isn't email-verified (we don't run a verification flow), and (b) Better Auth's adapter was silently stripping the trust field before the check could see it. The `?error=UNKNOWN` you saw was the production error page sanitizing the real `account not linked` message.
Heads-up when you upgrade: in your SSO provider settings, make sure the **Domain** field matches the email domain of your Authentik users (e.g. `yourcompany.com`). Auto-linking is now scoped to that domain — it's how we avoid blanket-trusting every IdP for every email. Docs: [SSO-OIDC-SETUP.md → Account Linking](https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/SSO-OIDC-SETUP.md#account-linking).
Thanks for the detailed repro — the `?error=UNKNOWN` URL + the `BETTER_AUTH` log warning is what let us trace it.
@DunklerPhoenix commented on GitHub (Jun 2, 2026):
thank you
I'll test it later.
Is it also possible to set a default/wildcard provider that is used for all domains if no other is configured?
<!-- gh-comment-id:4599304867 -->
@DunklerPhoenix commented on GitHub (Jun 2, 2026):
thank you
I'll test it later.
Is it also possible to set a default/wildcard provider that is used for all domains if no other is configured?
@DunklerPhoenix Multi-domain is supported. Set the Domain field to a comma-separated list (acme.com,subsidiary.io,acquired.dev) and any user whose email ends in one of those domains will auto-link. Subdomains match their parent too (eng.acme.com → acme.com).
A true any-domain wildcard isn't supported because it would weaken the security model.
<!-- gh-comment-id:4599377962 -->
@arunavo4 commented on GitHub (Jun 2, 2026):
@DunklerPhoenix Multi-domain is supported. Set the **Domain** field to a comma-separated list (`acme.com,subsidiary.io,acquired.dev`) and any user whose email ends in one of those domains will auto-link. Subdomains match their parent too (`eng.acme.com` → `acme.com`).
A true any-domain wildcard isn't supported because it would weaken the security model.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @DunklerPhoenix on GitHub (May 28, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/306
Originally assigned to: @arunavo4 on GitHub.
Heho
You wrote in your doc https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/SSO_TESTING.md that the env
DEBUG=better-auth:* bun run devwill enable debug mode for sso.I tried it, but neither in docker logs nor in browser console are more informations.
The problem I have is that a click on sso just bring me back to the login screen again and I don't understand why.
How can I debug this?
SSO Provider: Authentik
Browser log:
console log at start
@arunavo4 commented on GitHub (May 29, 2026):
@DunklerPhoenix looks like there is an email linking issue. I will also take the chance to migrate the soon to be deprecated oidc plugin.
@arunavo4 commented on GitHub (May 31, 2026):
@DunklerPhoenix Can you help test the PR.
@DunklerPhoenix commented on GitHub (May 31, 2026):
Heho
The only thing that changed is a new step inbetween.
So:
EDIT2 (sry):
EDIT:
image: ghcr.io/raylabshq/gitea-mirror:pr-307
@arunavo4 commented on GitHub (Jun 2, 2026):
Heya — fixed in #307, now merged and released as v3.17.0 (
ghcr.io/raylabshq/gitea-mirror:v3.17.0).Root cause was a chain: the account-linker was refusing to attach your Authentik identity to your existing local admin because (a) your local account isn't email-verified (we don't run a verification flow), and (b) Better Auth's adapter was silently stripping the trust field before the check could see it. The
?error=UNKNOWNyou saw was the production error page sanitizing the realaccount not linkedmessage.Heads-up when you upgrade: in your SSO provider settings, make sure the Domain field matches the email domain of your Authentik users (e.g.
yourcompany.com). Auto-linking is now scoped to that domain — it's how we avoid blanket-trusting every IdP for every email. Docs: SSO-OIDC-SETUP.md → Account Linking.Thanks for the detailed repro — the
?error=UNKNOWNURL + theBETTER_AUTHlog warning is what let us trace it.@DunklerPhoenix commented on GitHub (Jun 2, 2026):
thank you
I'll test it later.
Is it also possible to set a default/wildcard provider that is used for all domains if no other is configured?
@arunavo4 commented on GitHub (Jun 2, 2026):
@DunklerPhoenix Multi-domain is supported. Set the Domain field to a comma-separated list (
acme.com,subsidiary.io,acquired.dev) and any user whose email ends in one of those domains will auto-link. Subdomains match their parent too (eng.acme.com→acme.com).A true any-domain wildcard isn't supported because it would weaken the security model.