# OIDC (Microsoft Entra ID) login always redirects to /user/link\_account instead of auto-registering users **URL:** \ **Category:** Ecosystem\ **Created:** [April 18, 2026, 8:46pm UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058 "2026-04-18T20:46:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![granitehard](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/granitehard/32/7350_2.png) [@granitehard](https://forum.gitea.com/u/granitehard)\ **Post date:** [April 18, 2026, 8:46pm UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058/1 "2026-04-18T20:46:12Z")
## Description I am configuring OpenID Connect authentication with Microsoft Entra ID (Azure AD) in Gitea. Authentication succeeds, but users are never auto-created. Instead, Gitea consistently redirects to: ```auto /user/link_account ``` This occurs even when auto-registration is enabled and required claims appear to be configured. * * * ## Environment - Gitea version: latest (Docker image `gitea/gitea:latest`) - Deployment: Docker Compose - Database: PostgreSQL - Auth provider: Microsoft Entra ID (OIDC) * * * ## Configuration ### Gitea `app.ini` (relevant sections) ```auto [service] DISABLE_REGISTRATION = true ALLOW_ONLY_EXTERNAL_REGISTRATION = true REQUIRE_SIGNIN_VIEW = true [oauth2] ENABLE_AUTO_REGISTRATION = true ``` * * * ### OIDC Provider (Gitea UI) - Provider: OpenID Connect - Auto Discover URL: configured (Microsoft well-known endpoint) - Scopes: `openid profile email` - Auto Registration: enabled * * * ### Microsoft Entra Configuration - ID token optional claims added: - API permissions: - Admin consent granted * * * ## Observed Behavior - OAuth flow completes successfully - Callback endpoint is hit: - Gitea returns HTTP 303 and redirects to: - No user is created automatically Relevant logs: ```auto GET /user/oauth2/Microsoft/callback ... 303 See Other GET /user/link_account ... 200 OK ``` * * * ## Expected Behavior With `ENABLE_AUTO_REGISTRATION = true`, Gitea should: 1. Extract user identity from OIDC claims 2. Automatically create a new user 3. Log the user in * * * ## Additional Notes / Debugging - Debug logging enabled (`[log] LEVEL = debug`) - No OIDC claims are printed in logs - Behavior is consistent across multiple login attempts - Manual user creation + account linking works * * * ## Suspected Issue It appears Gitea is rejecting the OIDC identity for auto-registration, possibly due to: - Missing or untrusted `email` claim - Lack of `email_verified` - Incompatible or missing username mapping (`preferred_username` vs `sub`) - Strict validation of OIDC claims from Microsoft Entra However, there is no clear log output indicating which field is failing validation. * * * ## Questions 1. What exact claims are required for auto-registration to succeed? 2. Does Gitea require `email_verified = true`? 3. Which claim is used as the canonical username (`sub`, `preferred_username`, or `email`)? 4. Is Microsoft Entra ID officially supported/tested with OIDC in Gitea? 5. Can more verbose logging be enabled for OIDC claim validation failures? * * * ## Reproduction 1. Configure Microsoft Entra OIDC provider 2. Enable auto-registration in Gitea 3. Attempt login via OAuth2 4. Observe redirect to `/user/link_account` instead of account creation * * * ## Workaround - Manually creating users and linking accounts works - Considering using an intermediary IdP (e.g., Authentik) to normalize claims * * * ## Summary OIDC authentication with Microsoft Entra succeeds, but auto-registration consistently fails without clear error messaging, forcing manual account linking. Better documentation or logging around required claims and validation failures would help significantly. ---
**Author:** ![fzidar](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/fzidar/32/7393_2.png) [@fzidar](https://forum.gitea.com/u/fzidar)\ **Post date:** [May 1, 2026, 9:13pm UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058/2 "2026-05-01T21:13:20Z")
I’m running into the exact same issues. Have you found a better workaround or a solution? ---
**Author:** ![granitehard](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/granitehard/32/7350_2.png) [@granitehard](https://forum.gitea.com/u/granitehard)\ **Post date:** [May 1, 2026, 9:34pm UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058/3 "2026-05-01T21:34:33Z")
The best thing I found is to use a middleman like Authentik. I just use that for authentication for all my apps now because its a lot easier than setting up Entra for each app. ---
**Author:** ![adn77](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/adn77/32/7396_2.png) [@adn77](https://forum.gitea.com/u/adn77)\ **Post date:** [May 4, 2026, 6:16am UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058/4 "2026-05-04T06:16:08Z")
I have been fighting a similar issue th other day in another software stack (which led me to the Gitea forum). Eventually I adjusted the claims mapping in Entra: [OIDC account email is not verified - using Entra · Issue #159 · ZimengXiong/ExcaliDash · GitHub](https://github.com/ZimengXiong/ExcaliDash/issues/159) This is not saying that it will solve the logon issue in Gitea, but it might be worth a try 🙂 ---
**Author:** ![fzidar](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/fzidar/32/7393_2.png) [@fzidar](https://forum.gitea.com/u/fzidar)\ **Post date:** [May 4, 2026, 1:01pm UTC](https://forum.gitea.com/t/oidc-microsoft-entra-id-login-always-redirects-to-user-link-account-instead-of-auto-registering-users/12058/5 "2026-05-04T13:01:12Z")
I know you found a solution, but wanted to let you know that I updated my oauth2 configuration to the following: [oauth2\_client] ENABLE\_AUTO\_REGISTRATION = true USERNAME = preferred\_username ACCOUNT\_LINKING = auto OPENID\_CONNECT\_SCOPES = openid profile email UPDATE\_AVATAR = true And it is fixed now. I think the biggest unlock is the USERNAME = preferred\_username line.