Analyze best practices for GitHub passkeys. Tailored for developers seeking to enhance security and user experience.
Robert
Created: July 19, 2023
Updated: June 3, 2024
Recent Articles
More and more companies from a wide range of industries are stepping into a password-free world and implement passkeys. Through this series of articles, we aim to provide a comprehensive overview of the passkey user experience of those companies. This should enable you to incorporate these findings and enhance your product login accordingly. In each article, we focus on a single company. Today, we dive into GitHub. Since July 12, existing GitHub users can create passkeys for their account and log in with them. This makes GitHub the pioneering company to predominantly focus on targeting passkeys towards software developers through its software development platform. The passkey rollout paves the way for over 100 million users to enter a password-free world that offers enhanced security and user-friendliness.
Disclaimer:
In this section, we present the most important insights we have gained from the analysis of GitHub passkeys.
GitHub passkeys are currently limited to logging into GitHub accounts. Currently, there are two ways to set up a passkey for the device in use. On the one hand, users can navigate to their account settings and enable passkeys manually. In the Password and authentication section, users manually create the passkey. On the other hand, users who have logged in with their password are presented with a pop-up message that recommends creating a passkey for their account. This hybrid rollout strategy allows GitHub to begin with low risk and identify any potential bugs by gathering feedback from early adopters. Hence, the phased implementation ensures a smooth transition and accommodates non-technical users who may be unfamiliar with passkeys as an additional login option.
As one of the first companies to introduce passkeys, GitHub allows the creation and use of passkeys in its native apps for Apple and Android. This convenient functionality enables mobile users to log into their GitHub accounts using passkeys directly through the app, eliminating the need to visit the GitHub website.
One of the standout features of GitHub's passkey implementation is the immediate integration of Conditional UI. This seamless integration allows for enhanced user convenience by automatically suggesting and prefilling stored passkeys when users click on the username input field. From the very beginning, GitHub users can experience the time-saving benefits of passkeys without the need for manual search or entry of credentials.
In the 'Password and authentication' section, where all stored GitHub passkeys of the user are displayed, GitHub provides interesting properties of the passkeys. They involve two badges that indicate the browser-operating system combination where the passkey was created and whether it has been synchronized. Additionally, timestamps are provided to indicate the creation and retrieval of the passkey.
GitHub uses the term passkeys. To cater users who may be unfamiliar with passkeys or seek further information, GitHub provides comprehensive descriptions conveniently located during the passkey creation process. The descriptions refer to the underlying concept of biometric authentication, whereby no platform-specific authentication methods are mentioned. This aspect also highlights the emphasis placed on passwordless authentication offered by passkeys, which is consistently emphasized throughout GitHub's passkey creation process.
Each time a user attempts to log into the GitHub app, they are directed to a WebView screen. Consequently, direct login to the app is not possible, and users are required to enter their login credentials within the WebView to log into the app successfully. That means that there is still potential to improve the UX of the native app.
Considering what is currently possible in terms of passkey features and technology, this is still by far the best implementation we came across so far during our series of analyses on passkey rollouts.
GitHub has published a comprehensive blog article that provides a detailed explanation of passkeys and guides users through the setup process. This highlights their efforts to persuade users about the benefits of passkeys and promote passwordless authentication. It also reflects their recognition of the need to educate users about the technology and functionality behind passkeys, as not everyone may be familiar with them yet. This also becomes clear during the process of creating new passkeys in GitHub (see use cases).
To enable passkeys for your GitHub account, follow these steps:
Go to the 'Settings' sidebar and find the 'Feature Preview' tab. Click on it and enable the passkeys feature. Once passkeys are enabled, you can upgrade eligible security keys to passkeys and register new passkeys.
You can now register new passkeys for your GitHub account. We show how this works in the tested cases in the next section.
Note that we have only performed the use cases with passkey-ready devices (e.g., no iPhone prior to iOS 16.0, no MacBook prior to macOS Ventura, no Windows device prior to Windows 10). We use the same GitHub account for every use case.
MacBook (macOS Ventura 13.4.1) | iPhone (iOS 16.5.1) | Xiaomi Mi 10 (Android 11) | Windows 11 | |
---|---|---|---|---|
Multi-device passkey | Use case 1 (Safari) | Use case 2 (GitHub iOS app) | Use case 3 (Chrome) | N/A |
Single-device passkey | N/A | N/A | N/A | Use case 4 (Chrome) |
Use case | MacBook Chrome passkey creation |
---|---|
Use case number | 1 |
Device | MacBook |
Operating system | macOS Ventura 13.4.1 |
Browser | Safari |
Platform | Apple |
Synced in | Apple iCloud Keychain |
To initially set up the first passkey for our GitHub account, we clicked on 'Add a passkey' as previously shown in step 7 and 8.
Before a new passkey can be created, GitHub requires the confirmation of our identity through two-factor authentication.
Once this has been successfully verified, a passkey can be created.
It is noteworthy that at this point the user is again informed about what passkeys are all about. This shows that GitHub wants to educate users who do not yet know passkeys.
After clicking on 'Add passkey', the default Apple passkey pop-up appears that prompts us to use Touch ID.
Once our fingerprint was successfully registered, we received a notification confirming the successful generation of the passkey. The passkey can now be named individually according to our preference.
The further explanations of passkey functions once again demonstrate GitHub's commitment to support its users at every stage and guiding them through the creation process.
We have assigned the name "Safari on macOS" to our passkey, which can now be found in our account settings under 'Password and authentication'. Additionally, the passkey properties are displayed, including the official passkey logo for identification. The properties also include two badges indicating the browser-operating system-combination on which the passkey was created and whether it was synchronized, along with timestamps for creation and retrieval of the passkey.
When using the same browser-operating system-combination for which a passkey has already been stored, GitHub detects this and prevents the creation or overwrite of an existing passkey.
Use case | iPhone GitHub iOS app passkey login |
---|---|
Use case number | 2 |
Device | iPhone |
Operating system | iOS 16.5.1 |
Browser | N/A |
Platform | Apple |
Synced in | Apple iCloud Keychain |
Here, we performed the same test as in the use case above. Instead of Safari, we used Chrome this time. Here, too, we encounter the already familiar passkey flow.In this use case, we used the previously created passkey to log in to the GitHub iOS app.
When logging into the native apps of GitHub, a WebView screen always appears where the user has to enter his login data. Upon entering our username, we were prompted to authenticate using two-factor authentication as the default method. Since we intended to log in with our passkey, we clicked on 'Use your passkey'.
By clicking on 'Use passkey' we retrieved our passkey which was previously synced in the Apple iCloud Keychain (see use case 1).
After verifying our identity with Face ID, the passkey was successfully retrieved, granting us access to our account and logging us in.
Use case | Android Chrome passkey creation |
---|---|
Use case number | 3 |
Device | Xiaomi Mi 10 |
Operating system | Android 11 |
Browser | Chrome 114 |
Platform | Android |
Synced in | Google Password Manager |
In this use case, we generated a passkey on an Android device using Chrome. Our objective was to store and synchronize this passkey using the Google Password Manager so that we can retrieve it in the subsequent use case. To ensure successful synchronization and retrieval, it is crucial to be logged in into Chrome using the same Google account.
After we clicked on 'Add passkey', we have gone through the already familiar passkey creation process.
Below the grey horizontal line, the Google Account can be set where the created passkey is to be stored.
Use case | Windows Chrome passkey login |
---|---|
Use case number | 4 |
Device | HUAWEI MateBook X Pro |
Operating system | Windows 11 Home 22H2 OS build 22621.1635 |
Browser | Chrome 114 |
Platform | Windows |
Synced in | N/A |
In this use case, we use the passkey that we created in use case 4. As this passkey is retrieved from an Android phone, no new passkey for Windows is created.
In every major browser, GitHub displays the same login screen. Under which conditions the 'Sign-in with a passkey' appears under the green 'Sign in' button, we are going to explain in section GitHubs passkey detection feature and Conditional UI.
After clicking the 'Sign-in with a passkey' button, we were presented with the familiar Chrome passkey pop-up. Here, we selected 'S21 von Vincent', which is the Android device linked to the Google account that holds the passkey from use case 4.
With this device, we scanned the QR code that appeared and successfully retrieved the passkey from use case 4.
Here, we refer again to the initial login screen, which in all major browsers consists of a 'Username or email address' and 'Password' input field and a green 'Sign in' button.
As mentioned before, under certain conditions a 'Sign-in with a passkey' button appears below the 'Sign in' button.
This is always the case if the user has already logged in to GitHub with a passkey on the device used in the active browser. This means that GitHub detects and recognizes the use of passkeys on their platform.
On the desktop, we took a closer look at how GitHub does it. When you go to the GitHub website, the browser requests a login fragment file from GitHub. In response, GitHub provides additional information regarding the user's passkey and device, enabling background detection of whether a passkey has been utilized for GitHub on that specific device previously.
By suggesting the use of a passkey with this button, it serves as a reminder that a stored passkey may be available for the account. This not only streamlines the login process but also reduces the number of clicks required, resulting in a more efficient user experience.
Speaking of the automatic suggestion to log in with a passkey, Conditional UI is still the most powerful feature. Conditional UI leverages the autofill function passkeys provide. It automatically prefills passkeys as soon as the user clicks on the username input field. This means that users no longer must search for their credentials manually (not even usernames!), as they are already stored in the device / browser and are automatically pre-filled.
Unlike Shopify (see our analysis of Shopify passkeys) and Microsoft (see our analysis of Microsoft passkeys), which also recently introduced passkeys, Conditional UI has been enabled on GitHub directly since it was rolled out.
GitHub's passkey implementation sets a new standard for all major companies introducing passkeys soon. Since its availability from July 12, 2023, GitHub has demonstrated a superior approach to passkey implementation among tech giants. With passkeys accessible on major platforms and browsers, including iOS, macOS, Windows, and Android, GitHub offers a seamless user experience. The convenience of passkey usage within GitHub's mobile apps and the integration of the Conditional UI feature further enhance user convenience. Additionally, insightful passkey properties and comprehensive user education contribute to a well-rounded passkey experience. GitHub's implementation showcases the potential and benefits of password-free authentication, establishing a benchmark for others to follow.
Table of Contents
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
We provide UI components, SDKs and guides to help you add passkeys to your app in <1 hour
Start for free