Understanding the SDK Usage

Code walkthrough explaining SDK initialization, authentication flow, callback handling, user data retrieval, and error handling in the newsletter app.

This guide explains how the Humanity Protocol Connect SDK is used throughout the newsletter app to handle authentication and user data extraction.

SDK Initialization

The SDK is initialized once and exported as a singleton in src/lib/humanity-sdk.ts:

import { HumanitySDK } from '@humanity-org/connect-sdk'
import { getConfig } from './config'

let sdkInstance: HumanitySDK | null = null

export function getHumanitySdk(): HumanitySDK {
  if (sdkInstance) {
    return sdkInstance
  }

  const config = getConfig()

  sdkInstance = new HumanitySDK({
    clientId: config.humanity.clientId,
    redirectUri: config.humanity.redirectUri,
    environment: config.humanity.environment,
    clientSecret: config.humanity.clientSecret,
  })

  return sdkInstance
}

Key Configuration Parameters:

  • clientId - Your app's OAuth client ID (required)

  • redirectUri - Where users are redirected after authorization (required)

  • environment - Either 'sandbox' or 'production'

  • clientSecret - Required for server-side token exchange

The OAuth Flow

Step 1: Building the Authorization URL

File: src/app/api/auth/login/route.ts

When a user clicks "Sign in with Humanity Protocol", the app calls the /api/auth/login endpoint which builds an authorization URL using the SDK:

What the SDK Returns:

  • url - The full authorization URL to redirect the user to

  • codeVerifier - PKCE parameter that must be stored and used during token exchange

Important: The codeVerifier must be stored securely (in session cookie) because it's required in the next step to exchange the authorization code for tokens.

Step 2: Handling the OAuth Callback

File: src/app/callback/route.ts

After the user authorizes, Humanity Protocol redirects them back to /callback with an authorization code. The app exchanges this code for access tokens:

What the SDK Returns:

  • accessToken - Bearer token for calling Humanity Protocol APIs (short-lived)

  • refreshToken - Token for obtaining new access tokens (long-lived)

  • idToken - JWT containing basic identity claims

Step 3: Extracting User Data with the SDK

File: src/lib/auth-service.ts

Once we have an access token, we use the SDK to fetch the user's email and verify their presets:

SDK Methods Used:

  1. sdk.verifyPreset({ preset: 'email', accessToken })

    • Returns single preset verification

    • The email preset returns the user's verified email as value

    • Additional data available in evidence object (wallet address, humanity ID)

  2. sdk.verifyPresets({ accessToken, presets })

    • Batch verification of multiple presets

    • Returns array of { presetName, value } objects

    • Used to detect which social accounts are connected

Step 4: Using the Query Engine for Complex Conditions

File: src/lib/auth-service.ts

The SDK also provides a Query Engine for complex predicate queries:

Example Query for Hotel Membership:

SDK Method:

  • sdk.evaluatePredicateQuery({ accessToken, query })

    • Evaluates complex conditional logic against user's credentials

    • Returns { passed: boolean } indicating if conditions are met

    • Used for sophisticated eligibility checks

Key Files Where SDK is Used

File
Purpose
SDK Methods Used

src/lib/humanity-sdk.ts

SDK singleton initialization

new HumanitySDK(), getHumanitySdk()

src/app/api/auth/login/route.ts

Build authorization URL

sdk.buildAuthUrl(), HumanitySDK.generateState()

src/app/callback/route.ts

Exchange code for tokens

sdk.exchangeCodeForToken(), HumanitySDK.verifyState()

src/lib/auth-service.ts

Extract user data, verify presets

sdk.verifyPreset(), sdk.verifyPresets()

src/lib/auth-service.ts

Check travel preferences

sdk.evaluatePredicateQuery()

Data Flow Summary

Important Security Notes

  1. Never expose clientSecret to the frontend - it's only used in server-side API routes

  2. Always store codeVerifier securely - required for PKCE token exchange

  3. Validate state parameter - prevents CSRF attacks

  4. Use HTTP-only cookies - prevents XSS access to session tokens

  5. Verify all tokens - never trust client-provided data

Last updated