Configuring Gitea with Tinyauth [SOLVED]

[stevenkain]

Managed so far to make Tinyauth work for Immich and Vaultwarden, but with Gitea I got stuck at "The provided redirect URI is not trusted" by Tinyauth. Any help appreciated :-(

per Gitea specific instructions:

When registering a new OAuth2 authentication, the callback/redirect URL should be: https://gitea.mysite.com/user/oauth2/TinyAuth/callback

For the purposes of this post https://auth.mysite.com is where my Tinyauth is hosted and respectively https://gitea.mysite.com where Gitea is, all features work perfectly, can log in with user & password.

Tinyauth .env settings:

TINYAUTH_APPURL=https://auth.mysite.com
TINYAUTH_APPS_IMMICH_CONFIG_DOMAIN=immich.mysite.com
TINYAUTH_APPS_VAULTWARDEN_CONFIG_DOMAIN=vault.mysite.com
TINYAUTH_APPS_GITEA_CONFIG_DOMAIN=gitea.mysite.com

TINYAUTH_OIDC_CLIENTS_GITEA_NAME=Gitea  
TINYAUTH_OIDC_CLIENTS_GITEA_CLIENTID=xxxx-same-as-gitea-configxxx  
TINYAUTH_OIDC_CLIENTS_GITEA_CLIENTSECRET=ta-same_as_gitea_configxxx
TINYAUTH_OIDC_CLIENTS_GITEA_TRUSTEDREDIRECTURIS=https://gitea.mysite.com/user/oauth2/TinyAuth/callback,https://gitea.mysite.com/auth/login,https://gitea.mysite.com/user-settings,https://gitea.mysite.com/api/oauth/mobile-redirect,app.gitea:///oauth-callback

Also tried adding these, didn't change the result of the error:

https://gitea.mysite.com/oauthredirect,https://gitea.mysite.com/login/oauth/authorize,https://gitea.mysite.com/login/oauth/access_token

Tinyauth runs as a docker (podman) container via quadlet configuration, behind a reverse proxy (OpenLiteSpeed) connected via Tinyauth's own self-generated socket. As mentioned, other apps (Immich, Vaultwarden) work flawlessly with Tinyauth logging in, so it must not be the proxy settings. OLS forwards all headers to Tinyauth and all certificates are up to date and reachable.

Gitea Admin Settings -> Identity & Access -> Authentication Sources:

Authentication Name: TinyAuth
✓ Skip local 2FA
OAuth2 Provider: OpenID Connect
Client ID (Key): xxxx-same-as-gitea-configxxx
Client Secret: ta-same_as_gitea_configxxx
Icon URL: https://auth.mysite.com/fav.ico
OpenID Connect Auto Discovery URL: https://auth.mysite.com/.well-known/openid-configuration
Additional Scopes: email profile

... (other settings left empty)

✓ Enable User Synchronization
✓ This Authentication Source is Activated

Tinyauth service Log entries:

{"level":"warn","stream":"app","error":"invalid_request_uri","time":"2026-10-31T04:50:34Z","time":"2026-10-31T04:50:34Z","message":"Failed to validate authorize params"}

{"level":"error","stream":"app","error":"invalid_request_uri","reason":"Redirect URI not trusted","time":"2026-10-31T04:50:34Z","time":"2026-10-31T04:50:34Z","message":"Authorization error"}

For the life of me, I can't find the actual redirect/callback URI Gitea is sending (and Tinyauth rejects)

[Rustaman1280]

The error "Redirect URI not trusted" means the exact string Gitea passes in the redirect_uri query parameter during the /authorize handshake does not match any entry in TINYAUTH_OIDC_CLIENTS_GITEA_TRUSTEDREDIRECTURIS.

Here is how to find the exact rejected URI, why it happens with Gitea, and how to fix it:

---

1. How to find the exact URI Gitea is sending

You can see the exact URI immediately without checking server logs:

1. Open Gitea in your browser and click the TinyAuth login button.
2. When the Tinyauth error page appears ("The provided redirect URI is not trusted"), look at your browser's Address Bar (URL).
3. The URL is calling Tinyauth's /authorize endpoint:
   https://auth.mysite.com/authorize?client_id=...&redirect_uri=<ENCODED_URI>&...
4. Inspect the redirect_uri= parameter in that URL (or check browser DevTools -> Network tab on the authorize request). URL-decode that value (e.g. %2F -> /) to see the verbatim string Gitea sent.

Alternatively, enable debug logging in Tinyauth:

TINYAUTH_LOG_LEVEL=debug

Tinyauth will then log both the incoming redirect_uri and the configured whitelist on validation failure.

---

2. Common Causes in Gitea

Cause A: Gitea ROOT_URL in app.ini

Gitea constructs its callback URI dynamically using the ROOT_URL defined in Gitea's app.ini:

[server]
ROOT_URL = https://gitea.mysite.com/

If your ROOT_URL in Gitea's config is set to http:// instead of https://, has a port (e.g. :3000), or uses localhost, Gitea will send that scheme/host, which Tinyauth will reject.

Cause B: Casing / Slugification of Authentication Name

Depending on your Gitea version, the OAuth provider name in the callback URL can be case-sensitive or converted to lowercase:

• If Gitea sends /user/oauth2/tinyauth/callback (lowercase), but Tinyauth only has .../TinyAuth/callback, validation will fail.

---

3. Solution

Update your TINYAUTH_OIDC_CLIENTS_GITEA_TRUSTEDREDIRECTURIS in your .env to include both lowercase and title-case variants, as well as trailing slash variations:

TINYAUTH_OIDC_CLIENTS_GITEA_TRUSTEDREDIRECTURIS=https://gitea.mysite.com/user/oauth2/TinyAuth/callback,https://gitea.mysite.com/user/oauth2/tinyauth/callback,https://gitea.mysite.com/user/oauth2/TinyAuth/callback/,https://gitea.mysite.com/user/oauth2/tinyauth/callback/

Then restart your Tinyauth pod/container:

systemctl --user restart tinyauth # or podman restart tinyauth

Once both case variants are listed and ROOT_URL in Gitea matches your public HTTPS domain, the OIDC handshake will succeed.

If this resolved your Gitea redirect URI error, please feel free to mark this as the accepted answer!

[stevenkain]

OMFG that was it ! Ihad ROOT_URL in Gitea still set to an internal IP. I would have NEVER figured it out.
Thank you a million @Rustaman1280 for the detailed and prompt answer. Now it works!

[stevenkain]

I am still curious towards which other apps people here managed to configure Tinyauth as an OAuth / OIDC sign-in option, besides the above listed 3 I so far found.

[Rustaman1280]

Here are several popular self-hosted applications that support standard OpenID Connect (OIDC) and integrate seamlessly with Tinyauth, along with their expected callback URI patterns:

---

1. Grafana

Grafana has native Generic OAuth support that works directly with Tinyauth discovery:

• Protocol: Generic OAuth / OIDC (grafana.ini)
• Callback URI: https://grafana.mysite.com/login/generic_oauth
• Scopes: openid email profile

2. Nextcloud

Nextcloud supports OIDC via the official user_oidc community app:

• Protocol: OpenID Connect (user_oidc)
• Callback URI: https://nextcloud.mysite.com/apps/user_oidc/code
• Discovery: Full auto-discovery support via https://auth.mysite.com/.well-known/openid-configuration

3. Portainer (CE / EE)

Portainer supports custom OAuth/OIDC under Settings -> Authentication:

• Protocol: Custom OAuth / OIDC
• Callback URI: https://portainer.mysite.com/ (or port-specific root URL)
• Scopes: openid email profile

4. BookStack

BookStack has built-in native OIDC configured purely via environment variables:

• Configuration: AUTH_METHOD=oidc, OIDC_ISSUER=https://auth.mysite.com
• Callback URI: https://wiki.mysite.com/oidc/callback
• Scopes: openid email profile

5. Mealie (Recipe & Meal Planner)

Mealie features native OIDC discovery support:

• Configuration:

  OIDC_AUTH_ENABLED=true
  OIDC_CONFIGURATION_URL=https://auth.mysite.com/.well-known/openid-configuration
  OIDC_CLIENT_ID=your-client-id
  OIDC_CLIENT_SECRET=your-secret

• Callback URI: https://mealie.mysite.com/login

6. Paperless-ngx

Paperless-ngx integrates with OIDC via django-allauth:

• Configuration:

  PAPERLESS_ENABLE_HTTP_REMOTE_USER=false
  PAPERLESS_SOCIALACCOUNT_PROVIDERS='{"openid_connect": {"SERVERS": [{"id": "tinyauth", "name": "TinyAuth", "server_url": "https://auth.mysite.com", "token_auth_method": "client_secret_post"}]}}'

• Callback URI: https://paperless.mysite.com/accounts/oidc/tinyauth/login/callback/

7. Uptime Kuma

Uptime Kuma supports OpenID Connect authentication natively in modern releases:

• Callback URI: https://kuma.mysite.com/api/oauth/callback

8. Jellyfin

With the official jellyfin-plugin-sso (OpenID Connect provider):

• Callback URI: https://jellyfin.mysite.com/sso/OID/redirect

---

Pro-Tip for Adding New Clients in Tinyauth

When adding any of these services to your Tinyauth .env:

TINYAUTH_OIDC_CLIENTS_<APP>_NAME="AppName"
TINYAUTH_OIDC_CLIENTS_<APP>_CLIENTID="app-client-id"
TINYAUTH_OIDC_CLIENTS_<APP>_CLIENTSECRET="app-client-secret"
TINYAUTH_OIDC_CLIENTS_<APP>_TRUSTEDREDIRECTURIS="https://app.mysite.com/callback-path"

Because Tinyauth strictly checks redirect URIs, always inspect the first authorization handshake in your browser Network tab to confirm whether the application appends trailing slashes or path parameters.