This would require configuration with a whitelist of which OIDC IdPs to trust. Otherwise anybody could self-authorise a OIDC token (using their own IdP) and use that to log in.
glizzyguzzler@piefed.blahaj.zone 3 days ago
I am digging this, thanks for keeping it updated and improving it!
I see that you say it's feature complete / no user stuff; but it'd really mesh well if it took OIDC authentication. Don't need it to make users or anything, just instead of the password popup the OIDC provider is asked for confirmation that whatever user registered with the OIDC is logged in. That'd let me leverage extra 2FA protection from the OIDC provider and juice on that one-login life.
Now I have no experience making OIDC crap work nor how it even works behind the scenes, so I can't help :( sorry; just wishful thinking.
Also saw on your github - hope our newly shit-out gestapo don't bother you!
flubba86@lemmy.world 3 days ago
SinTan1729@programming.dev 3 days ago
Hmm, so that might be out of scope here. But I can try to do some kind of 2FA, shouldn’t be much of an issue, really. It’s just that I never thought a link shortener needed that kind of protection since the links will be shared anyway.
flubba86@lemmy.world 3 days ago
I agree with you, a simple minimal url-shortener does not need 2FA.
glizzyguzzler@piefed.blahaj.zone 2 days ago
Yes that tracks with how OIDC setup works with my other services (you give the container the OIDC links and shared secrets so it knows how to talk to the OIDC and trust it).
SinTan1729@programming.dev 3 days ago
I don’t understand much about OIDC either. But I’ll keep it in mind. Thanks.
And thanks for your concern. I’m doing fine for the time being.