Integrating OpenID Providers into Internet Identity

internet-identity
1

Context

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:

  1. 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.

  2. 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.

  3. 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.

Google has probably the most extensive user base. Gmail boasts over 1.8 billion users globally as of 2024.

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.

24 Likes
2

Yes I would love that. More options and flexibiliity the better.

3 Likes
3

This is great news! I believe this opens up a lot of possibilities for web2 companies to use the Internet Identity as the authentication method

3 Likes
4

This would be a very good approach to onboard web2 folks into the IC.
Looking forward to this integration.

3 Likes
5

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)

2 Likes
6

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.

4 Likes
7

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.
3 Likes
8

I never mentionned leaking such information.

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.

9

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.

10

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.

2 Likes
11

Hey @sea-snake

Could you provide a rough plan or outline of how this would work technically?

  1. Would a linked Google account simply appear as another passkey in the list returned by the lookup method?
  2. How would the “unlinking” of a Google account work? Would it just involve removing one of the eight (8) passkeys?
  3. Could you explain in more detail how the “scope per dApp” functionality works?

Thank you in advance!

1 Like
12

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.

  1. 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.
  2. 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.
  3. 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.
3 Likes
13

Does it mean that anyone (person or tool) will NOT be able to check if any particural II has linked OpenID accounts linked?

Its great that lookup method is public and anyone can check lets say if II has seed phrase attached or not :man_shrugging:t2: (its just one example).

14

Yes exactly, this was one of the primary design requirements in regards of privacy as listed in the OP.

Seed phrases are 24 words, which is such a high entropy that this public knowledge (its existence) does not make an account less secure. In most wallets with a seed phrase, this phrase isn’t just a password, it’s the private key itself for the identity. Other devices listed in lookup are WebAuthn devices, their data e.g. public key is unique on every registration, so it’s basically random data unless you own the device in question.

The public device lookup method is required to make the authentication with the WebAuthn standard work, to initiate the authentication with WebAuthn you need the credential id which we won’t be able to lookup on the sign in screen if it wasn’t public.

If you have any other privacy concerns with II, feel free to let us know :smiley:

15

Supporting OpenId and Google login is great, making it as easy as possible to login to ICP apps is key to longterm success! It definitely is key to mainstream adoption.

One thing worth considering and discussing is where this integration should happen. I would argue that Internet Identity is not necessarily the best place to add support. The Internet Identity is an application that builds on the core building block of IC identities/principals. Viewed that way, the Internet Identity could be said to be one identity provider among many.

That we know for a fact. There will be many. In addition to Internet Identity, we have sign in with Ethereum, with Solana, with Bitcoin, NFID etc. And, in addition to these there will be local sign in methods. If I as a Swede were to build an app for the Swedish market, I would be a fool not to try to integrate what we call “BankId”, a local authenticator with almost 100% adoption.

When I develop a Web2 app, I add a fairly minimal library to my frontend (and possibly backend) to get access to any/many login providers. I initiate the login request and get an identity (JWT) in return.

This we get with Internet Identity as well. But, if I, for example, want to add Ethereum login and Bitcoin login as well to my app, I need to add fairly heavy wallet libraries along with ic-siws and ic-siwb libraries.

I think we should consider letting all supported providers host an official authentication UI similar to the Internet Identity UI. That would mean, an app developer could add any number of authentication methods without bloating their frontend and adding tons of complexity.

With this perspective applied, we would build a standalone OpenId service instead of adding it to Internet Identity. In addition to building the OpenId service, we would build the libraries necessary for more of these identity provider services to happen. A service can be built by DFINITY or by the community.

I created some wireframes to describe how, from a user perspective, these two scenarios could look.

Curious to hear your thoughts.

Separate Identity providers for each method

image
image1197Ă—835 109 KB

OpenID is a “sub provider” to Internet Identity

image
image1197Ă—835 116 KB

5 Likes
16

Thanks for bringing this up! Let me discuss by describing my opinion on the two flows you’ve mentioned.

Separate Identity providers for each method

This flow describes multiple canisters which act as in between parties between a auth source (ethereum, wallets and openid like Google). Having reliance on in between parties like this is something that shouldn’t be needed in an ideal world. In practice due to technical limitations, you’d need an in between canister to mediate between the dapp and some auth sources.

In regards of OpenID, every provider (e.g. Google) needs to be implemented one by one to add support. By creating an in between canister for OpenID, you’d be creating a single point of authority over which OpenID providers are supported.

A similar issue occurs with wallets, this list would be an authority over which wallets are available and which not. One could argue that standards around wallet discovery would alleviate this issue - which it will - but if this is the case, then why not implement said standards directly from the dapp itself? This is currently ongoing in the Identity & Wallet standards WG.

Lastly for Ethereum, I’m aware that this also has technical limitations resulting in the need of a canister with a state to create delegations. Right now, I’m not sure if there’s a direct path around this

OpenID is a “sub provider” to Internet Identity

As mentioned in the OP, the main goal of OpenID sign-in is to offer users an alternative to passkeys to access their Internet Identity.

The OpenID metadata is assigned to the II account but not shared with the dapp. From the perspective of the dapp, it’s not aware that the user used either a passkey or OpenID credential. This is intentional, since the core feature of II is to give users privacy between different dapps.

Besides a passkey and OpenID, a user can also access their II account with a seed phrase. None of these authentication methods with II are shown to the dapp. From the perspective of the dapp, an II account signed in.

OpenID on the IC

For dapps that somehow need to directly integrate with OpenID providers on the IC. I think a more flexible approach, that doesn’t rely on intermediate parties, would be libraries or ready made canisters similar to the asset canister. This puts the implementation and control within the scope of the dapp itself.

This would also be needed for common OAuth flows where the token contains permissions e.g. a Discord sign-in with scopes to allow a bot running on the IC to take actions on Discord on behalf of the user.

3 Likes
17

just to clarify → the seed phrase can only be used for recovery and will - if used - “reset” the devices configured for the II, right?

18

I believe there should be at least a flag or a method to indicate whether any OpenID accounts are linked. The presence of such a method would allow certain dApps to decide whether to interact with a given Internet Identity or not.

19

At this moment the recovery phrase can only be used as recovery method. In practice this means it allows you to use the seed phrase to “sign in aka recover flow” with your recovery phrase into Internet Identity but not into a dapp.

Also your devices are not reset after using the recovery phrase, these remain the same and the recovery phrase doesn’t change either (can be used again).

1 Like
20

See this post above: Integrating OpenID Providers into Internet Identity - #7 by sea-snake

One idea mentioned here is that dapps should be able to define their security requirements, but should not be able to put requirements upon the II account as a whole