View OpenId Connect Authentication on the plugin site for more information.
SummaryAllows users to authenticate using self hosted or public openid connect providers
Open Tickets (bugs and feature requests)
- Support for configuring by well known url (/.well-known/openid-configuration) see also https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
- We can now also look for groups in the UserInfo endpoint when it's configured
- Added documentation about how scripted clients should authenticate given this plugin is active
- Now honoring jenkins proxy settings see JenkinsBehindProxy
- Bugfix for regression, breaks on absent expires_in
- Local Login / escape hatch
- Fix JEP-200 compatibility
- Added test harness
- Using role-based permissions
- Fix for 1.1 breaking on existing configuration and configuration saving issues
- Add groups at login if provided in the idToken as an array of strings
- Exception with Azure authority needs testing
- Patched TokenResponse of the google oauth-client for better compatibility with openid provider implementations
- On Logout have the option to log out of OpenId Provider
- Friendlier error when the user declines authorization
- fix save not resetting userNameField and scopes to default values bug / User name field value not being updated
- Add new setting to disable sslVerification - for testing purposes enhancement
- Support OIDC UserInfo Endpoint enhancement
Configuration of this plugin takes a bit of effort as it requires some knowledge of the openid connect standard as well as the non-standard configuration of the various identity providers out there. Should you configure this plugin against a identity provider then please share your experiences and found caveats through a blog post or by adding it to the wiki.
Also note that the spec describes a wel known configuration location which will also help discovering your settings (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig)
Using the plugin with Azure AD
Interacting with Jenkins as a non front-end user
TLDR: use an API token instead as described here: Authenticating scripted clients
Using basic auth for authentication won't work. This is because jenkins has no knowledge of the password due to the way openid connect works: Indentifing a user is a three way interaction between the user, Jenkins and the openid provider.
The plugin asks the configured openid provider to confirm the identity of the user is and does thiis in a way that both jenkins and the provider are 'talking' about the same user. The openid connect provider will likely challenge the user to prove it's identity and might do this by requesting a username and password but this is entirely up to the provider. This part is between the user and the openid connect provider, jenkins (using this plugin) delegates proving ones identity to the provider and will go with whatever conclusion the provider draws. This has the benefit that with openid connect the service your trying to access (in our case Jenkins) never sees a user password, so even if Jenkins is compromised an attacker can't intercept passwords or other secrets. Using basic auth would require one to send their password to Jenkins which would defeat this.
Scripted clients can still interact with Jenkins even when the openid connect plugin is active: they will have to use an API token. Authenticating scripted clients describes how to obtain one.