Federated Keyless Key Considerations

Supported IAMs

Currently, the three supported IAMs are Amazon Cognito, Auth0, and Okta across devnet, testnet, and mainnet. See a table of the full set of supported IAM providers here.

Federated Keyless flow

The flow for Federated Keyless transactions is the same as described here. However, the difference is that in Federated Keyless, instead of the OIDC provider (e.g. Google, Apple) acting as the issuer of the JWT, the IAM provider (e.g. Auth0, Cognito) acts as the issuer. The user authenticates with the application, the IAM receives the user’s credentials, and then the IAM issues the Keyless-compatible JWT.

Available authentication methods

All authentication methods that are supported by the IAM providers are available for use - this includes SMS OTP, email link, and the traditional username + password.

Configuration limitations

A Keyless account address varies according to the aud (AKA application ID or client ID), and iss (AKA issuer). The setup of your user data within the IAM must reflect the interoperability you seek to provide to your users. JWT tokens issued for a user in the same user pool but for different applications will result in a different address derivation if the aud value is different.

The trust and security model for Federated Keyless

Compared to the existing Keyless implementation, dApp developers utilizing Federated Keyless alongside certain authentication methods like email/SMS, OTP and email/password may have more access to user credentials when leveraging IAM providers than with the existing direct OIDC provider integrations.

We recommend each dApp developer perform their own research and consult with their legal counsel before integrating an authentication method. Developers should also understand to what extent they may have access to user credentials and what controls they have in place.