# Connect a generic OIDC provider

> Register Buttons with an OpenID Connect provider, configure the connection, and test sign-in and access.

Use Generic OIDC to connect an OpenID Connect provider that supports Discovery, the Authorization Code flow, S256 PKCE, and nonce. Before you begin An Enterprise license and permission to manage SSO settings. Buttons' public address configured. On desktop deployments, use Environment Settings → Buttons External Address in the watchdog application. This address determines the callback URL, not Editor Listen Address . Your provider's Issuer URL and permission to register a confidential web application with a Client ID, Client Secret, and redirect URI. A provider that issues ID tokens signed with RS256 or ES256. Other signing algorithms are not supported. A tested local administrator account. Follow Get started with SSO for the shared setup and recovery guidance. Register Buttons with your provider Open Settings → SSO and select Add provider . Set Provider to Generic OIDC . Select Setup guide and copy the callback URL. In your provider, register a confidential web application and set its redirect/callback URI to the copied value. Note the application's Client ID and Client Secret, and the Issuer URL advertised by the provider's discovery document. If the public address is missing, both the setup guide and the connections list warn that the callback address needs configuration. Configure the connection Enter a Display name . Enter the Client ID and Client secret from your provider. Enter the Issuer URL . Use HTTPS. HTTP is accepted only for explicitly allowlisted hosts, for local testing. Add any Additional scopes you need. Buttons already requests openid , profile , and email . Save. Keep the Client Secret secure. When editing an existing connection, leave Client secret blank to keep the existing value. Map claims to roles After you save the connection, use Role mappings if the provider should assign local roles. Follow Map identity claims to roles to configure mappings and test sample claims. Test sign-in and access Enable the connection and the master SSO login toggle. Keep local login as the default while testing, as described in Get started with SSO . In a separate browser session, sign in through the new connection. Verify that the test user has the expected roles and access. OIDC has no separate Test connection action. Buttons checks discovery metadata and issuer configuration when sign-in starts, before redirecting to the provider. Token exchange and token validation happen after the provider returns the user to Buttons. If you get stuck What you see What to try The setup guide has no callback URL, or sign-in reports that the external Buttons address is not configured. Configure Buttons' public address, then copy the callback URL from Setup guide into your provider's redirect URI settings. The provider does not appear on the login page. Enable both the connection and SSO login . "This sign-in connection is not properly configured. Please contact your administrator." Check that the connection has a Client ID and Client Secret. "This sign-in provider is not properly configured." Check the Issuer URL against the discovery document. Check that the provider's endpoints use HTTPS and that it advertises RS256 or ES256 if it lists signing algorithms. "Unable to complete sign-in. Please try again." Retry, then check provider availability and network connectivity from the machine running Buttons. "Sign-in failed. Please try again." after returning from the provider. Start a new sign-in attempt. If it still fails, check the Client ID, Client Secret, registered redirect URI, and provider logs. Expired or reused sign-in state and token-validation failures can also cause this message. The user signs in but does not have the expected role. Check the mappings against the user's claims. See Map identity claims to roles for the accepted sample format and sign-in behavior. To correct the settings when OIDC sign-in fails, select sign in with password and use your local administrator credentials. Where to go next Get started with SSO Map identity claims to roles Connect LDAP or Active Directory