6 posts tagged with "OIDC"

Every tool in a typical self-hosted DevOps stack can act as an OpenID Connect client: Gitea and Argo CD speak OIDC natively, Jenkins does through the oic-auth plugin, Grafana and Portainer through generic OAuth 2.0, and MinIO, Harbor and GitLab through their OIDC settings. Point all of them at one Casdoor instance, give each tool its own Casdoor application, and put your people in Casdoor groups. Each tool then reads the groups claim and decides who is an administrator. This post lists the callback URL, the config keys and the group mapping for each tool, then covers the parts they share.

Open-source nginx has no CAS module, so "nginx CAS authentication" in practice means one of two setups. Either nginx asks an authentication service about every request through its auth_request module, and Casdoor answers (directly at /api/forward-auth, or through casdoor-forward-auth or OAuth2 Proxy), or the app behind nginx is itself a CAS client and talks to Casdoor's CAS server endpoints. If you can rebuild nginx, the Casdoor nginx module runs the login inside nginx, and if you'd rather not run nginx at all, Casdoor's site proxy can sit in front of the app. In every case the login page is Casdoor's, so one SSO session, one set of permissions and one MFA policy cover all the apps.

Logging a user out of an OpenID Connect app takes more than deleting your own session cookie. The user is still signed in at the identity provider, so the next "Sign in" click goes straight through without a password, and the other apps that share that identity provider session stay signed in too. A proper logout has three parts: clear your app's local session, send the browser to the provider's end_session_endpoint (RP-initiated logout) so the provider session ends, and let the provider tell the other apps through back-channel logout. With Casdoor, the end-session endpoint is /api/logout, back-channel logout is configured per application, and refresh tokens can be revoked at /api/login/oauth/revoke.

To add single sign-on to Spring Boot, register each app as an application in an OpenID Connect provider such as Casdoor, point Spring Security at the provider's issuer URL, and pick the Spring module that matches the app: oauth2Login() for a server-rendered web app, oauth2ResourceServer().jwt() for a REST API that receives bearer tokens, and Spring Cloud Gateway with the TokenRelay filter when one gateway signs users in for a set of microservices. Users get SSO because every app sends them to the same Casdoor, which remembers the session: the second app redirects, Casdoor already knows the user, and they come straight back without a login form. This post sets up all three shapes against one Casdoor, each with a working application.yml and a customized SecurityFilterChain.

Several Apache data and middleware projects ship a Casdoor login of their own: Apache DolphinScheduler has an authentication type called CASDOOR_SSO (since 3.2.0) and a generic OIDC mode (since 3.4.0), Apache ShenYu has a Casdoor plugin (since 2.5.1), Apache Pulsar Manager has a "Log in with Casdoor" button (since 0.3.0), and Apache APISIX has the authz-casdoor plugin (since 2.14.0). Apache IoTDB is the exception: the database itself authenticates with its own users and passwords, and only the now archived IoTDB Web Workbench talks to Casdoor. The table below lists every project, the version, and where the settings live; the second half of the post sets up user authentication in IoTDB step by step.

There is no "Steam OAuth": Steam signs users in with OpenID 2.0 and gives you a 64-bit SteamID, nothing more. Telegram's classic Login Widget isn't OAuth either: it hands your page a set of user fields plus an HMAC-SHA256 hash that you check with your bot token. Telegram now also runs a real OpenID Connect provider at oauth.telegram.org. If you put Casdoor between your app and these providers, Casdoor does the protocol-specific checks and your app only ever speaks OpenID Connect to Casdoor, the same way it would for Google or GitHub.