github-oauth-plugin | Jenkins authentication plugin using GitHub OAuth | OAuth library

Before configuring the plugin you must create a GitHub application registration. The Client ID and the Client Secret will be used to configure the Jenkins Security Realm. Keep the page open to the application registration so this information can be copied to your Jenkins configuration. The security realm in Jenkins controls authentication (i.e. you are who you say you are). The GitHub Authentication Plugin provides a security realm to authenticate Jenkins users via GitHub OAuth. In the plugin configuration pages each field has a little (❓) next to it. Click on it for help about the setting. The authorization configuration in Jenkins controls what your users can do (i.e. read jobs, execute builds, administer permissions, etc.). The GitHub OAuth Plugin supports multiple ways of configuring authorization. It is highly recommended that you configure the security realm and log in via GitHub OAuth before configuring authorization. This way Jenkins can look up and verify users and groups if configuring matrix-based authorization. Control user authorization using the Github Committer Authorization Strategy. This is the simplest authorization strategy to get up and running. It handles authorization based on the git URL of a job and the type of access a user has to that project (i.e. Admin, Read/Write, Read-Only). There is a way to authorize the use of the /github-webhook callback url to receive post commit hooks from GitHub. This authorization strategy has a checkbox that can allow GitHub POST data to be received. You will still need to run the GitHub Plugin to have the message trigger the build. There are a few ways to configure the plugin so that everyone on your team has Overall/Administer access. Control user authorization using Matrix-based security or Project-based Matrix Authorization Strategy. Project-based Matrix Authorization Strategy allows one to configure authorization globally per project and, when using Project-based Matrix Authorization Strategy with the CloudBees folder plugin, per folder. There are a few built-in authorizations to consider. You can configure authorization based on GitHub users, organizations, or teams.
Visit https://github.com/settings/applications/new to create a GitHub application registration.
The values for application name, homepage URL, or application description don't matter. They can be customized however desired.
However, the authorization callback URL takes a specific value. It must be https://jenkins.example.com/securityRealm/finishLogin where jenkins.example.com is the location of the Jenkins server. The important part of the callback URL is /securityRealm/finishLogin
Finish by clicking Register application.
In the Global Security configuration choose the Security Realm to be GitHub Authentication Plugin.
The settings to configure are: GitHub Web URI, GitHub API URI, Client ID, Client Secret, and OAuth Scope(s).
If you're using GitHub Enterprise then the API URI is https://ghe.example.com/api/v3. The GitHub Enterprise API URI ends with /api/v3.
The recommended minimum GitHub OAuth scopes are read:org,user:email. The recommended scopes are designed for using both authentication and authorization functions in the plugin. If only authentication is being used then the scope can be further limited to (no scope) or user:email.
Choose Logged-in users can do anything authorization strategy.
Choose one of the matrix-based authorization strategies. Set authenticated users to Overall/Administer permissions. Set anonymous users to have Overall/Read permissions and perhaps the ViewStatus permission.
anonymous - is anyone who has not logged in. Recommended permissions are just Job/Discover and Job/ViewStatus.
authenticated - is anyone who has logged in. You can configure permissions for anybody who has logged into Jenkins. Recommended permissions are Overall/Read and View/Read. anonymous and authenticated usernames are case sensitive and must be lower case. This is a consideration when configuring authorizations via Groovy. Keep in mind that anonymous shows up as Anonymous in the Jenkins UI.
username - give permissions to a specific GitHub username.
organization - give permissions to every user that belongs to a specific GitHub organization.
organization*team - give permissions to a specific GitHub team of a GitHub organization. Notice that organization and team are separated by an asterisk (*).
After installing, the <securityRealm> class should have been updated in your /var/lib/jenkins/config.xml file. The value of <clientID> should agree with what you pasted into the admin UI. If it doesn't or you still can't log in, reset to <securityRealm class="hudson.security.HudsonPrivateSecurityRealm"> and restart Jenkins from the command-line.