Support OIDC for login

Pre-release testing

Have you read the documentation?

Yes, but it does not include related information regarding my question.
Yes, but the steps described in the documentation do not work on my machine.
Yes, but I am having difficulty understanding it and wants clarification.

You are setting up gotify in

Docker
Linux native platform
Windows native platform

Describe your problem
Related to #203, #20.

I've noticed that authentication seems to be a hot topic for self-hostable services, like this one. There are many different standards people want supported (OIDC, SAML, AD, LDAP), all of which can be difficult to implement correctly and support. Libraries similar to passport.js can help, but generally have a learning curve to integrating them.

Looking through the Issues, another mode I have not seen suggested yet is to simply allow disabling of Authentication entirely. This has the benefits of:

No additional libraries or knowledge necessary for the developer to implement
Users can bring their own auth, typically in the form of a proxy like Oauth2-Proxy, or Traefik's ForwardAuth feature paired with an external Identity Provider like KeyCloak or Authelia
Users can choose to have no auth and only secure their systems behind a firewall instead (great for experimentation and local development)

Given the reluctance on #20. and the ongoing discussion about an Auth plugin system, this seemed worth mentioning. I've seen projects avoid Auth plugins and ONLY offer built-in Auth or none, I've also seen projects that offer support for every method under the sun. Just depends on what the devs feel comfortable supporting.

I think most folks would like to see support for an SSO strategy, whatever that is. I personally use OIDC, but mostly via Auth proxies since not a lot of projects have native OIDC support, which I think is fair.

Hey all, it would be great if some of you could test the OIDC support so we can fix any issues before release. You can get the latest changes via the master tag:

docker.io/gotify/server:master
ghcr.io/gotify/server:master

gotify/android supports OIDC with version 2.10.0. This will be released shortly on Google Play; F-Droid in a few days.

The latest changes on master include breaking API changes. If you use any of this endpoints, then please wait until we have proper migration documentation.

