Fix post-enrollment OIDC redirect/login flow for external users #39

Closed
opened 2026-06-03 20:36:54 -05:00 by Gitchegumi · 0 comments
Gitchegumi commented 2026-06-03 20:36:54 -05:00 (Migrated from github.com)

Problem

The current onboarding flow successfully creates a user in Authentik, but after enrollment the user is sent back to the GitchAlerts "Sign in with OIDC" page. When an external user clicks the button, the Authentik login portal is not served correctly.

This appears to work for me when I am on the same network as the server, but fails for friends accessing externally.

Current behavior

  • User opens the GitchAlerts invite/enrollment flow.
  • Authentik enrollment successfully creates the user.
  • User is redirected to the GitchAlerts sign-in page.
  • User clicks Sign in with OIDC.
  • The Authentik login portal is not served for external users.
  • Local/LAN access appears to work for the instance owner.

Expected behavior

After Authentik enrollment succeeds, the user should be able to complete OIDC login from outside the LAN using the public HTTPS routes.

Ideally, enrollment should either:

  1. log the user in and complete the OIDC callback into GitchAlerts automatically, or
  2. send the user to GitchAlerts sign-in where clicking Sign in with OIDC correctly routes to the public Authentik login/authorization URL.

Areas to inspect

  • AUTH_OIDC_ISSUER must use the public canonical Authentik issuer URL, not an internal hostname/IP.
  • NEXTAUTH_URL / app public URL must match the externally reachable GitchAlerts URL.
  • Authentik application/provider redirect URIs must include the public GitchAlerts callback URL.
  • GitchAlerts should not generate OIDC URLs using LAN-only hostnames.
  • Nginx Proxy Manager routing for Authentik and GitchAlerts should support external HTTPS access.
  • Authentik provider/application launch URL and allowed redirect/callback URLs.
  • Whether the enrollment flow's User Login stage is configured to land in the expected application/OIDC flow.
  • Whether GitchAlerts loses the invite cookie or callback state between enrollment and sign-in.
  • Whether browser redirects are moving between internal and external domains, IPs, or protocols.

Acceptance criteria

  • A newly enrolled external user can complete the full flow from outside the LAN:
    1. open GitchAlerts invite link,
    2. complete Authentik enrollment,
    3. complete OIDC sign-in,
    4. land in GitchAlerts dashboard,
    5. receive their own workspace.
  • Generated Authentik/OIDC URLs use the public HTTPS hostname, not LAN-only addresses.
  • The flow works from a device/network that is not on the server LAN.
  • If enrollment cannot automatically complete OIDC login, the fallback GitchAlerts sign-in button still works externally.
  • Add documentation for the required public URL/env values and Authentik redirect URI settings.

Notes

This is probably an integration/configuration edge between GitchAlerts, Authentik, NextAuth, and reverse proxy public URLs. The key symptom is that the account is created in Authentik, but the post-enrollment OIDC/login step does not work for external users.

## Problem The current onboarding flow successfully creates a user in Authentik, but after enrollment the user is sent back to the GitchAlerts "Sign in with OIDC" page. When an external user clicks the button, the Authentik login portal is not served correctly. This appears to work for me when I am on the same network as the server, but fails for friends accessing externally. ## Current behavior - User opens the GitchAlerts invite/enrollment flow. - Authentik enrollment successfully creates the user. - User is redirected to the GitchAlerts sign-in page. - User clicks **Sign in with OIDC**. - The Authentik login portal is not served for external users. - Local/LAN access appears to work for the instance owner. ## Expected behavior After Authentik enrollment succeeds, the user should be able to complete OIDC login from outside the LAN using the public HTTPS routes. Ideally, enrollment should either: 1. log the user in and complete the OIDC callback into GitchAlerts automatically, or 2. send the user to GitchAlerts sign-in where clicking **Sign in with OIDC** correctly routes to the public Authentik login/authorization URL. ## Areas to inspect - `AUTH_OIDC_ISSUER` must use the public canonical Authentik issuer URL, not an internal hostname/IP. - `NEXTAUTH_URL` / app public URL must match the externally reachable GitchAlerts URL. - Authentik application/provider redirect URIs must include the public GitchAlerts callback URL. - GitchAlerts should not generate OIDC URLs using LAN-only hostnames. - Nginx Proxy Manager routing for Authentik and GitchAlerts should support external HTTPS access. - Authentik provider/application launch URL and allowed redirect/callback URLs. - Whether the enrollment flow's User Login stage is configured to land in the expected application/OIDC flow. - Whether GitchAlerts loses the invite cookie or callback state between enrollment and sign-in. - Whether browser redirects are moving between internal and external domains, IPs, or protocols. ## Acceptance criteria - A newly enrolled external user can complete the full flow from outside the LAN: 1. open GitchAlerts invite link, 2. complete Authentik enrollment, 3. complete OIDC sign-in, 4. land in GitchAlerts dashboard, 5. receive their own workspace. - Generated Authentik/OIDC URLs use the public HTTPS hostname, not LAN-only addresses. - The flow works from a device/network that is not on the server LAN. - If enrollment cannot automatically complete OIDC login, the fallback GitchAlerts sign-in button still works externally. - Add documentation for the required public URL/env values and Authentik redirect URI settings. ## Notes This is probably an integration/configuration edge between GitchAlerts, Authentik, NextAuth, and reverse proxy public URLs. The key symptom is that the account is created in Authentik, but the post-enrollment OIDC/login step does not work for external users.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gitchegumi/GitchAlerts#39
No description provided.