Currently, Internet Identity uses two main methods to authenticate its users: passkeys and passphrases.
DFINITY is exploring the possibility of adding OpenID providers as authentication methods.
That would mean that users of Internet Identity could create an identity with Google or GitHub for example, and then use the same method to log into their favorite dapp.
OpenID providers would complement passkeys as an additional authentication method, but it would be up to the user to connect with them. Internet Identity will still prioritize passkeys as the primary method for authentication.
Why OpenID?
There are three main reasons to integrate with Open ID providers:
Reach a larger user base
Passkeys are a promising future technology but are not yet widely accessible or adopted. Many users either can’t use passkeys, don’t want to, or don’t know how to. By adding OpenID, Internet Identity can reach a much broader audience.
Leverage recovery mechanisms
OpenID providers offer built-in account recovery features. For example, if a user loses their passkey but has linked their Internet Identity to Google, they can still regain access through Google on another device.
Access from any device
OpenID enables users to log in to any dapp with Internet Identity on any device. This is particularly useful on shared or public devices where passkeys may not be an option, as users can authenticate via a familiar OpenID provider like Google.
Approach
The plan is to integrate OpenID in the following flows:
Link an OpenID provider to your Internet Identity.
Sign in using a linked OpenID provider.
Register a new Internet Identity with an OpenID provider.
These flows mirror those already available for passkeys, making OpenID providers a fully integrated and first-class authentication option within Internet Identity.
Security and Privacy First
Security and privacy are fundamental principles of Internet Identity, and the following points outline the key aspects of the OpenID provider integration.
Security
Fully on-chain
No additional web2 component will be developed for the integration. The only web2 components are redirecting the user to the OpenID provider and an HTTP outcall from the canister to get the certificates used to verify OpenID tokens.
Cryptographically secure
The OpenID token is bound to a cryptographic key pair during transmission to the Internet Identity canister, ensuring it cannot be intercepted and misused by unauthorized parties.
Privacy
Your data stays private
Internet Identity never shares any information with the OpenID provider, ensuring that your sensitive data, including your identity number, remains completely confidential.
Minimal data storage
Only the essential OpenID profile information required for authentication is securely stored within Internet Identity and is accessible only to you.
Google As the First OpenID Provider
The first Open ID provider that Internet Identity will support will be Google.
However, that doesn’t mean Internet Identity will not add more Open ID providers in the future. Internet Identity will remain vigilant in responding to the community and its users’ requests.
If you want ICP to succeed this is a must, security should not be enforced nor should UX be sacrificed in favor of security
It would nicely complement the OISY wallet, but OISY needs delegation support(for painless dev/user experience when talking to dapp canisters that contain logic, aka without user confirmation)
This is great! However, I didn’t see any mention in your post about giving consumers of Internet Identity the ability to opt out, allowing them to disable such types of sign-ins. Similarly to the existing option to opt out of the PIN method. I believe this could be beneficial for dApps using II that either have other plans or have a strict stance on decentralization.
Alternatively, instead of an opt-out feature, it might be interesting to allow developers to specify which providers are permitted or not. Either way, incorporating a mechanism to disable this feature in the approach would be valuable.
Dapps opted out of pin identities to avoid issues like loss of funds from temporary identities. Pin identities have since been deprecated and are no longer available.
OpenID-based identities are treated the same as Passkeys, sharing the same registration flow, including captcha. Users can link OpenID accounts to identities with Passkeys or add Passkeys to identities with linked accounts at any time.
Blocking users based on their Internet Identity authentication method would restrict access and compromise privacy, as authentication methods should not be public or used for exclusion.
Future improvements could include:
Utilizing a dapp registry to enable II to suggest additional Passkey authentication for specific dapps.
A way for dapps to specify a more fine-grained permission model for their own login. For example, requiring a passkey interaction or even two confirmations.
In my opinion, as mentionned, consumers should be able to enable or disable the sign-in methods they accept, just as they would with any other authentication provider. But feel free to ignore this suggestion—after all, dapps also have the choice not to use II at all if that’s really any issue for them.
To clarify, right now II authentication methods are scoped to the whole identity across all dapps a user interacts with. The future improvements listed, are under the assumption, additional authentication methods could be scoped per dapp.
This would mean that individual dapps could add additional security requirements for the login flow with their own dapp. Without requiring this for the whole identity and all other dapps the user interacts with.
If I get it right, the proposal is to keep the II protocol, so no change for dapps but the auth could happen through passphrase or Google / GitHub.
I think another big unlock would be to allow the relying party (dapp) to use OAuth2 against the II. Only session-based JWT can work I think but that would be a great step - any web2 app could now use the IC for auth. And of course more web3-specific features down the line.
On an abstract technical level, the II frontend would request a JWT from the OpenID provider and send it to the II canister to be verified and then register its claims.
Future logins would then be possible by requesting another JWT and sending it to the II canister to be verified and compared to the previously registered JWT claims.
Linked accounts are separate from the device list and will also not be returned from the lookup method. The lookup method is public and we don’t intend to make the linked accounts of II users public.
As mentioned above, linked accounts are separate so there will be separate canister methods to (un)link an account. The linked accounts will be shown in a separate section below the Passkeys sections.
The “scope per dapp” idea was mentioned as a possible approach to some of the concerns mentioned above in future overall improvements. There isn’t anything concrete yet in this regard at this moment.