DELETE /application/:id
DELETE /client/:id
POST /current/user/password
All /user/* endpoints

Click the spoiler below to have a look at the OIDC documentation.

OIDC Documentation (click me)

OpenI…

Hey, just disabling auth isn't enough because gotify needs to know which user should be used. Sure, it should be possible to add a setting like preauthenticed_user to the config, which auto logs on an existing user, but this feels a little hacky.

Generally I'm open to natively support another auth system, but as you say it's hard to choose (:.

@jmattheis

Ok, I've spent slightly more than 2 minutes playing around with Gotify now. 😅 When I wrote the above I didn't realize there were multiple users, that does complicate things.

Proxies that do authentication will usually set a Header like X-Auth-Request-User, X-Auth-Request-Email, X-Auth-Request-Preferred-Username, X-Forwarded-User, or X-Remote-User to indicate which authenticated user the request is associated with. The upstream server (Gotify) then just usually has a config setting to indicate which header it should trust to find the username.

The security of this depends heavily on (1) the proxy overwriting any incoming values on the request for the Header being used to store the user, to prevent spoofing, and (2) that the communication between proxy and app server is secure, either via HTTPS or a private network. In a Docker environment with a good modern reverse proxy like Caddy, Traefik, HAProxy, etc, this is the case.

This can be a really easy way to support the bring-your-own-auth model @jmattheis , if that's what you're looking for, to keep Gotify simple. People will no doubt still ask for native OIDC, LDAP, SAML support though, so it really comes down to philosophically whether you think that complexity should be added natively, or not.

I don't expect a solution here anytime soon, so I'll consider this issue resolved and stick with the native auth for now, live without SSO. Feel free to close this if you see fit.

Any plans to implement this? Would be very useful

As a new user of this awesome project, This would be truly great to see implemented!

People will no doubt still ask for native OIDC, LDAP, SAML support though, so it really comes down to philosophically whether you think that complexity should be added natively, or not.

I vote for OIDC.

I think an auth plugin is possible although I defer to jannis for our final take on this. My recommendation is accept a PR but not priority.

SSO often goes beyond authentication and gets its hands on authorization (it is marketed as an authentication solution but in reality delivers much more than that) so everybody has different situations, can I know what kind of setup do you have?

Do you only want pure authentication (login once, get a token and end of story)? This feels doable. and my perceived benefit to you would be you can have one single login for all your services for you or your small team (?) But I still want to evaluate the feasibility of just using a proxy for this: essentially all you need is readapt a sample OIDC solution let it make a request to gotify and it would be similar result?

Do you want a more full workflow more designed for larger organizations (no client-side tokens, session management, etc), this feels like architecturally incompatible.

For my personal usecase I'm just tired of having a million accounts for something local to my home. Would be nice to be auto logged in as a user via oidc or an oidc proxy, some trusted header from a proxy or whatnot

I would really like to be able to use Authentik as an IDP, wether this is a full-on OIDC or SAML or just a plain proxy solution.

Running a home-server for a house hold with even a small number of applications will create a lot of user accounts. Authentik (or any IDP for that matter) will significantly decrease the number of accounts and passwords that we need to keep track of.

I'm not sure if making this pluggable is worth the effort designing and supporting the plugin interface. Gotify doesn't really need enterprise SSO stuff like SAML, as it's not really built for this anyway. I think supporting OIDC should cover nearly all use-cases and should be good enough.

We can probably ignore authorization, as the only configurable permission in gotify is creating users and this should be taken care by OIDC.

I will look at possible workflows this weekend. I never deployed OIDC on my own but I will try it out.

Related: #692

Thanks for looking into this. I had to build an OAuth 2.0 flow from nothing a while ago, though i'm not sure if i can be helpful. Let me know if you have a specific question.

I will look at possible workflows this weekend. I never deployed OIDC on my own but I will try it out.

Related: #692

Unfortunately, I cannot manage to get it working with Authentik. Connection try ends with error failed to initialize OIDC provider error="issuer does not match". The only tip I've found was in hashicorp/vault#25024 (comment), that issuer field must be the same as in url. Tripple checked - it's the same. I don't have more ideas.

Not quite sure what you/they mean exactly. Shouldn't that be by Definition since it's managed by a single System (Authentik IDP) ?

The issuer value returned MUST be identical to the Issuer URL that was used as the prefix to /.well-known/openid-configuration to retrieve the configuration information

Isn't that usually called (in Authentik) the Application's SLUG ?

Since I cannot test gotify for the Reasons mentioned above, I cannot really do the Test for you, but I would translate that Comment into the following (SLUG set to gotify for this Example).

Authentik -> Provider -> gotify -> Preview:

iss: https://authentik.MYDOMAIN.TLD/application/o/gotify/
aud: <Your OpenID Client ID>

Visiting https://authentik.MYDOMAIN.TLD/application/o/gotify/.well-known/openid-configuration should also yield "issuer": "https://authentik.MYDOMAIN.TLD/application/o/gotify/".

Not sure if you set different Names/SLUGs for Application/Provider, I usually just set the same (e.g. gotify) for both Application and Provider.

As some general Remarks related to many OpenID Issues I had in the Past, although the Signing/Encryption Key Issues tend to give more like a e.g. JWT Signing Algorithm ES256 / RS256 / HS256 Error, usually along with an Expected Message too, besides email_verified being required by some Applications and some recurrent Issues with Browser Cache/Cookies/Sessions:

Make sure that the Signing Key is either unset (if not needed), set to the Default authentik Self-signed Certificate or set to a custom generated RSA or ECDSA Key (I just generated one of each and share them across Providers).
Make sure that you do NOT confuse/mix Signing Key and Encryption Key
email_verified set to true might be required. You can force this by creating a Custom Scope Mapping in Customization -> Property Mappings -> Scope Mapping:
- Mapping Name: OAuth Mapping: OpenID 'email' with "email_verified": True
- Scope name: email
- Description: Email address (forced email verification)
- Expression:

return {
"email": user.email,
"email_verified": True,
}

Make sure that the correct Scopes are requested
Make sure Encryption Key is NOT set (though some few Applications require it)
Is there something weird in the Firefox/Chromium Developer Console ? What about the Network Tab, any weird Errors (404, 401, 500, 502, ...) ? Any weird Redirects with doubled-up Paths etc ?
Make sure that IPv6 Resolution (DNS) works correctly and points to the same Host as the IPv4 Resolution
Clear Browser Cache (Shift + click on the Refresh Icon)
Clear Browser Cookies (click on Icon on the left of the URL Bar, then select the Cookie and clear that)
Clear Browser History for the last e.g. 24 Hours
Check Authentik Server Logs to see if something weird is going on.

email_verified set to true might be required

It can be. I've created mapping as you suggested and it started. Thanks!

email_verified set to true might be required

It can be. I've created mapping as you suggested and it started. Thanks!

So this was the only Thing you needed to do in order to get it working 😮 ?

If so the Error Message is quite misleading.

I would suggest that you ping the People in the Issue you mentioned about the email_verified Issue you found 😉.

@jmattheis

@jmattheis: maybe add a Note in the OIDC Documentation about the email_verified Attribute/Property being required to be set to true (Email must be confirmed / verified in SSO / IDP), since that Error Message experienced by @Trishun is quite misleading.

Gotify doesn't validate email_verified. I can't reproduce the problem. I've set up a authentik instance with default config, created a single user and a oidc provider for the gotify. Only configured the redirect url and the group/user binding. For me this works without the email_verified property mapping.

It also highly unlikely that the error "issuer does not match" is caused by user properties. As at startup no users are fetched. This is only done when a user actually logs into the UI.

@jmattheis

@jmattheis: could it be that your Email is validated within Authentik, so you don't need that custom Scope Mapping ?

Anyways I remember that at some Point, probably 1 Year ago or so, there were some Changes such that Breakages might occur if Email is not validated (or if you don't use a custom Mapping).

This is the claim that reaches Gotify:

{"email":"[email protected]","email_verified":false,"given_name":"user","groups":[],"name":"user","nickname":"user","preferred_username":"user","sub":"9262af8ee9cd14df78511f729fbdfe7a6d8a63cd543129c99c5c25e8ec686edc"}

email verified comes from the default "authentik default OAuth Mapping: OpenID 'email'"

Even when disabling this scope mapping, thus returning no email properties. It still works for me.

{"given_name":"user","groups":[],"name":"user","nickname":"user","preferred_username":"user","sub":"9262af8ee9cd14df78511f729fbdfe7a6d8a63cd543129c99c5c25e8ec686edc"}

But yeah, doesn't really matter as these properties are not read at startup. If there is a startup problem it's a different problem.

Tested on pocket-id, works "out of the box" (no added scopes, etc.) Link by username successfully linked the admin user, although a group filter would be nice instead.
(Also tested the Android client, worked perfectly.)

Edit to add: the admin user was created from env vars on a fresh install. Haven't tried migrations.

Tested with kanidm on v2.9.1-134-g0fd65a0. Works without issue on both browser and android app interface.

Two questions, is it possible to disable local login and only use OIDC ? also any ability to assign admin vs regular user via group?

Other than that got it to work without any issues with Authentik.

@rafaelmathieu

@rafaelmathieu No both feature aren't supported and won't be included in the next release. See #991 and #957.

Released with v3.0.0. Thanks for everyone testing this feature before the release!

Released with v3.0.0. Thanks for everyone testing this feature before the release!

It works great, thank you!

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

Navigation Menu

Repository navigation

Support OIDC for login #433

Pre-release testing

OpenI…

43 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support OIDC for login #433

Description

Pre-release testing

OpenI…

Activity

jmattheis commented on Sep 17, 2021

tpansino commented on Sep 17, 2021

barrelltitor commented on Sep 5, 2022

yeyeoke commented on Jul 9, 2024

gthbusrr commented on Oct 1, 2024

eternal-flame-AD commented on Oct 1, 2024

barrelltitor commented on Oct 2, 2024

ericvenneker commented on Oct 2, 2024

jmattheis commented on Oct 3, 2024

eternal-flame-AD commented on Oct 3, 2024

najtin commented on Oct 4, 2024

43 remaining items

luckylinux commented on Jun 25, 2026

Trishun commented on Jun 25, 2026

luckylinux commented on Jun 26, 2026

luckylinux commented on Jun 26, 2026

jmattheis commented on Jun 27, 2026

luckylinux commented on Jun 27, 2026

jmattheis commented on Jun 27, 2026

disconn3ct commented on Jun 27, 2026

professorwaltwood commented on Jul 5, 2026

rafaelmathieu commented on Jul 7, 2026

jmattheis commented on Jul 7, 2026

jmattheis commented on Jul 18, 2026

wsw70 commented on Jul 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions