Application types and how to choose
This page is the decision hub for ChainIT integrations. Use it after you can sign in to the Developer Portal and before you lock in an application configuration. It explains how M2M, IDP, and Hosted UI differ, how they map to OAuth/OIDC concepts, and which portal fields apply—so a human or an automated assistant can pick the correct path without mixing flows.
How ChainIT surfaces “Login with ChainIT”
IDP and Hosted UI both authenticate end users with ChainIT. The difference is who builds the interactive UI and how deep the verification goes:
| Capability | IDP | Hosted UI |
|---|---|---|
| User signs in with ChainIT (OIDC-style flows) | Yes | Yes |
| You implement buttons, redirects, and session handling | Yes | Partially (SDK drives hosted screens) |
| ChainIT provides a managed branded UI for OTP, liveness, ID scan, terms | No | Yes |
| Typical fit | “Login with ChainIT” in your SPA/mobile app where you control layout | Regulated onboarding / KYC-heavy journeys with minimal custom UI |
M2M is not a user login path. It is client credentials for your servers calling ChainIT APIs. If you need both user login and backend jobs, you usually create two applications (for example one IDP or Hosted UI app for users, and one M2M app for batch work).
Quick comparison
| Dimension | M2M | IDP | Hosted UI |
|---|---|---|---|
| Primary actor | Your backend service | End user in a browser or app | End user in hosted UI |
| OAuth grant | Client credentials | Authorization code + PKCE (required) | Session + SDK; tokens via SDK callbacks |
clientSecret | Always on server | Confidential clients: server; public clients (SPA/native): often no secret on device | Always on server for client-session; never in the browser |
| Typical output | access_token (API scopes) | access_token, id_token, optional refresh_token | Same token family via SDK success callback |
| UserInfo API | Not applicable (no user sub) | Yes, with user access_token | Yes, with user access_token |
| Integration doc | M2M | IDP | Hosted UI |
High-level architecture
Decision: what are you building?
Property support matrix (Developer Portal)
Different application types expose different registration fields.
| Property | M2M | IDP | Hosted UI | Meaning |
|---|---|---|---|---|
callbackURL | No | Yes | No | OAuth redirect URIs after authorization. |
originURL | No | Optional | Optional | Allowed browser origins (CORS) for pages that host the integration * is not supported. See the origin whitelisting guide. |
scopes | Yes | Yes | No | Requested permissions (FILE_UPLOAD, openid, etc.). |
branding | No | No | Yes | Logos and colors for hosted UI. |
tokenManagement | No | Yes | Yes | Token lifetime / refresh configuration where supported. |
clientSecret | Yes | Yes* | Yes | Server-side secret; never ship to untrusted clients. |
*Public IDP clients (many SPAs and mobile apps) use PKCE without embedding a clientSecret in the app; confidential servers still use a secret for token exchange.
M2M (machine-to-machine)
When to choose it: Your service calls ChainIT REST APIs (file upload, minting, KYB, and similar) and no interactive user login is part of that credential.
Flow: Your server sends client_id / client_secret (or HTTP Basic) to the token endpoint and receives an access_token scoped for APIs.
Not for: Building a “Login” button for people. Use IDP or Hosted UI instead.
IDP (Identity Provider) — “Login with ChainIT”
When to choose it: You want the same end-user pattern as “Login with Google”—a “Login with ChainIT” button—implemented with standard OAuth 2.0 / OIDC authorization code + PKCE. You control the UX around the flow: your buttons, your routing, your session store. The user is redirected to ChainIT to authenticate and consent, then returns to your redirect URI with an authorization code.
Flow: Browser or app opens ChainIT authorize URL with PKCE challenge → user authenticates → redirect back with code → your backend or secure component exchanges the code for tokens.
Critical rule: PKCE with S256 is mandatory for public clients.
Hosted UI
When to choose it: You need a guided, compliant onboarding path (OTP, terms, face liveness, ID document capture) with ChainIT-hosted screens, while still matching your brand. Your frontend loads the SDK; your backend creates short-lived client sessions so the secret never lives in the browser.
Flow: Backend POST client-session → frontend initializes SDK with session payload → user completes hosted steps → SDK onSuccess with tokens.
URL whitelist: Register all allowed web origins in URL White Listing (CORS) for Hosted UI (see the origin whitelisting guide for rules). * is not allowed. Callback URLs are not used for this type.
Read the full Hosted UI guide →
After you choose a type
- In the Developer Portal, create an application of that type and fill only the fields your type uses (see matrix above).
- Copy
clientIdandclientSecretonce; store them in a secrets manager or environment variables. - Open the application guide (M2M, IDP, or Hosted UI) and implement that flow end to end—including token validation and least-privilege scopes.
- Review token validation and security best practices.
Treat each application type as a separate OAuth topology. Do not reuse M2M tokens in a browser, do not call UserInfo with M2M tokens, and do not skip PKCE on public IDP clients. When in doubt, re-read the guide for the type you selected—not a generic “integration” template.
Next steps
After you create an application in the portal, follow the guide for that type end to end—including token validation and least-privilege scopes.