Yes indeed!
I did a LOT of tweaking and I should have kept better track of my work, but I want to try to keep this concise yet helpful so I don’t just simply overload you with everything I did 
If I’m looking at the Python source directly, there are five things that may be happening in that instance (unfortunately the same message is used for several scenarios):
-
Unable to add the user (i.e. user limit hit)
-
Unable to fetch session’s token using
CLIENT_SECRETandCLIENT_IDusingTOKEN_URL -
Unable to get session state using
AUTHORIZATION_URL -
Unable to obtain user info from
USER_INFO_URL -
Unable to generally authenticate
That error message is repeated in other places as well, but in those other instances, they have other attendant messages too which give more descriptive information.
Your URL’s for the above look fine. My only real difference is that I added port 9091 to my PROVIDER_DOMAIN as Authelia was listening there (i.e. authelia.example.us:9091).
(Incidentally, in Authelia’s docker-compose, I had to change…
expose:
- 9091
…to…
ports:
- 9091:9091
…in order for Authelia to start listening there)
So that’s on the Seafile side. As for the Authelia side, of course I had to properly set the authentication_backend properly with the encryption algorithm (and corresponding users database, for which I just used a YAML file). I also had to set the OIDC provider with a Java Web Key set, using client_secret_basic for the token_endpoint_auth_method, although for the key set, I needed to add a container environment variable in the docker-compose file so I could properly template/include the key file contents in the configuration:
environment:
- X_AUTHELIA_CONFIG_FILTERS=template
Then the last piece was Apache Traffic Server, my reverse proxy. I just had to make sure I was passing both HTTPS & WebSockets traffic.
So that’s it in a high-level nutshell. If need be we can start matching up configs.