Skip to content

authentication

Subscribe to all “authentication” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Unlink your email in case of 2FA lockout

You can now unlink your email address from a two-factor enabled GitHub account in case you’re unable to sign into it or recover it. When the worst occurs, and a user is unable to find an SSH key, PAT, or a device that’s been previously signed into GitHub in order to recover their account, they may want to start fresh with a new GitHub.com account. Since accounts on GitHub are required to each have a unique email address, though, locked out users can have difficulty starting a new account using their preferred email address.

In the 2FA recovery flow, a new option is presented at the bottom of the page, which will allow a user to remove their email address from a GitHub account:

image

Selecting this option will send emails to each of the addresses on file for the account, each one containing a unique link. Following the link will remove the respective email address from the GitHub account, making it available again for a new account.

For more information, see Unlinking your email from a locked account.

See more

Second-factor validation after 2FA setup

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

See more

Updates to the two-factor authentication setup flow

As we prepare for next year's 2FA requirement for active contributors on GitHub, we're making improvements to our two-factor setup UI to encourage best practices and ensure new 2FA users have their authentication factors set up correctly from the start.

We now take an opinionated stance on which second factor you should set up first – you'll no longer be asked to choose between SMS or setting up an authenticator app (known as TOTP), and instead see the TOTP setup screen immediately when first setting up 2FA.

If you wish to use SMS when setting up 2FA, you can switch your authentication method via the new option at the bottom. In the future, you'll also find security keys there as an option for initial setup on supported devices and browsers.

For more information, see "Configuring two-factor authentication".

See more

OIDC for Azure AD Enterprise Managed Users is now GA

OpenID Connect (OIDC) for authenticating enterprise managed users is now generally available for enterprises using Azure AD.

OIDC allows GitHub to use your identity provider's IP allow list policies to control where PAT and SSH keys can be used to access GitHub from, with granular control down to individuals. Enterprise customers using OIDC can now select whether to use their identity provider's IP allow list policies, or GitHub's built-in allow list feature.

image

image

To learn more about OIDC and enterprise managed users, see "Enterprise Managed Users" and "Migrating from SAML to OIDC for Enterprise Managed Users". To learn more about Azure AD's IP allow list functionality, see "Location based Conditional access"

See more

New session and device management settings page

You can now review and manage your browser and GitHub Mobile sessions using the new Sessions tab in your user settings. This new tab includes all of your signed-in web sessions, as well as each GitHub Mobile app your account is signed into. You can revoke each web and mobile session individually. For mobile sessions, this signs you out of the GitHub Mobile app on that device, and disables that application for use as a second factor. The new Sessions tab replaces the web sessions view that was present under Password and authentication.

image

This new settings page is generally available for GitHub.com users now, and will be released to GitHub Enterprise Server as part of GHES 3.8.

To learn more, see "Viewing and managing your sessions".

See more

Private beta introducing innersource restrictions for Enterprise Managed Users

GitHub Enterprise Cloud customers that use Enterprise Managed Users (EMUs) can now participate in a private beta for a new user role that has restricted visibility of internal repositories. This role helps companies to work with contractors and collaborators in a flexible and managed fashion on specific projects, while also sharing code and ideas without restrictions amongst employees.

Users are granted this new role by being marked as "Restricted Users" in your identity provider. Enterprise members granted this role can be added to Organizations as members, and added to Organization teams – but they won't be able to see internal repositories in other Organizations unless explicitly added to those repositories one-by-one.

If you would like to enroll your EMU enterprise in this private beta, please reach out to your account team or contact our sales team for more details.

See more

Introducing fine-grained personal access tokens

Today we're enabling fine-grained personal access tokens (PATs) in Public Beta for all user accounts on GitHub.com. This new type of token gives developers and resource owners more control and visibility around token access. Learn more about this new token type in today's blog post.

These new tokens offer many more permissions to choose from, must be scoped to a specific organization or account, and must expire. Organization owners will also find new tools to manage tokens that can access their organization, and can require approval of those tokens before they may be used.

PATsv2-light2

You can try out the new token creation flow, and provide feedback in our community discussion.

For more information, see "Creating a fine-grained personal access token".

See more

Automatic Single Sign On for Enterprise Managed Users – Public Beta

Enterprise administrators can now choose to redirect signed-out Enterprise Managed Users to their company's single sign-on (SSO) page. This feature is available as a public beta.
By default, enterprises with Managed Users enabled are hidden, showing a 404 error page any time an enterprise resource is visited by a user that isn't already signed in to the enterprise.
If you enable this feature for your enterprise, visitors to resources in your enterprise, org, or user namespaces will immediately be presented with an SSO redirect if not already signed in to your enterprise.
This redirect helps users sign in to the correct account, rather than giving them the impression that the link they were given no longer works.

You can find this setting in the Authentication security section of your Enterprise Settings, below the single sign-on configuration sections.
image

Read more about this settings at "Automatic redirection for Enterprise Managed Users".

See more

Warning users about account relinking during SAML SSO

