lastlogin-io/obligator

Simple and opinionated OpenID Connect server designed for self-hosters

obligator's Issues

Using Obligator to protect apps

Currently I am using Authentik to protect my apps. It is too slow and I would like to use Obligator instead. As I understand it, forward auth is the needed feature for this kind of stuff. But I can't wrap my head around what settings I need to specify in my reverse proxy.

I'm using Authentik with Caddy and this setup: https://docs.goauthentik.io/docs/providers/proxy/server_caddy

This way, when someone tries to access an app, he is first redirected to an outpost, where he must login.

Please let me know if this is possible to do with Obligator

Provide some sort of username in /userinfo

Hi,
I am trying to use this for Hedgedoc (v1) and there is seemingly no way to change your username. Therefore it would be nice for the /userinfo endpoint to provide one, as described in the openid docs.

Thanks for the great work,
Julian

Implement refresh tokens

Similar situation to dynamic client registration. Doesn't really add anything, but it's the expected flow for other software that wants to interact with obligator. See #28.

Docker repo is 404

pull access denied for anderspitman/obligator, repository does not exist or may require 'docker login'

Add Portier to the table

By far the project most similar to obligator that I've found

Implement dynamic client registration

Just need to return the requester's domain as the client_id and don't need to store anything

Should probably just remove the state parameter for upstream requests

Now that we're storing everything in JWTs, state isn't really doing anything, and it's optional https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1

lastlogin.io demo sends emails with invalid magic links

I just followed the instructions at the Demo section to try the obligator instance running at lastlogin.io using my email address. After a little while I recieved the email and clicked on the link but then it goes to lastlogin.io/magic?key...... and the error message "Invalid magic link" is displayed. Hower the URL seems to be fine having a key and an instance_id.

Implement scoping control for all cookies

Currently using obligator_ as a prefix for all cookies. This should be controllable by the user as it is for the login key cookie

suggestion for future consideration: WebAuthN FIDO2 (passkeys)

I have not done much digging into this project yet, but a suggestion I have after reading the readme file is in response to the blurb about sending a unique code to the email. The suggestion is to add a registration flow to confirm ownership of the email like you already are but then also allow linking that email to a FIDO2 token registration via webauthn, which is what passkeys use.

I suggest this because I use a variety of webauthn devices all the time now and I think that method of authenticating is much much better than passwords and is more convenient than clicking on a link sent to your email in my opinion. There are authenticator smartcards (my preference), USB tokens like yubikeys and the opensource derivatives, and of course now google and apple passkeys supported by the trusted platform modules or HSMs on the new phones.

Compare with IdentityServer

https://github.com/DuendeSoftware/IdentityServer

Implement login cookie editor

Users need to be able to delete old identities and login history as desired

[feedback] Kanidm comparison table line items

Hi there,

I'm the developer of Kanidm, I wanted to update some of your line items in the readme.

• Simple - This is subjective, but most of our users would say "yes" to this compared to keycloak or oauth2-proxy.
• Anonymous - No
• Multi-domain - No
• Email Login - No
• HTTP API - Yes
• Forward Auth - No (last we looked, it's insecure)
• Header Auth - Yes
• OIDC - Yes, we are a full OIDC server
• SAML - No
• MFA - Yes, including passkeys and attested passkeys
• Rev Proxy - No
• Admin GUI - No
• Client Registration - No
• Passkeys - Yes
• Attested Passkeys - Yes, we are the only IDP that supports these today

We also have active-active replication so we support HA

Implement copying logins when sharing via QR

Encrypt all cookies

Don't see a good reason not to, and it offers some defense in depth. At least random apps on the user's machine won't be able to snoop all their logins

TLSAuth parameter for SMTP

Actually testing your interesting software 👍

At the moment it is not possible to use SMTP endpoints which require SSL/TLS encryption for sending mails (e.g. smtp.office365.com) with the docker image. Checked the code and in the struct there are no params for this use case.

It would be nice if this is possible.

Add proper lifetimes to JWT cookies

Add Impersonation?

It is a pretty important feature for many within the auth / identity space. The only modern provider that seems to have support and documentation for "impersonation" is GoAuthentik - but I've not run through your full comparison table yet. Is that a feature you wouldn't mind adding to your comparison table?
Thanks!

Consider adding OpenZiti for application-embedded security

Currently the API is only offered through unix sockets. This reduces the chance that it accidentally gets exposed, which is important because it's not authenticated in any way.

Would you be open to embedding zero trust directly into the project via OpenZiti? OpenZiti allows you to have secure connectivity to the server from anywhere, via a zero trust overlay.

If that sounds interesting, I'd be happy to contribute a patch and if you're into it, demo it over on our YouTube channel too?

Need to properly validate URL params at token endpoint. Currently only requiring the code

Document that obligator intentionally violates draft-ietf-oauth-security-topics-24 4.1.3 by allowing any redirect URI that is a suffix of the client_id domain

Should be safe as long as we don't have an open redirector

Refresh token support?

Is it by design or not implemented that refresh tokens aren't implemented?. I see a security.md file that states they aren't implemented, but unsure if it's more a TODO, or would conflict with the stateless nature.

From #27 I was able to get lastlogin.io working with kubectl, however the one UX pain point is it seems the id_token lasts 10 minutes.
This means I am constantly logging back in :). It seems the kubectl plugin might support getting refresh tokens without the interactivity, but as obligator doesn't return them, I think it has to go for a full authorisation flow when the token expires.

obligator/docker/security.md

Line 33 in 8fc6dd1

We don't issue an refresh tokens

Fix QR issues

• Redirect to original instance when clustered
• Expire codes after a brief time

usage with cli tools

Hi there, this has been excellent where I have gotten it working, but wondering if it can be used in cli contexts too?.

Eg kubelogin is a kubectl plugin. I tried to configure it, but it seems to start a localhost:8000 server to manipulate (probably store) the tokens on the way through. This means the redirect URLs don't match, so obligator correctly rejects.

I am trying to figure out if these flows are actually compatible. Eg a cli tool might need some interactive page, that waits for the redirect to then persist on disk. Is this a use case obligator can support?.

I don't mind writing some code, say a kubectl plugin, but I suspect this may be impossible to even achieve due to how anonymous Auth in obligator works.

Maybe add https://github.com/panva/node-oidc-provider to the table