Skip to Content
DocsEnterprise CapabilitiesUse CasesCompliance & Enterprise OpsSign-In with KryptoGO

Sign In with KryptoGO

Let your users sign in to your application with their KryptoGO account — and, if you choose, surface their default wallet address, NFT holdings, and token balances inside your product. A framework-agnostic OAuth 2.0 SDK is published for web; mobile integrations use the same OAuth 2.0 protocol or, where you also embed a wallet, the Mobile Wallet SDK’s partner-JWT auth flow.

Who this is for

PersonaTypical inbound
Partner application or ecosystem app”We want our users to sign in with their KryptoGO Wallet account instead of building our own.”
Web3 product”We want one-click access to a user’s NFTs and tokens for portfolio display.”
Loyalty or rewards app”We want to identify a user across our properties using their KryptoGO identity.”
Internal application”We need to integrate KryptoGO accounts on a new property.”

Not a fit if you require non-OAuth federation such as SAML or an OIDC discovery document (we ship OAuth2 only today), need to self-host the identity provider (the OAuth provider is hosted by KryptoGO), or need custom claims beyond the documented user-info shape (the claim set is fixed today).

What you can ship today

SurfaceWhat it is
Hosted OAuth providerA KryptoGO-hosted accounts page handles authentication. Email and one-time password, phone and one-time password, and Google sign-in are supported.
Web SDK (@kryptogo/auth)A framework-agnostic JavaScript SDK for browser-side integration. Supports popup and inline iframe transports. Published on the public package registry.
Mobile integrationNative iOS and Android apps integrate against the same OAuth 2.0 provider using standard OAuth client patterns. Where you are also embedding a KryptoGO wallet inside your mobile app, the Mobile Wallet SDK’s partner-JWT custom-auth flow is the more direct path — see White-Label Wallet.
OAuth client provisioningCreate and manage OAuth client credentials inside the Studio console.

After a user signs in, your application receives an access token plus a documented user-info shape: a stable user identifier, email or phone number (whichever the user authenticated with), and display name. Optional methods on the SDK also expose the user’s default wallet address per chain, paginated NFT holdings, and token balances.

How it works

1. Your application initialises the SDK with your OAuth client ID,
   provisioned from Studio.

2. The user clicks Sign in with KryptoGO. The SDK opens the KryptoGO
   accounts page in a popup, or inline as an iframe if you prefer.

3. The user authenticates with email and one-time password, phone
   and one-time password, or Google sign-in.

4. The accounts page posts the access token back to your application
   over a secured channel. The SDK fires an onConnect callback and
   stores the token.

5. Your application calls the SDK to retrieve the user's identifier,
   wallet address, NFT holdings, or token balances as needed.

6. The SDK refreshes the access token automatically when your
   application requests one and the current token is near expiry.

7. On sign-out, your application calls the SDK's logout method,
   which clears the local session state.

Supported chains for wallet-address lookup

Ethereum, BNB Smart Chain, Polygon, Arbitrum, Bitcoin, KuCoin Community Chain, Solana, and Tron are supported as chain identifiers when fetching the user’s default receive address.

Onboarding the OAuth client

  1. Your organisation must be a Studio organisation first — see Team, roles, API keys, and risk limits for organisation provisioning.
  2. An admin opens the OAuth Clients section inside Studio and creates a client.
  3. The platform issues a client identifier and, optionally, a client secret.
  4. Your application uses the client identifier to initialise the SDK.

Custody model

Sign In with KryptoGO authenticates a user. The wallet address surfaced via the SDK belongs to the user’s KryptoGO Wallet — which uses the embedded self-custody model with Shamir’s-Secret-Sharing across the user device, KryptoGO cloud, and a third party of the user’s choice. Your application reads the address; you do not custody the user’s keys. See Custody Options for the full custody model.

Compliance posture

The OAuth provider runs inside the same regulated platform — Taiwan VASP, ISO 27001, ISO 27701, SOC 2 Type II, Cure53 audit. Tokens are short-lived with automatic refresh. The accounts page is the trust anchor for the user-authentication popup, so origin verification is enforced against it. See Compliance and Certifications for the full posture.

Typical integration timeline

PathBucket
Web integration with the framework-agnostic SDKUnder one month — typically a few days for a frontend team
Mobile integration against the OAuth 2.0 provider on iOS or AndroidUnder one month — typically one to two weeks per platform
Custom transport (inline iframe instead of popup, custom locale, white-label branding)One to two months — depends on the depth of customisation

Current scope

  • The OAuth provider, the framework-agnostic web SDK, and OAuth client provisioning inside Studio are in production.
  • The framework-agnostic web SDK is available immediately on the public package registry and works inside any React, Vue, Angular, or vanilla-JavaScript codebase. A React-first wrapper is available on partnership request.
  • Mobile-native OAuth integration uses standard OAuth 2.0 client patterns; we will share sample code during partnership scoping.
  • SAML and OIDC discovery support is on the roadmap; OAuth 2.0 is the only federation flow today.
  • Custom branding for the hosted accounts page is available case-by-case for partners; contact us to scope.

Talk to us

If you want to add Sign in with KryptoGO to your product, reach our partnerships team via the address on www.kryptogo.tw .

Where to go next

Last updated on
Team, Roles, API Keys & Risk LimitsCustomer Data Platform