When users access an organization with SAML SSO, GitHub stores a link between the SAML identity and the user's GitHub account. This link is used by SCIM and team synchronization to grant access within your organization or enterprise. If you break this link by signing into that organization with a different SAML identity, you are likely to lose access to resources inside that organization.

Starting gradually today and being fully rolled out tomorrow, users will see a warning message if they attempt to sign in with a different SAML account and change their linked identity. They'll have the option to go back to their IdP to sign in with a different account, which is usually the correct option. If they really intend to break the link to their previous SAML account and link to a new one, they can choose to continue.

Learn more by reading "About Authentication with SAML SSO".

See more

Expiration dates of SAML-authorized PATs available via API

GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.

Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:

gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'

Learn more about authorizing a personal access token for use with SAML single sign-on.

See more

Sunset Notice Affecting Actions: API Authentication via Query Parameters

GitHub will stop supporting API Authentication via Query Parameters with Actions on October 6th 2021 at 14:00 UTC. If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • October 6 2021 at 14:00 UTC
See more

Sunset Notice: API Authentication via Query Parameters

As previously announced, on September 8th 2021 at 14:00 UTC, GitHub will stop supporting API Authentication via Query Parameters.

If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version API Authentication via Query Parameters will be removed.

See more

Git password authentication is shutting down

As previously announced, starting on August 13, 2021, at 09:00 PST, we will no longer accept account passwords when authenticating Git operations on GitHub.com. Instead, token-based authentication (for example, personal access, OAuth, SSH Key, or GitHub App installation token) will be required for all authenticated Git operations.

Please refer to this blog post for instructions on what you need to do to continue using git operations securely.

Removal

  • August 13, 2021, at 09:00 PST
See more

Sunset Notice: OAuth Application API

As previously announced, on August 11 2021 at 14:00 UTC, GitHub will be removing the OAuth Application API to avoid unintentional logging of in-transit access tokens.

Please refer to this blog post on migrating to the replacement endpoints.

Removal

  • August 11 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version the OAuth Application API will be removed.

See more

Brownout Notice: API Authentication via Query Parameters for 48 hours

As previously communicated, on August 11, 2021 at 14:00 UTC for 48 hours, GitHub will be conducting the third and final scheduled brownout for API Authentication via Query Parameters.

If you are passing credentials via query or path parameters, GitHub will intermittently respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Brownouts

  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version API Authentication via Query Parameters will be removed.

See more

GitHub App user-to-server REST API requests now have read access to public resources

API requests made by a GitHub App on behalf of a user that has authorized the app are known as user-to-server requests.

The resources that can be accessed by these requests are constrained to the set of private resources that both the App and the authorizing user can access.

GitHub is now extending this access model, allowing user-to-server requests to also read public resources over the REST API. This includes, for example, the ability to list a public repository's issues and pull requests, and to access a public repository's comments and content.

Read more about authorizing GitHub Apps.

See more

Expiration options for personal access tokens

You can now set an expiration date on your new and existing personal access tokens.

Setting an expiration date on personal access tokens is highly recommended as this helps keep your information secure. GitHub will send you an email when it's time to renew a token that's about to expire. Tokens that have expired can be regenerated, giving you a duplicate token with the same properties as the original.

When using a personal access token with the GitHub API, you'll see a new response header, GitHub-Authentication-Token-Expiration, indicating the token's expiration date. You can use this in scripts, for example to log a warning message as the expiration date approaches.

Learn more about personal access tokens and how to use them.

See more

Brownout Notice: API Authentication via Query Parameters, and the OAuth Applications API for 24 hours

As previously communicated, on June 9th, 2021 at 14:00 UTC we will be conducting the second scheduled brownout for API Authentication via Query Parameters and the OAuth Applications API. If you are passing credentials via query or path parameters, we will intermittently respond with client errors.

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more

Brownout Notice: API Authentication via Query Parameters, and the OAuth Applications API for 12 hours

As previously communicated, on May 5th, 2021 we will be conducting the first scheduled brownout for API Authentication via Query Parameters and the OAuth Applications API. If you are passing credentials via query or path parameters, we will intermittently respond with client errors.

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more

Sunsetting API Authentication via Query Parameters, and the OAuth Applications API

In February 2020, to strengthen the security of our API, we deprecated API Authentication via Query Parameters and the OAuth Application API to avoid unintentional logging of in-transit access tokens. In the coming months, we'll be removing these endpoints and authentication flow according to the following schedule:

OAuth Application API

Please refer to this blog post on migrating to the replacement endpoints.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC

Removal

  • August 11 2021 at 14:00 UTC

Authentication via Query Parameters

Please refer to this blog post for authentication via headers.

Brownouts

  • May 5, 2021: For 12 hours starting at 14:00 UTC
  • June 9, 2021: For 24 hours starting at 14:00 UTC
  • August 11, 2021: For 48 hours starting at 14:00 UTC

Removal

  • September 8 2021 at 14:00 UTC

Please check the latest Enterprise release notes to learn in which version these functionalities will be removed.

See more
View more changes