SSOGEN / SSO Applications / GitHub SSO: Sign In to GitHub Through SSOGEN
Integration
GitHub SSO: Sign In to GitHub Through SSOGEN
GitHub SSO with SSOGEN uses either SAML 2.0 or OpenID Connect, whichever the application's settings page asks for. This page shows how to choose and which values go where.
GitHub SSO with SSOGEN signs your engineers in to GitHub with the same identity, sign-in policy and MFA as every other application. GitHub needs no catalog entry: SSOGEN connects any application that speaks SAML 2.0 or OpenID Connect.
- Roles. GitHub is the service provider (SAML) or the client (OpenID Connect), and SSOGEN is the identity provider.
- This page. the values to copy between the two screens.
- Labels. the GitHub administration screen uses its own labels, so match fields by meaning with the table below.
Values to copy for GitHub
| SSOGEN field or value | Vendor-neutral name in the application | Direction |
|---|---|---|
| Service provider entity ID | Entity ID, identifier, audience | From GitHub into SSOGEN |
| Assertion consumer service URL | ACS URL, reply URL | From GitHub into SSOGEN |
| Single logout URL (optional) | Logout URL | From GitHub into SSOGEN, if it has one |
| IdP entity ID | Identity provider entity ID, issuer | From SSOGEN into GitHub |
| Single sign-on URL | Sign-in URL, login URL | From SSOGEN into GitHub |
| Signing certificate | Identity provider certificate | From SSOGEN into GitHub |
| Name ID | User matching attribute | Choose in SSOGEN, set the same format in GitHub |
If GitHub publishes a metadata file, upload it in the Connection step, and SSOGEN fills in the first three rows. In the other direction, importing SSOGEN’s metadata address configures the last four rows at once, including the certificate.
Choose SAML or OIDC by the settings page
If an application can use either protocol, pick the one whose settings page you understand best.
- SAML. If the page asks for identity provider metadata, an entity ID or a sign-in URL, register a SAML application.
- OpenID Connect. If it asks for a client ID, secret or issuer address, register an OpenID Connect application.
- OpenID Connect in SSOGEN. It uses the authorization code flow with PKCE (S256) and exact
https://redirect URIs. - Library support. Check that the application’s library supports both.
Register, assign, test and activate
- In the Admin Console, open Applications, then SAML (or OpenID Connect) and start the registration wizard.
- Fill in General and Connection with the values above, choose a Sign-in policy, and set Identify the person by.
- Enter the Launch URL, the address that starts the application’s own SSO sign-in. Selecting Next saves the application, but it stays unavailable.
- Assign a person or group, run Test for a named person, and review the result.
- Select Activate application. The application then appears in My Apps for the people assigned to it.
The full screens and every message appear in Register a SAML application and Register an OpenID Connect application.
The test and activation details appear in Assign people, set the sign-in policy, test and activate.
Questions people ask
Does SSOGEN allow wildcards in redirect URIs?
No. SSOGEN matches redirect URIs exactly, and a trailing slash makes a different address.
What does the application get as the person’s identifier in OpenID Connect?
The sub claim. By default, it is SSOGEN’s stable identifier, not a readable name. If the application needs a readable name, pick another attribute under Identify the person by.
Can a program sign in to an API without a person?
Yes, through a service application that uses client credentials, registered under OpenID Connect.
Where to go next
SSOGEN has run single sign-on in production since 2016, and GitHub joins the same sign-in as your other applications.
- SSO applications hub. Return to the SSO applications hub for the protocol comparison and the other guides.
- Not sure which protocol? If you are not sure whether GitHub belongs under SAML or OpenID Connect, read Choose how to connect an application.