Skip to content

Authenticating via OpenID Connect

Configure OIDC for LubeLogger using the Server Settings Configurator

The following sample shows how to set up OIDC with Google as the provider with the LubeLogger instance running on https://localhost:5000

alt text

State Validation

When enabled, LubeLogger will validate the state token echoed back by the OIDC provider and will fail any login attempts where the state token is not identical to what it sent to the provider. Leave this disabled if you wish to have IdP-initiated SSO.

Proof of KeyCode Exchange(PKCE)

When enabled, LubeLogger will generate and pass in a SHA-256-hashed challenge code to the OIDC provider.

OIDC User Registration

There are three modes of registration when an OIDC user logs in to LubeLogger for the first time and they don't have an existing account in LubeLogger

Invitation Only

An admin user must generate a token for this user in order for them to create an account in LubeLogger, or in the case where Open Registration is enabled, the user must provide a valid and reachable email address and generate a token themselves.

Disable Registration

Only users with existing accounts in LubeLogger can log in via OIDC, they won't have an option to register an account when signing in via OIDC.

Auto Registration

All users logging in via OIDC for the first time will have an account automatically created for them. Do not enable this option unless you fully trust all of the users in your IdP. Do not enable this option if you are not the admin of your IdP. Enabling this option allows anyone from your IdP to register an account in LubeLogger. The users in your IdP should all have valid and reachable email addresses for future correspondence.

Testing

Once you have all these environment variables injected correctly, you should see the ability to login via your OIDC provider. Note: Currently LubeLogger only supports one OIDC provider.

alt text

alt text

LubeLogger uses the user's email address to authenticate against a registered user, the email address provided by the OIDC provider must match the email address of the user in the system.

If the user is attempting to login via OIDC but does not have an account with LubeLogger, they will be prompted for a registration token and to set up a username which will then allow them to log in. Note that the registration token is only required for their first time logging in.

Advanced Troubleshooting

The Remote Auth Debug endpoint allows users to diagnose OIDC-related issues by stepping through it:

  1. Set OpenIDConfig__RedirectURL to https://yourlubeloggerdomain/Login/RemoteAuthDebug
  2. Configure your OpenID Provider so that https://yourlubeloggerdomain/Login/RemoteAuthDebug is a valid Redirect URL
  3. Login using OIDC, instead of being redirected to login, you will be redirected to a page that displays checks and results.

Example scenarios(details redacted):

All checks passed and a user is identified:

alt text

All checks passed but no user is identified with the email(will be redirected to register under normal circumstances)

alt text

Failed State Validation, Expired OpenID Code and/or OpenID not returning id_token:

alt text

Failed Claim Validation(no email returned from OpenID Provider):

alt text

Authelia >= v4.39

There are breaking changes for users using Authelia with version >= 4.39

This is because LubeLogger utilizes the legacy method of retrieving the email claim via the id_token, which Authelia has deprecated as of v4.39.

If you're using LubeLogger <= v1.4.6, use the workaround below, otherwise, you can inject your Authelia's userinfo endpoint into the UserInfoURL environment variable, note that userinfo_signed_response_alg must be none in order for LubeLogger to integrate properly with Authelia

Authelia config in identity_providers:

identity_providers:
   oidc:
     claims_policies:
       legacy_claims:
         id_token: ['email', 'email_verified', 'preferred_username', 'name']
   ...

Authelia config for LubeLogger client:

    - client_id: lubelogger
      client_name: "Lube Logger"
      ...
      claims_policy: "legacy_claims"