Xaman Developer Docs
Developer ConsoleAPI Endpoints
  • Build on Xaman
  • Concepts
    • Getting started
      • Terminology
      • Developer Education
    • 🔐Authorization & Credentials
    • Payloads (sign requests)
      • 🚨Secure Payment Verification
      • Workflow
      • Lifecycle
        • Sample POS lifecycle
      • Payload Delivery
        • Deep Linking
        • QR Scanning
        • Push
        • xApps
        • Mobile (iOS/Android)
        • Desktop browser
      • Status updates
        • Websocket
        • Webhooks
          • Signature verification
        • API Call (polling)
      • Networks
      • Payload Return URL
      • Tx Explorer(s)
    • Special Transaction Types
    • Limitations
      • Rate limits
      • Transaction types
      • Push permission
    • Implementation checklist
      • Protocol specific checks
  • Environments
    • 🌎Browser ("Web3")
      • CORS (Browser)
    • 📱xApps ("dApps")
      • Requirements
      • Develop & Test
      • CORS (xApp)
      • Xumm UI interaction
      • Your own backend (Auth)
      • Style guide
      • Development & Debugging
      • xAppBuilder 🏗️
        • Connecting localhost to xAppBuilder
        • xAppBuilder FAQ
    • 📂Backend (SDK / API)
      • User identification payloads
    • 🎛️Native Apps
    • 🙇Identity (OAuth2, OpenID)
      • Test Tools
  • JS/TS SDK
    • Xaman SDK (Intro)
    • Examples / User stories
      • Sign Requests (payloads)
        • Browser
        • xApp
        • Backend
      • Verify Payload signature
      • Simple Sign Request
    • 📦SDK (syntax)
      • Xumm.ping()
      • Xumm.on(event, fn)
      • Xumm.off(event, fn)
      • Xumm.helpers { … }
        • ping()
        • getRates( … )
        • getRails()
        • getHookHash( … )
        • getHookHashes()
        • getCuratedAssets()
        • getNftokenDetail( … )
        • getKycStatus( … )
        • verifyUserTokens([ … ])
        • getTransaction( … )
      • Xumm.user { … }
      • Xumm.environment { … }
      • Xumm.payload { … }
        • create( … )
        • createAndSubscribe( … )
        • cancel( … )
        • subscribe( … )
        • get( … )
      • Xumm.xapp { … }
        • ready()
        • openSignRequest({ … })
        • selectDestination({ … })
        • scanQr()
        • tx({ … })
        • close({ … })
        • share({ … })
        • navigate({ … })
        • openBrowser({ … })
        • on(xAppEvent, fn)
        • off(xAppEvent, fn)
      • Xumm.userstore { … }
        • list()
        • get( … )
        • delete( … )
        • set( … , { … } )
      • Xumm.backendstore { … }
        • get()
        • set({ … })
        • delete()
      • Xumm.push { … }
        • event( … )
        • notification( … )
      • Xumm.runtime { … }
      • Xumm.authorize()
      • Xumm.logout()
Powered by GitBook
On this page
  • Authorization
  • Backend
  • Frontend (browser, client side)
  • xApp
  • Native application
  • Credentials

Was this helpful?

Edit on GitHub
Export as PDF
  1. Concepts

Authorization & Credentials

How to authorize when communicating with the Xumm platform depends on your workflow.

PreviousDeveloper EducationNextPayloads (sign requests)

Last updated 1 year ago

Was this helpful?

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 , and are to be passed in the x-api-key and x-api-secret headers to our platform.

Frontend (browser, client side)

Browser ("Web3") can use our , 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 ("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 , 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. 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 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

✅ Yes

✅ Yes

User identified with credentials?

✅ Yes

✅ Yes

Usable in backend environments?

✅ Yes

Yes (but frontend obtained)

Yes (but frontend (xApp) obtained)

Usable in frontend (browser) environments?

✅ Yes

✅ No

CORS ready?

Yes (JWT endpoints, SDK handles this for you)

Yes (JWT endpoints, SDK handles this for you)

Usable in native app environments?

Yes (but OAuth2 sign in flow required)

Credential validity & authenticity can be offline verified?

Obtained from the

After the user signs their first by you through deeplink / QR with a then obtained "User Token"

No, (Sign Request) required first.

No

No

No

No

No

Yes, the JWT: using the OAuth2 (RS256).

Yes, the JWT (HS256):

🔐
Developer Dashboard
Frontend (browser, client side) implementations
Javascript/Typescript SDK
xApps
Javascript/Typescript SDK
Your application
Your own backend (Auth)
Xumm Developer Dashboard
Sign Request
"SignIn" payload
❌
❌
❌
❌
❌
certs information