🔐Authorization & Credentials
How to authorize when communicating with the Xumm platform depends on your workflow.
Authorization
Backend
When communicating with the Xumm platform from your backend environment, you will need a API Key and API Secret. They can be obtained from our Developer Dashboard, and are to be passed in the x-api-key and x-api-secret headers to our platform.
Frontend (browser, client side)
Frontend (browser, client side) implementations Browser ("Web3") can use our Javascript/Typescript SDK, in which case the entire authorization is abstracted away. Under the hood, the user will go through an OAuth2-flow and a JWT (JSON Web Token) is obtained from our platform. This token is valid for 24 hours and user context bound.
If you are building your own frontend implementation, any OAuth2 (Implicit and PKCE flows both supported) client will do. See Identity (OAuth2, OpenID)
Never use an API Secret obtained from the Developer Dashboard in a frontend environment! Anyone in possession of your API Secret (x-api-secret) can create payloads (Sign Requests) on behalf of your application. If abused, this can immensely damage the reputation of your application.
xApp
xApps xApps ("dApps") are loaded with several URL Query Paramters added, one of which is the xAppToken parameter. This parameter contains what we refer to as the "OTT", the "One Time Token". This token can be resolved by your application to a JSON response containing:
user context information
a JWT, JSON Web Token, allowing you to make subsequent calls to our platform
If you use our Javascript/Typescript SDK, this entire authorization flow is abstracted away by our SDK; the SDK (in the xApp, client side) will automatically resolve the xApp Token ("OTT") and use the JWT to make subsequent calls to our platform.
Native application
Any OAuth2 (Implicit and PKCE flows both supported) client will do. Your application Native Apps can redirect the user to our platform (to be redirected to the Xumm app) to sign in after which the client will be redirected back to your application (if your application supports deep links). You will obtain a JWT (JSON Web Token) to communicate to our platform from the user context. See:Identity (OAuth2, OpenID)
Credentials
| Backend | PKCE / JWT | xApps | |
|---|---|---|---|
Also known as | "Server side" | "Sign in with Xumm" | "dApps", "web apps" embedded in Xumm |
Credentials | API Key & Secret | JWT (SDK handles this for you) | JWT (SDK handles this for you) |
Credential source | Obtained from the Xumm Developer Dashboard | Obtained after end user logs in (SDK does this for you) | Automatically obtained through a "One Time Token" (SDK does this for you) |
Can send sign request push notifications | After the user signs their first Sign Request by you through deeplink / QR with a then obtained "User Token" | ✅ Yes | ✅ Yes |
User identified with credentials? | No, "SignIn" payload (Sign Request) required first. | ✅ Yes | ✅ Yes |
Usable in backend environments? | ✅ Yes | Yes (but frontend obtained) | Yes (but frontend (xApp) obtained) |
Usable in frontend (browser) environments? | ❌ No | ✅ Yes | ✅ No |
CORS ready? | ❌ No | Yes (JWT endpoints, SDK handles this for you) | Yes (JWT endpoints, SDK handles this for you) |
Usable in native app environments? | ❌ No | Yes (but OAuth2 sign in flow required) | ❌ No |
Credential validity & authenticity can be offline verified? | ❌ No | Yes, the JWT: using the OAuth2 certs information (RS256). | Yes, the JWT (HS256):Your own backend (Auth) |
Last updated