​
This is an enterprise-only feature. Please contact us in slack or via email ([email protected]) to enable.

​
Introduction

If you have built your own authentication system or use other auth providers outside Dynamic, you can continue to use those services while taking advantage of Dynamic’s product to enable web3-based functionality and interactions. You do this by exchanging your token from a JWT issuer to “sign-in” or “link” to Dynamic. This will return Dynamic’s standard sign-in artifacts (ie, minified JWT and user). At a high level, the process will involve the following:
  1. Verify the authenticity of the JWT by getting the public key from a JWKS endpoint provided by you, and using this public key to verify the JWT.
  2. Require you to provide exact value for either the iss (issuer) JWT claim. If the value of this field deviates from that is provided in the project environment’s configuration, we will reject the JWT.
  3. Dynamic will also require the sub (subject, or user ID) field be provided. These will correspond to the your user ID. These will be mapped to the similar user model in Dynamic.
  4. Dynamic will also require exp (expires at) JWT claim from external JWT. Dynamic will ensure that this exp claim is respected with timeouts on the SDK.
  5. Once signed in using this external JWT, we will create an new verified credential of type externalAuth, letting us know that the user has an external authentication mechanism they used to verify their account. This should have externalUserId with the value of the JWT’s sub.
  6. Optional verified credential data, such as e-mail sign in can be provided as part of the JWT. This would allow Dynamic to create an email verified credential tied to the Dynamic user on our side.

​
Workflow

Swimlanes