Hi @Helvio88 - thanks for looking into this. I think tihs is the corect approach. The state request parameter is not being used. I understood the specs so that it is not required, I'm wondering why Authelia requires it. I'm just not sure if we should set it to some statically fixed string. It seems not so useful, wdyt?

If you like to test it offline, you don't need to really know sbt for that. Here are some tips, basically you need to install sbt, node and elm and start into sbt and then run restserver/reStart and it should compile and startup. I think we should at least test it a bit before merging. I can do that as well, ofc, might take a bit though :).

I was able to use restserver/reStart - how do I point to a specific config file?

Also, this is some quick information right from the source about the state parameter:
https://auth0.com/docs/secure/attack-protection/state-parameters

In short, you send a state string and then receive it back from the identity provider. It's another thing to match. If it doesn't match, then it's an invalid request. Most Identity Providers require it, but frequently a static state is sent. Could be an Env Var. I simply used the OIDC name - which should be enough.

In short, you send a state string and then receive it back from the identity provider. It's another thing to match. If it doesn't match, then it's an invalid request. Most Identity Providers require it, but frequently a static state is sent. Could be an Env Var. I simply used the OIDC name - which should be enough.

Yes, but we don't check it or do anything with it, so it feels a bit useless. I don't think it really helps in mitigating CSRF attacks then. This is more circumventing the IPs requirement of a state parameter. (I'm not really opposed to it :)). Maybe another variant would be to use a random signed string and check the signature… I would prefer not to maintain state on the server ….

I was able to use restserver/reStart - how do I point to a specific config file?

You can create a directory local in the source root and add a dev.conf file. I build.sbt this file is configured to be read if existing.

Also, this is some quick information right from the source about the state parameter:
https://auth0.com/docs/secure/attack-protection/state-parameters

Thank you - the link is helpful!

You can create a directory local in the source root and add a dev.conf file. I build.sbt this file is configured to be read if existing.

Thank you! Output said it picked up the conf file.
But I am still getting access denied. Although I am getting to the consent screen now, which is new! Will need to troubleshoot more! Thanks for the help so far, hopefully I can come up with something better soon!

Ah!

External accounts don't work when signup is closed!

Ah!

External accounts don't work when signup is closed!

Changing to open made it work! But I wonder if it's the right way to do OIDC lol

Changing to open made it work

Ah… it indeed sounds a bit weird! Does it also work with mode=invite? It might be because it needs to create a new account with the data from the IP. I need to look, forgot all about it. Regarding the state parameter, the specs say it is "recommended" - so sometimes I read this as "not needed" 😄 but it really means "should" - so we should add it I guess

Maybe a env or static string should be used instead, because some IPs need at least 8 characters. Leaving it the way I did would cause issues if people name it other than "docspell" or "authelia" which have 8 chars lol

Or go all in with CSRF mitigation with a random cookie. But I really don't think it's needed since it's already behind an IP.

Also, invite worked!

BTW what I meant that it doesn't work with closed - the user already existed. But I'm not sure which file will be responsible for that check (create or login).

I think somewhere in docspell/modules/backend/src/main/scala/docspell/backend/signup/OSignup.scala (line 80?) an OIDC user should be matched against the Users DB to see if exists and return accordingly. But I'm not familiar with Scala so I'm not sure I can help much here :(

Thank you for digging into this! I think this is a ordinary bug. It should work regardless of signup mode. It's two bugs now: the missing state parameter and its interfering with the signup setting.