Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The IDP Kit supports retrieval and verification of NFTs from wallets.
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
When using NFTs as information source, the IDP Kit will derive the required NFT collection from the authentication request and redirect to an application, where the user can connect his wallet and share their address.
After the user has shared their address, the application will send it back to the IDP Kit, where the NFT Manager will make sure that the user is the rightful owner of that shared address, by utilizing the concepts described in EIP-4361: Sign-In with Ethereum, and that the shared address is associated with the required NFT collection sent in the authentication request. Have a look at the NFT Manager configuration page to see how this can be configured and which defaults can be set.
The verified data is then transformed into the response format requested by the application, which by default will include the account address and optionally specified metadata of the NFT.
The authorization flow visualized
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
IDP Kit receiving the request
The IDP Kit takes the request and opens a wallet connect page, where the user is prompted to connect their wallet to the page and share their address. The shared address will then be sent back to the IDP Kit, which verifies that the user is the rightful owner and holder of an NFT of the required NFT collection. After verification, the IDP Kit sends the information (account address/nft metadata) back to the client application in the nft_token property of the user info.
The application can rely on the received data, as the IDP Kit is verifying the ownership of NFT and address.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
The IDP Kit supports Sign In With Ethereum (SIWE).
This section will explain the principles of how OIDC authentication requests are translated into SIWE requests and the options available to craft such requests.
To understand how identity provision via SIWE can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
When using SIWE as information source, the client application needs to specify the custom siwe claim in the authorization request.
The IDP Kit then takes the request and opens a wallet connect page, where the user is prompted to connect their wallet to the page and share their address. The shared address will then be sent back to the IDP Kit, which verifies that the user is the rightful owner.
After verification, the IDP Kit sends the account address back to the client application in the siwe property of the user info.
The application can rely on the received data, as the IDP Kit is verifying the ownership of the address.
The IDP Kit supports retrieval and verification of NFTs from Tezos ledger.
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
The IDP Kit transforms the ownership of NFT on the Tezos ledger into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWT, NFT, and their metadata.
Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Tezos ledger. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
The whole verification process has seven main steps:
The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.
The IDP Kit processes the verification request. If it is an NFT Tezos verification, the IDP Kit redirects the user to his user interface.
Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWT process.
The SIWT process continues within the IDP Kit by verifying the user address and the message signature.
After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Tezos ledger. The NFT collection information is defined in the IDP Kit configuration file.
If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.
In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.
The authorization flow visualized
OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.
SIWT is used to verify that the user controls and owns the private key of a Tezos account.
We can apply policies to the NFT metadata based on the Open policy agent(OPA).
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
This documentation section will dive deep into implementing the Sign-in with Tezos(SIWT). For more details about the concept Sign in With X (SIWx), .
Sign-In with Tezos describes how Tezos accounts authenticate with off-chain services by signing a message parameterized by scope, nonce, etc. It is an alternative to centralized identity providers. It is based on the self-custody of your identity. It leverages the on-chain authentication model to off-chain services.
The reason behind implementing the concept Sign-In with Tezos is that it is a critical step in the Login with NFTs concept. Before granting access to some services based on the ownership of some NFTs, we need to check two main aspects:
You own an account via Sign with Tezos.
Verify that the account has an NFT in a specified collection.
An account in Tezos is linked to the ownership of a private key which is then mapped to his public key. The hash of the public key outputs an address. Depending on the chosen Digital Signature Algorithm's elliptic curve (see ECDSA), the latter starts with "tz1" (Ed25519 curve), "tz2" (Secp256k1 curve), or "tz3" (P256 curve).
The IDP Kit implements SIWT based on seven main steps:
Nonce generation.
Redirection to the IDK Kit wallet user interface.
Connect to your Temple wallet.
A popup appears for signing the message. It is based on multiple factors like the nonce generated by the IDP Kit, account address, etc.
Click the “Sign” button.
Redirection to the IDK Kit verification service.
The IDP Kit verifies the message signature based on the account address.
The message will be in the form of:
{domain} wants you to sign in with your Tezos account: {address}. Public Key: {publicKey}.Date: {ISO8601formatedTimestamp}. {description} URI: {origin}. Version: {versionNumber}. Nonce: {nonce}
domain: is the RFC 3986 authority that is requesting the signing.
Permissions.address: account address.
Public Key : account public key.
Date: is the ISO 8601 datetime string of the current time.
Nonce:security parameter generated by the IDP Kit.
Algorand
Ethereum / Polygone
Tezos
Near
Polkadot
Flow
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
The IDP Kit transforms the ownership of NFT on the Near Protocol into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWN, NFT, and their metadata.
Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Near Protocol. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
The whole verification process has seven main steps:
The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.
The IDP Kit processes the verification request. If it is an NFT Near Protocol verification, the IDP Kit redirects the user to his user interface.
Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWN process.
The SIWN process continues within the IDP Kit by verifying the user address and the message signature.
After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Near Protocol Blockchain. The NFT collection information is defined in the IDP Kit configuration file.
If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.
In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.
The authorization flow visualized
OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.
SIWN is used to verify that the user controls and owns the private key of a Near account.
We can apply policies to the NFT metadata based on the Open policy agent(OPA).
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
This documentation section will dive deep into implementing the Sign-in with Near Protocol(SIWN). For more details about the concept Sign in With X (SIWx), CAIP-122.
Sign-In with Near Protocol describes how Near accounts authenticate with off-chain services by signing a message parameterized by scope, nonce, etc. It is an alternative to centralized identity providers. It is based on the self-custody of your identity. It leverages the on-chain authentication model to off-chain services.
The reason behind implementing the concept Sign-In with Near is that it is a critical step in the Login with NFTs concept. Before granting access to some services based on the ownership of some NFTs, we need to check two main aspects:
You own an account via Sign with Near.
Verify that the account has an NFT in a specified collection.
An account in Near is linked to the ownership of a private key which is then mapped to his public key. The hash of the public key outputs an address.
The IDP Kit implements SIWN based on seven main steps:
Nonce generation.
Redirection to the IDK Kit wallet user interface.
Connect to your Near wallet.
A popup appears for signing the message. It is based on multiple factors like the nonce generated by the IDP Kit, account address, etc.
Click the “Sign” button.
Redirection to the IDK Kit verification service.
The IDP Kit verifies the message signature based on the account address.
The message will be in the form of:
{domain} wants you to sign in with your Near account: {address}. Public Key: {publicKey}.Date: {ISO8601formatedTimestamp}. {description} URI: {origin}. Version: {versionNumber}. Nonce: {nonce}
domain: is the RFC 3986 authority that is requesting the signing.
Permissions.address: account address.
Public Key : account public key.
Date: is the ISO 8601 datetime string of the current time.
Nonce:security parameter generated by the IDP Kit.
This documentation section will dive deep into implementing the Sign-in with Polkadot(SIWP). For more details about the concept Sign in With X (SIWx), CAIP-122.
Sign-In with Polkadot Blockchain describes how polkadot accounts authenticate with off-chain services by signing a message parameterized by scope, nonce, etc. It is an alternative to centralized identity providers. It is based on the self-custody of your identity. It leverages the on-chain authentication model to off-chain services.
The reason behind implementing the concept Sign-In with Polkadot is that it is a critical step in the Login with NFTs concept. Before granting access to some services based on the ownership of some NFTs, we need to check two main aspects:
You own an account via Sign with Polkadot.
Verify that the account has an NFT in a specified collection.
An account in Polkadot is linked to the ownership of a private key which is then mapped to his public key. The hash of the public key outputs an address.
The IDP Kit implements SIWP based on seven main steps:
Nonce generation.
Redirection to the IDK Kit wallet user interface.
Connect to your polkadot wallet.
A popup appears for signing the message. It is based on multiple factors like the nonce generated by the IDP Kit, account address, etc.
Click the “Sign” button.
Redirection to the IDK Kit verification service.
The IDP Kit verifies the message signature based on the account address.
The message will be in the form of:
{domain} wants you to sign in with your Polkadot account: {address}. Public Key: {publicKey}.Date: {ISO8601formatedTimestamp}. {description} URI: {origin}. Version: {versionNumber}. Nonce: {nonce}
domain: is the RFC 3986 authority that is requesting the signing.
Permissions.address: account address.
Public Key : account public key.
Date: is the ISO 8601 datetime string of the current time.
Nonce: security parameter generated by the IDP Kit.
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
The IDP Kit transforms the ownership of NFT on Polkadot into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWF, NFT, and their metadata.
Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Flow Blockchain. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
The whole verification process has seven main steps:
The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.
The IDP Kit processes the verification request. If it is an NFT Flow verification, the IDP Kit redirects the user to his user interface.
Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWF process.
The SIWF process continues within the IDP Kit by verifying the user address and the message signature.
After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Flow Blockchain. The NFT collection information is defined in the IDP Kit configuration file.
If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.
In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.
The authorization flow visualized
OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.
SIWF is used to verify that the user controls and owns the private key of a Flow account.
We can apply policies to the NFT metadata based on the Open policy agent(OPA).
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
The IDP Kit transforms the ownership of NFT on Polkadot into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWP, NFT, and their metadata.
Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Polkadot Blockchain. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of .
The whole verification process has seven main steps:
The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.
The IDP Kit processes the verification request. If it is an NFT Polkadot verification, the IDP Kit redirects the user to his user interface.
Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWP process.
The SIWP process continues within the IDP Kit by verifying the user address and the message signature.
After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Polkadot Blockchain. The NFT collection information is defined in the IDP Kit configuration file.
If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.
In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.
The authorization flow visualized
OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.
SIWP is used to verify that the user controls and owns the private key of a Polkadot account.
We can apply policies to the NFT metadata based on the Open policy agent(OPA).
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
Derived from nft_mappings defined in the IDP Kit , based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit
This documentation section will dive deep into implementing the Sign-in with Flow(SIWF). For more details about the concept Sign in With X (SIWx), CAIP-122.
Sign-In with Flow Blockchain describes how flow accounts authenticate with off-chain services by signing a message parameterized by scope, nonce, etc. It is an alternative to centralized identity providers. It is based on the self-custody of your identity. It leverages the on-chain authentication model to off-chain services.
The reason behind implementing the concept Sign-In with Flow is that it is a critical step in the Login with NFTs concept. Before granting access to some services based on the ownership of some NFTs, we need to check two main aspects:
You own an account via Sign with Flow.
Verify that the account has an NFT in a specified collection.
An account in Flow is linked to the ownership of a private key which is then mapped to his public key. The hash of the public key outputs an address.
The IDP Kit implements SIWF based on seven main steps:
Nonce generation.
Redirection to the IDK Kit wallet user interface.
Connect to your flow wallet.
A popup appears for signing the message. It is based on multiple factors like the nonce generated by the IDP Kit, account address, etc.
Click the “Sign” button.
Redirection to the IDK Kit verification service.
The IDP Kit verifies the message signature based on the account address.
The message will be in the form of:
{domain} wants you to sign in with your Flow account: {address}. Public Key: {publicKey}.Date: {ISO8601formatedTimestamp}. {description} URI: {origin}. Version: {versionNumber}. Nonce: {nonce}
domain: is the RFC 3986 authority that is requesting the signing.
Permissions.address: account address.
Public Key : account public key.
Date: is the ISO 8601 datetime string of the current time.
Nonce: security parameter generated by the IDP Kit.
This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.
The IDP Kit transforms the ownership of NFT on Polkadot into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWA, NFT, and their metadata.
Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Algorand Blockchain. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).
To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.
The whole verification process has seven main steps:
The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.
The IDP Kit processes the verification request. If it is an NFT Flow verification, the IDP Kit redirects the user to his user interface.
Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWA process.
The SIWA process continues within the IDP Kit by verifying the user address and the message signature.
After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Algorand Blockchain. The NFT collection information is defined in the IDP Kit configuration file.
If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.
In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.
The authorization flow visualized
OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.
SIWA is used to verify that the user controls and owns the private key of an Algorand account.
We can apply policies to the NFT metadata based on the Open policy agent(OPA).
In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.
By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:
nft_token claim, specified by the client application as a custom claim object in the authorization request
Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request
NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration
The nft_token claim should be constructed as follows:
Authorization POST request:
When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:
Authorization GET request:
When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.
In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.
The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.
Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.
To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.
This documentation section will dive deep into implementing the Sign-in with Algorand(SIWA). For more details about the concept Sign in With X (SIWx), CAIP-122.
Sign-In with Algorand Blockchain describes how Algorand accounts authenticate with off-chain services by signing a message parameterized by scope, nonce, etc. It is an alternative to centralized identity providers. It is based on the self-custody of your identity. It leverages the on-chain authentication model to off-chain services.
The reason behind implementing the concept Sign-In with Algorand is that it is a critical step in the Login with NFTs concept. Before granting access to some services based on the ownership of some NFTs, we need to check two main aspects:
You own an account via Sign with Algorand.
Verify that the account has an NFT in a specified collection.
An account in Algorand is linked to the ownership of a private key which is then mapped to his public key. The hash of the public key outputs an address.
The IDP Kit implements SIWA based on seven main steps:
Nonce generation.
Redirection to the IDK Kit wallet user interface.
Connect to your Algorand wallet.
A popup appears for signing the message. It is based on multiple factors like the nonce generated by the IDP Kit, account address, etc.
Click the “Sign” button.
Redirection to the IDK Kit verification service.
The IDP Kit verifies the message signature based on the account address.
The message will be in the form of:
{domain} wants you to sign in with your Algorand account: {address}. Public Key: {publicKey}.Date: {ISO8601formatedTimestamp}. {description} URI: {origin}. Version: {versionNumber}. Nonce: {nonce}
domain: is the RFC 3986 authority that is requesting the signing.
Permissions.address: account address.
Public Key : account public key.
Date: is the ISO 8601 datetime string of the current time.
Nonce: security parameter generated by the IDP Kit.
