NFT Provider

[taminobaumann]

☕️ Reasoning

What changes are being made? What feature/bug is being fixed here?

New Provider

Provider builds upon the IDP Kit of Walt.id (open-source) and enables authentication via NFTs.

🧢 Checklist

• [x] Documentation
• [x] Tests
• [x] Ready to be merged

📌 Resources

https://docs.walt.id/v/idpkit/concepts/identity-provision-via-nfts

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	❌ Failed (Inspect)			Apr 8, 2024 9:45pm
next-auth	✅ Ready (Inspect)	Visit Preview		Apr 8, 2024 9:45pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Apr 8, 2024 9:45pm

[ndom91]

We usually try to avoid adding additional options to providers other than clientId and clientSecret, but it looks like identityProviderURL is essential in this case, right? Because you can self-host / use a few different providers with walt-id by the looks of it.

If you're going to add an explicit extra option, especially one that is so critical like this seems to be, I'd recommend documenting this explicity in the README (nft.md) for the provider as well. Potentially giving a usage example also.

[taminobaumann]

Hey @ndom91

thanks for the review! Yes, the identityProviderURL is in this case essential. I've now expanded the configuration section, explaining why we need the extra parameter, and added two examples.

[ndom91]

@taminobaumann so I'm not super familiar with the whole web3/crypto space. Could you give me a high-level run down of how this works?

My assumption is Walt.id somehow checks I own a wallet address and/or asset like an NFT and then translates that authentication success into an oauth flow success so you can use it in standard oauth provider setting like here? :shrug:

[taminobaumann]

@ndom91 sure!

The IDP Kit implements the standards defined by OpenID Connect and can therefore be used similar to other providers. However, it adds some custom scopes like nft_token or siwe, which influence how the stage where the user authenticates looks like.

The flow works as follows:

1. The client makes a standard OIDC request to the authorize endpoint, requesting the open_id and nft_token scope. This tells the IDP Kit (Authorization Server) that the user wants to authenticate via an NFT.
2. The IDP Kit then redirects the user to a web page (in the normal flow this would be the consent page of for example google) with a wallet connect button. After the user has connected their crypto wallet, shared their address and signed a message with their private key, the information will be passed back to the IDP Kit.
3. The IDP Kit then takes the address and checks if the signed message was really signed by the address which the user provided, based on the principles, described in Sign-in With Ethereum.
4. Now that the IDP Kit knows that the address provided is owned by the user and valid, it can look up all related assets (NFTs) associated with that address on the blockchain.
5. If one of the associated assets is part of the NFT collection, configured in the IDP Kit, it will create a success response and redirect the user to the provided redirect url of the client, otherwise the authentication will fail.
6. Now the client will have an authorization_code which can be used, as standardized by OIDC, to e.g. request an access_token and then with it the user info. However, the user info will only provide what is available through the NFT used during authentication. Today, this will be the address of the user holding the NFT. In the future, this could also be more, depending on the metadata of the NFT.

We've also published a tutorial - Login with NFTs | Next.js, which will use the NFT Provider, once available.

[vercel[bot]]

@ndom91 is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[ndom91]

@taminobaumann would you still like to get this merged? I know this is an old PR.. But if yuo're still interested, the providers have moved to packages/core/src/providers/* :pray:

[taminobaumann]

@taminobaumann would you still like to get this merged? I know this is an old PR.. But if yuo're still interested, the providers have moved to packages/core/src/providers/* 🙏

Hey @ndom91 No merge is required anymore. Thanks for brining it up again. Closing this PR.