I have been searching through this subreddit to find a working example of Authelia ODIC with LubeLogger. I found a post that had a configuration but it does not seem to work for me. Authelia seems to process the request, but loops through this same response in the logs until the browser errors out. Seeing if anyone can help out with a working config example.
time=“2025-03-29T00:25:18-04:00” level=debug msg=“Authorization Request with id ’*’ on client with id ‘lubelogger’ is being processed” method=GET path=/api/oidc/authorization remote_ip=* time=“2025-03-29T00:25:20-04:00” level=debug msg=“Mark 1FA authentication attempt made by user ’*’” method=POST path=/api/firstfactor remote_ip=*
time=“2025-03-29T00:25:20-04:00” level=debug msg=“Successful 1FA authentication attempt made by user ’*’” method=POST path=/api/firstfactor remote_ip=*
time=“2025-03-29T00:25:21-04:00” level=debug msg=“Authorization Request with id ’*’ on client with id ‘lubelogger’ is being processed” method=GET path=/api/oidc/authorization remote_ip=*
time=“2025-03-29T00:25:21-04:00” level=debug msg=“Authorization Request with id ’*’ on client with id ‘lubelogger’ is not being redirected for reauthentication” authenticated_at=“2025-03-29 04:25:20 +0000 UTC” method=GET path=/api/oidc/authorization prompt= remote_ip=* requested_at=“2025-03-29 04:25:18.724520774 +0000 UTC”
time=“2025-03-29T00:25:21-04:00” level=debug msg=“Authorization Request with id ’*’ on client with id ‘lubelogger’ was successfully processed, proceeding to build Authorization Response” method=GET path=/api/oidc/authorization remote_ip=*
This is the Authelia config:
- client_id: lubelogger client_name: ‘Lube Logger’ client_secret: ‘SECRET’ pre_configured_consent_duration: 1M authorization_policy: one_factor token_endpoint_auth_method: ‘client_secret_post’ redirect_uris: - ‘https://cars.\*.\*/Login/RemoteAuth’ public: false pkce_challenge_method: S256 grant_types: - authorization_code - refresh_token scopes: - openid - email - profile userinfo_signed_response_alg: ‘none’ consent_mode: implicit id_token_signed_response_alg: ‘RS256’ id_token_signed_response_key_id: ”
I get this message from LubeLogger:
fail: CarCareTracker.Controllers.LoginController[0] Sequence contains no matching element info: CarCareTracker.Middleware.Authen[7] AuthN was not authenticated. Failure message: Cookie is invalid or does not exist.
And the OIDC portion of the .env:
OpenIDConfig__Name=“authelia” OpenIDConfig__ClientId=“lubelogger” OpenIDConfig__ClientSecret=“SECRET” OpenIDConfig__AuthURL=“https://auth.\*.\*/api/oidc/authorization” OpenIDConfig__TokenURL=“https://auth.\*.\*/api/oidc/token” OpenIDConfig__RedirectURL=“https://cars.\*.\*/Login/RemoteAuth” OpenIDConfig__Scope=openid email OpenIDConfig__ValidateState=true OpenIDConfig__UsePKCE=true OpenIDConfig__DisableRegularLogin=true OpenIDConfig__LogOutURL=“https://auth.\*.\*/logout”
Comments
ChiefAoki • 1 points • 2025-03-29
does your authelia user have an email address? I stepped through the code and the only place it will throw an error for sequence contains no matching elements is if Authelia doesn’t pass in an email claim in the response.
gibberoni • 1 points • 2025-03-30
Yes, checked in the user database and the user has an email that matches the email in LubeLogger.
I tried with both the root user (using the notify email), as well as creating a token for a new user with the same openID name and email, but still get the same loop.
ChiefAoki • 1 points • 2025-03-30
Okay, first I will set
OpenIDConfig__DisableRegularLogin=falseso that it no longer runs in a loop. This will require you to click ” Login via Authelia ” on the LL login page to kick off the OIDC auth flow.Then, can you set
OpenIDConfig__Scope="openid email"with the double quotes ? I believe this might be the issue, where only openid was requested by LL and not the email claim because of the lack of double quotes, note that this is system-specific.Once you can verify that it’s working you can set
OpenIDConfig__DisableRegularLogin=trueso that it will auto-init the OIDC login flow.Meanwhile, I’ll work on improving the error message, in the next release of LL, when it encounters an auth response with a missing email claim, it will instead print the following message:
OpenID Provider did not provide an email claim, claims returned: 'list of claims returned by the id_token'Which will probably help you troubleshoot.
gibberoni • 1 points • 2025-03-31
Thank you! I have tried the suggestions. I no longer loop, but I am returned back to the LL login screen after I see Authelia return a successful authentication. You are probably right that I am missing something when Authelia sends the response back.
I look forward to the update so I can troubleshoot. I sent you a coffee ;) thanks for the development on this!
ChiefAoki • 1 points • 2025-04-02
Just released 1.4.6, which will come with a RemoteAuthDebug endpoint that will allow you to analyze the steps in the OpenID login flow:
https://docs.lubelogger.com/Advanced/OpenID#advanced-troubleshooting
gibberoni • 1 points • 2025-04-02
This is great! Thank you! Looks like it is not returning the response that LL is expecting. I am going to spend tonight working on the response build from Authelia. Its currently sending bunch of extra information that is causing the issue.
I will reply back when I get it working, and you can add the Authelia settings to your docs if you would like to!
errtus • 1 points • 2025-04-03
Had the same problem after upgrading authelia to version 4.39 where they changed how claims parameter works (more info here https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter).
Basically what you have to do is:
In your authelia config on identity_providers level you have to have: identity_providers: oidc: claims_policies: legacy_claims: id_token: [‘email’, ‘email_verified’, ‘preferred_username’, ‘name’] …
Then still in authelia config where you have your
client_id: lubeloggeradd new keyclaims_policy: "legacy_claims". So you would have
- client_id: lubelogger client_name: “Lube Logger” … claims_policy: “legacy_claims”
Restart authelia + lubelogger and it should work :)
gibberoni • 1 points • 2025-04-03
Ah, this makes sense. I was trying to figure out how to form the response in Authelia and I guess the legacy way is it.
I will try this tonight and post the results. Hopefully this works!
gibberoni • 1 points • 2025-04-04
This was it! Amazing. Thank you so much for saving me a ton of time!
errtus • 1 points • 2025-04-04
I’m glad it worked :)
ChiefAoki • 1 points • 2025-04-04
Thanks for bringing this to my attention, I read the article and didn’t realize that passing the email scope via the id_token is considered legacy/outdated practice. I will implement some changes to LL in the next release that will take an additional parameter called userinfo endpoint to retrieve the email claim, so that it is future-proofed.
errtus • 1 points • 2025-04-04
Thanks man!
CardiologistApart1 • 1 points • 2025-05-14
I originally set this way, but my understanding is that on newer versions of Authelia this is not needed and I was able to remove the legacy claims successfully. Ultimately I switched to PocketID, but happy to share my settings with Authelia that was working.