Skip to content

Option to disable local login when OIDC is enabled #1007

Closed
Closed
Option to disable local login when OIDC is enabled#1007
Labels
a:featureNew feature or request

Description

@MichielMak
MichielMak
opened on Jul 22, 2026

Is your feature request related to a problem? Please describe.
When OIDC SSO is enabled, the local username/password login form is still shown and the /auth/local/login endpoint stays active. In setups where all users should authenticate through the identity provider (centralized auth, MFA/policy enforced at the IdP, deprovisioning handled centrally), operators want to fully turn off local login so it can't be used as a bypass.

Describe the solution you'd like
A new boolean config option, e.g. GOTIFY_OIDC_DISABLELOCALLOGIN (default false). When it is true and OIDC is enabled:

  • Backend rejects POST /auth/local/login with 403 and a clear error instead of 404.
  • UI hides the username/password form (and the register button), leaving only the "Login with OIDC" button.
  • /gotifyinfo reports local-login availability so clients can adapt.

Critical safety behavior: the flag must ONLY take effect when OIDC is actually enabled. If DISABLELOCALLOGIN=true but OIDC is disabled, the flag is ignored (local login stays working) and a warning is logged, so an operator can never lock themselves out.

Describe alternatives you've considered

  • Reverse-proxy rules blocking /auth/local/login: works but is external, easy to misconfigure, and doesn't hide the UI form.
  • Removing local accounts entirely: not viable, a break-glass admin is often still wanted.

Additional context
We already have a working implementation on a local branch and are happy to open a PR if the maintainers are open to it. Rough scope:

  • config/keys.go, config/config.go: new env var + OIDC.DisableLocalLogin field.
  • router/router.go: conditional /auth/local/login handler (403 when disabled) + ignore-with-warning guard.
  • model/gotifyinfo.go, ui/serve.go: expose localLogin to clients/UI.
  • ui/src/config.ts, ui/src/user/Login.tsx: hide form/register, keep OIDC button.
  • Docs (gotify-server.env.example), swagger spec, and tests.

Happy to align with your preferred naming/behavior before submitting.

Activity

  1. jmattheis commented on Jul 24, 2026

    @jmattheis
    jmattheis
    on Jul 24, 2026
    Member

    Yeah, you can submit this, with these changes:

    • Besides /auth/local/login the handleUser path inside auth/authentication.go has to be disabled too, otherwise the local login credentials can still be used via basic auth on other api endpoints.
    • Setting should be called GOTIFY_LOCALAUTH_ENABELED with default true
    • If LOCALAUTH_ENABLED and OIDC_ENABELD are disabled, gotify should exit with a fatal error (log.Fatal()).
    • The flag in /gotifyinfo should be called localauth.
  2. Imagejmattheis
    added
    a:featureNew feature or request
    on Jul 24, 2026

  3. eternal-flame-AD commented on Jul 26, 2026

    @eternal-flame-AD
    eternal-flame-AD
    on Jul 26, 2026
    Member

    (this is just a discussion, no action required on this yet)

    @jmattheis should we also remove the policy on there being at least one admin because the presence of an admin should be deferred to the idp?

    In a full OIDC model I can see a valid setup where there is no admin and everyone just uses it as a normal user - until Gotify learns about an authorized user via a specific claim (which is a feature I see as important to add in the future).

    I imagine what an organization would want to have a workflow were they simply assign an IT admin claim and they just reauthenticate with gotify and automatically get admin (and vise versa they lose admin the next time they authenticate without the necessary claim). Instead what I see they have to do is currently is to have an emergency account using regular users or modify the database manually.

    Of course there is also the lockout concern - but I think we are already past that once we introduced IdP as it can get extremely difficult to recover from a situation where the only admin is an OIDC user but you accidentally deactivated that account on the IdP and Gotify has no way of knowing or stopping that.

  4. jmattheis commented on Jul 26, 2026

    @jmattheis
    jmattheis
    on Jul 26, 2026
    Member

    should we also remove the policy on there being at least one admin because the presence of an admin should be deferred to the idp?

    Yes, if localauth is disabled, the local admin creation should be disabled too.

    Of course there is also the lockout concern - but I think we are already past that once we introduced IdP as it can get extremely difficult to recover from a situation where the only admin is an OIDC user but you accidentally deactivated that account on the IdP and Gotify has no way of knowing or stopping that.

    If this is the case, then you can manually recover by enabling localauth and restarting gotify. I think this is good enough.

    OIDC admin user mapping is tracked here: #957.

  5. DerDummePunkt commented on Aug 4, 2026

    @DerDummePunkt
    DerDummePunkt
    on Aug 4, 2026
    Contributor

    I'm also working on an implementation of this.

    should we also remove the policy on there being at least one admin because the presence of an admin should be deferred to the idp?

    Yes, if localauth is disabled, the local admin creation should be disabled too.

    Just so i understand this correctly, we still want to allow a logged in admin to create/update/delete users in /#/users, since not every install will have GOTIFY_OIDC_AUTOREGISTER set to true (or GOTIFY_OIDC_LINK_BY_USERNAME for that matter),
    instead, we should disable the toggle for the admin status, correct?

    Wouldnt it make more sense to disable the password input field, when localauth is disabled, for this feature, and defer the admin status change to #957 ?

  6. jmattheis commented on Aug 4, 2026

    @jmattheis
    jmattheis
    on Aug 4, 2026
    Member

    instead, we should disable the toggle for the admin status, correct?

    I'm not sure I understand what you mean. This feature flag only affects how a user is able to authenticate. User creation/deleting/update endpoints should continue to work. It should be possible to change the admin status of a user, if localauth is disabled.

    Local admin creation, is a feature in gotify. If no user has the administrator flag, then gotify will create the default user on startup. If localauth is disabled, this default user shouldn't be created.

    If localauth is disabled the UI should hide the login form and only show the "login with oidc" button.

  7. DerDummePunkt commented on Aug 4, 2026

    @DerDummePunkt
    DerDummePunkt
    on Aug 4, 2026
    Contributor

    instead, we should disable the toggle for the admin status, correct?

    Local admin creation, is a feature in gotify. If no user has the administrator flag, then gotify will create the default user on startup. If localauth is disabled, this default user shouldn't be created.

    Aaah, got it, thats the part i missed, sorry.

  8. ImageDerDummePunkt
    added a commit that references this issue on Aug 4, 2026

    implements gotify#1007 - Option to

    3cbf90d
  9. Imagejmattheis
    added a commit that references this issue on Aug 13, 2026

    implements gotify#1007 - Option to

    c6b01be
  10. Imagepull
    added a commit that references this issue on Aug 13, 2026

    Merge pull request gotify#1020 from DerDummePunkt/github_1007_option_…

    aceb5ff
  11. Imagejmattheis
    closed this as completedon Sep 6, 2026
  12. ImagebigSmooth7867
    added a commit that references this issue on Sep 21, 2026

    Update gotify/server Docker tag to v3 (#705)

    ce946b9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    a:featureNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions