Skip to content

SSO/OIDC Configuration

Mydia supports OpenID Connect (OIDC) for single sign-on integration.

Supported Providers

Mydia works with any OIDC-compliant provider:

  • Keycloak
  • Authelia
  • Auth0
  • Okta
  • Azure AD
  • Google
  • And more...

Configuration

Environment Variables

OIDC_ENABLED=true
OIDC_ISSUER=https://your-provider
OIDC_CLIENT_ID=mydia
OIDC_CLIENT_SECRET=your-client-secret
OIDC_REDIRECT_URI=http://localhost:4000/auth/oidc/callback
OIDC_SCOPES=openid profile email

Variable Reference

Every OIDC variable is listed in Environment variables.

Provider Setup

Minimal Configuration

Mydia uses standard OAuth2 authentication. Configure your provider with:

  1. Client ID - Unique identifier for Mydia
  2. Client Secret - Secret key for authentication
  3. Redirect URI - https://your-mydia-host/auth/oidc/callback

No need to configure:

  • Token endpoint auth methods
  • Response modes
  • JWT-based authentication
  • PAR settings

Keycloak Example

  1. Create a new client in your realm
  2. Set client protocol to openid-connect
  3. Set access type to confidential
  4. Add redirect URI: https://mydia.example.com/auth/oidc/callback
  5. Copy client ID and secret
OIDC_ISSUER=https://keycloak.example.com/realms/myrealm
OIDC_CLIENT_ID=mydia
OIDC_CLIENT_SECRET=your-client-secret

Authelia Example

  1. Add client configuration to Authelia:
identity_providers:
  oidc:
    clients:
      - client_id: mydia
        client_secret: your-client-secret
        redirect_uris:
          - https://mydia.example.com/auth/oidc/callback
        scopes:
          - openid
          - profile
          - email
  1. Configure Mydia:
OIDC_ISSUER=https://authelia.example.com
OIDC_CLIENT_ID=mydia
OIDC_CLIENT_SECRET=your-client-secret

Auth0 Example

  1. Create a new Regular Web Application
  2. Configure allowed callback URLs
  3. Copy domain, client ID, and secret
OIDC_ISSUER=https://your-tenant.auth0.com
OIDC_CLIENT_ID=your-client-id
OIDC_CLIENT_SECRET=your-client-secret

Google Example

  1. Create OAuth 2.0 credentials in Google Cloud Console
  2. Add authorized redirect URIs
  3. Copy client ID and secret
OIDC_ISSUER=https://accounts.google.com
OIDC_CLIENT_ID=your-client-id.apps.googleusercontent.com
OIDC_CLIENT_SECRET=your-client-secret

User Management

First User Promotion

The first user to log in via OIDC is automatically promoted to admin role. Subsequent users are assigned guest role.

Role Assignment

Currently, role assignment is manual after first login:

  1. Admin logs in
  2. Navigates to Admin > Users
  3. Updates user role as needed

Combining with Local Auth

You can use both local and OIDC authentication:

LOCAL_AUTH_ENABLED=true
OIDC_ENABLED=true

Users see options for both on the login page.

Disabling Local Auth

For OIDC-only authentication:

LOCAL_AUTH_ENABLED=false
OIDC_ENABLED=true

Warning

Ensure OIDC is working before disabling local auth to avoid lockout.

Scopes

Default scopes:

OIDC_SCOPES=openid profile email

Required scopes:

  • openid - Required for OIDC
  • profile - User profile information
  • email - User email address

Redirect URI

If you do not set one, Mydia derives the redirect URI from its own external URL, which a release build hardcodes to https on port 443:

https://{PHX_HOST}/auth/oidc/callback

URL_SCHEME does not enter into it. The variable exists and is validated, but nothing in a release reads it, so the scheme is always https.

Serving Mydia over plain http breaks OIDC login

If your install is reachable at http://mydia.example.com, the auto-computed redirect URI is still https://mydia.example.com/auth/oidc/callback. Your provider will either reject it as an unregistered redirect URI or bounce the browser to an https address that nothing is listening on. Either way, login fails, and the error surfaces at the provider rather than in Mydia's logs, which makes it easy to misdiagnose.

Fix it by setting the redirect URI explicitly to match how you actually serve Mydia:

OIDC_REDIRECT_URI=http://mydia.example.com/auth/oidc/callback

Register the same value with your identity provider. Putting Mydia behind a proxy that terminates TLS is the better answer where you have the choice.

Set it explicitly with:

OIDC_REDIRECT_URI=https://mydia.example.com/auth/oidc/callback

Troubleshooting

Login Fails

  1. Check discovery document URI is accessible
  2. Verify client ID and secret
  3. Check redirect URI matches provider configuration
  4. Review application logs for errors

User Not Created

  1. Ensure required scopes are granted
  2. Check provider returns email claim
  3. Review application logs

Session Issues

  1. Check cookie settings
  2. Verify HTTPS configuration
  3. Check PHX_HOST matches your domain

Testing

Verify the setup end to end before you rely on it:

  1. Start Mydia and check the logs. On boot it logs the issuer, client ID, and redirect URI it will use, or (auto-generated) if you did not set one. Confirm the redirect URI matches what you registered with your provider.
  2. Log out, then use the OIDC button on the login page. A successful round trip lands you back on the dashboard with your provider account.
  3. Check Admin > Users. A first-time OIDC login creates the user. If no admin account exists yet, that user is promoted to admin so an OIDC-only deployment is not left with nobody who can administer it.
  4. Keep at least one working local admin account until you have confirmed OIDC login works. LOCAL_AUTH_ENABLED=false with a broken OIDC setup locks you out of the web interface entirely.

If you do lock yourself out, mydia-cli user inside the container can create or reset a local account. See User Management.