oidc or remote authentication support

[rophy]

Hi, does snapp supports OIDC or remote authentication?

Remote authentication means snapp can assume a reverse proxy which handles user authentication, and determine authenticated username based on a defined header such as X-Remote-User.

[urania-dev]

Hello, no unfortunately it does not. And is not going to atm.

The app rely on Lucia auth with user/password auth. It could be easily implemented with a fork of the project maybe, but im try to add less features but in a more stable and controller manner.

[IvanLi-CN]

I apologize for commenting on a closed issue, but I'm particularly hopeful that snapp could integrate OIDC.

I've self-hosted many applications and use Authelia as an SSO solution. It's incredibly convenient not having to log in separately for each application.

I took a brief look at Lucia and it seems they offer integration options for OAuth 2.0 and OIDC: https://v2.lucia-auth.com/oauth/

If integration through Lucia is possible, would you be open to accepting a PR for OIDC support? I'm considering implementing this feature for my own use, but it would be great if it could be merged into the main repository.

Since I'm a bit busy, I haven't had the chance to dive deep into Lucia yet. So I'd like to hear your thoughts on this first.

[urania-dev]

actually we use lucia3, and lucia next is gonna be a manual instead of an actual library. so i think that yeah, it is possible, i just have to learn how to.

Edit: I re-read your message and just understood that you were offering to work on it, feel free, i'm trying to understand it better myself, we can join the effort :)

as for the auth library in use are lucia v3, oslo, and arcticjs i presume would be necessary too for oauth2 / oidc.

my main problem is that authelia itself is not directly listed in the examples, and i never used it, so i don't know wht to expect from said SSO, but is it interchangeable with keycloak? am i misunderstanding something?

if that would be the case i can implement keycloak flow i suppose "easily enough"

i suggest the copenaghen book by pilcrow (lucia author)

[urania-dev]

https://oslo.js.org/reference/oauth2/

[IvanLi-CN]

I'm glad to hear you mention Keycloak. Yes, it and Authelia can indeed be used interchangeably as OIDC Providers. The main difference is that Authelia might be a bit stricter in some specific details.

Is this the book you're referring to? It's fantastic! I just flipped through it and realized I might have read parts of it before, but I can't remember anything now. I feel quite embarrassed!

[urania-dev]

Indeed! :)

well i'm actually trying to configure my traefik to mount authelia, let me try 👯

[IvanLi-CN]

I'm ready for a pleasant surprise. 🎉

[urania-dev]

OIDC is up. tested with keycloak, if not working i think i can rearrange some piece to make it more versatile

[urania-dev]

I'm ready for a pleasant surprise. 🎉

did you manage to set it up? :)

[IvanLi-CN]

did you manage to set it up? :)

Sorry for the late reply, please give me some time, I want to verify that there is no arctic solution. Because I found that if I want to use authelia, I seem to have to write a custom provider separately. I looked at the code you submitted, and it seems that arctic and lucia are not as closely integrated as I thought. I will try to submit a code today to see if you can accept a more general solution.

[urania-dev]

Sorry didn't meant to pressure, was just curious about authelia

Well i havent found and authelia specific integration but artic and oslo operates as stand alone helpers, they don't look very interconnected by design i think (/s) . The generic oauth2 guide seems promising. Tho

Also, can you share authelia wellknown to understand how It works? I couldnt manage to set it on my homelab

[IvanLi-CN]

I've created a PR to temporarily store my proposed solution: https://github.com/urania-dev/snapp/pull/65#issue-2598870198

For self-hosted applications, I feel it's somewhat time-consuming to write boilerplate code for each new OIDC provider added. I couldn't find documentation in Arctic on how to create a generic OIDC provider, and it doesn't support discovery out of the box. So, I directly used openid-client to create a generic solution.

Ideally, I think we should offer tailored configuration options for common services like GitHub and Google, while using generic configuration for less common providers that support standard OIDC, such as Authelia and KeyCloak. This approach might reduce the effort required for code maintenance.

[IvanLi-CN]

can you share authelia wellknown to understand how It works? I couldnt manage to set it on my homelab

Have you run authelia but failed to integrate successfully? I am now trying to implement a custom arctic provider.

If it is about the configuration of Authelia, to be honest, it seems a bit complicated, and I feel that I cannot explain it clearly.

---

Edit:

Maybe this is what you want to know? Some endpoints of Authelia:

https://www.authelia.com/integration/openid-connect/introduction/#discoverable-endpoints

[urania-dev]

Well from the pull requests seems that you took your time to build a fully fleshed identità pocket based on the env set. It seems even more polished of my button left alone in signin. I try to merge It right away

[IvanLi-CN]

I've just created an Authelia Provider for Arctic. While it's not complete (some fields are missing), it should be sufficient for demonstration purposes. To save time, I directly overwrote the Keycloak provider you wrote. I've committed this directly to the PR branch we were discussing earlier.

https://github.com/urania-dev/snapp/pull/65/commits/7dd07baa007031e611557d29b7f72ff25009efa9

[urania-dev]

I merged my local version with your code.

let me just understand it better as i just woke up, you actually implemented a parallel series of check based on env and openid-client to correctly inspect and identify endpoints for the various oauth path.

so it would just suffice to be a correct way to implement oauth and i should remove the original /oauth and /oauth/callback to render it completely effective (thou i'm studing the artic implementation).

i think your solution works best

[IvanLi-CN]

Thank you for your acknowledgment. This solution was inspired by hedgedoc.

My idea is to immediately check and automatically discover OIDC Provider information when the program starts. Once everything is verified, it continues to boot, with data temporarily stored in the server's memory.

You might prefer storing configuration information in a database. I haven't looked into this part of the code yet, so I haven't considered this aspect at all.

The Arctic and oslo-related code does the same job, so yes, we need to choose one and remove the other.

There are many areas where this code can be improved:

• I'm not very familiar with Svelte, so things like global variables and directory structure might be poorly implemented.
• The validation of OIDC configuration parameters isn't thoroughly handled, and error messages aren't user-friendly.
• Exception handling is quite rough.
• Regarding naming, my personal intuition is that using 'OIDC' might be slightly better than 'OAuth'.

I've overextended my time and probably won't have the opportunity to refine it in the near future. If you have time, I'd be excited to see what improvements you might make. Looking forward to a pleasant surprise! :eyes:

[urania-dev]

weeeell, it doesn't seems that bad integrated, yeah the most error throw exceptions at the user, but should be addressed by admin on startup as part of the configuration.

i'll try to make it more user friendly

[urania-dev]

meanwhile, i'm building a version with your oauth, it should works pretty well. a thing that i think it doesn't passed enough is how grateful i am, it is the real first implementation of an entire flow from a pull collaboration, so learning new stuff and seeing the app grow it is really satisfying.

i'm looking forward to ear from you soon :)