mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-11-04 00:02:23 +01:00
[Feature Request] OIDC / Forward Auth #15
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/gitea-mirror#15
Reference in new issue
Block a user
Hi
It would be awesome to have OIDC or Forward auth, examples:
https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/header_authentication
https://docs.goauthentik.io/integrations/services/bookstack/
That would be awesome, because one could simply log into main auth provider and not have to log in again on each selfhosted app.
Therefore log in automatically into gitea-mirror.
I guess it's best to decide, if the app stays single-user then header auth may probably be the best, if multi-user OIDC/Oauth.
I have been debating about single and multiple user casue I feel if people have multiple github accounts they could make seperate user accounts and have it work that way. but single account is just easier to manage. Will think more on it and see what I decide on
Yeah, I'd currently think single user is better for such a thing.
because with docker it's easy to run a second container.
dude, you are insanely quick, awesome :)
will test out as soon as release is up.
@CrazyWolf13 https://github.com/arunavo4/gitea-mirror/releases/tag/v2.19.0
Startup of the service seems to fail for me after update.
@CrazyWolf13 are you using docker or Proxmox?
Proxmox :)
@CrazyWolf13 I have made a patch update with some manual migrations. But will be releasing a breaking change major verison update with drizzle migrations for future proofing this.
Production build error fix:
Setup wizard on existing installation fix:
Hi @arunavo4
Thanks for the quick fix, though that does not seem to resolve the issue, I still see the error:
Neither the update, nor the both snippets above seem to fix it :/
The first command did just a build no special output, but the service still showed the above error.
The second command looks promising, but seems to fail.
@CrazyWolf13 Hey I dont want to spend time writing migrations so I have moved the application to use drizzle migrations for easy migrations in the future but it does come with a major breaking change so just do a fresh start from scratch.
future migrations should be seemless.
v3.0.0I am currently testing thisalright.
Please let me know the most semless way to migrate the whole community-script userbase (Roughly 100 Installs)
Plus if we need to do any special changes to our deployment.
@arunavo4 could you release v3 as an actual github release an tag it?
Seems like it's ony tagged on ghcr.
EDIT: seems like it's only prerelease.
It has issues so I have made pre release I need to fix the issues but I don't have time this week wait for next week I will try to find some time
Due to major issues I have removed the v3 branch and will update it once I have fully tested and fixed all the issues.
@CrazyWolf13 consider testing the latest v3 version
https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.0.0
@arunavo4 apologies for the delay, I was finally able to upgrade our script and also my personal instance. I fully reconfigured it too.
When clicking on the Authentification Part of that round bar, I end up with a black screen, I can't see anything in the log.
https://github.com/user-attachments/assets/9824c1bf-560d-4157-9b76-6ab0420cb4a5
Error from dev-tools:
I'm gonna close this as OIDC is implemented.
Checking in on this — as of v3.9.2, HTTP header / forward auth doesn't appear to be available in the UI anymore. The only options under "Add SSO Provider" are OIDC/OAuth2 and SAML 2.0. Was this dropped in the v3 rewrite, or is it still planned?
Hey @lanrat — header / forward auth is still supported in v3, it just isn't exposed in the "Add SSO Provider" dialog. That dialog is for OIDC/OAuth/SAML providers, which we store in the DB so per-user provisioning can be managed from the UI.
Header auth is intentionally environment-variable only, because trusting a header means trusting whatever upstream sets it — that's an operator-level decision (who controls the reverse proxy), not something a logged-in user inside the app should be able to flip on. So it lives outside the UI provider list.
Minimum config to turn it on:
The defaults are Authentik-shaped (
X-Authentik-Username/-Email/-Name); for Authelia or oauth2-proxy overrideHEADER_AUTH_USER_HEADER/_EMAIL_HEADER/_NAME_HEADER. Full variable list is indocs/ENVIRONMENT_VARIABLES.md.Once it's active you'll see a green "Header Authentication / Via reverse proxy" badge on the Authentication settings page, and
/api/auth/header-statusreturns{"enabled": true, ...}.Acknowledged that this wasn't discoverable — just landed a section in
docs/SSO-OIDC-SETUP.mdcovering setup, Authentik + Authelia examples, lookup order, and the must-strip-inbound-headers security note.Thanks for the reply — I gave it another shot on v3.16.1 with header overrides matching what Caddy / caddy-security sends, and it still doesn't work end to end. Server side picks up the headers fine, but the browser ends up back at
/login.Config:
Config is being loaded —
/api/auth/header-statusreports it:Cleanest repro, no proxy involved — running inside the container:
That's a 200 with body
nulleven with the headers right there on the request. The React app calls this on mount, seesnull, and the auth guard punts to/login.Looking at the source, I think this is what's going on:
src/middleware.tsL43–71 populatescontext.locals.user/sessionon header-auth success, but never sets a cookie, so nothing about the auth state survives the response.src/pages/api/auth/[...all].tshands the whole/api/auth/*surface off toauth.handler(Better Auth), which only knows about cookies — soget-sessioncan't see the header-authenticated user.Two ways out I can see: either the middleware mints a real Better Auth session/cookie when header auth succeeds, or
get-sessionfalls through to the header check when there's no cookie. Either one would unstick the SPA.If you push a fix I'm happy to test. It feels like header auth is one cookie away from working.
@lanrat thanks for testing it out. please give the latest version a try
Header auth works now. Thanks!