Skip to content

SSO/OIDC Deep Dive

This page documents detailed OIDC behavior and post-login user identity handling.

Flow Boundaries

Identity vs API access

The OIDC flow authenticates a user identity.

REST API access still requires service authentication and API headers.

OIDC Authorize Endpoint

https://prod.personifyauth.com/connect/authorize

OIDC Parameter Details

Required for robust implementation

  • redirect_uri: must be pre-registered/whitelisted
  • scope: must include openid; include profile to receive email-related identity claims
  • state: round-trip app context (event/session correlation)
  • nonce: token replay protection
  • prompt=login: force explicit login prompt behavior when required
  • code_challenge + code_challenge_method=S256: PKCE support

Optional

  • tenantId: pass tenant branding GUID when provided so IdP can apply client branding if a login form is shown

Why Use a Generic redirect_uri

Use one stable callback URL across all events whenever possible.

Avoid event-specific redirect URIs by default

If your redirect_uri changes per event, each new event URL must be separately whitelisted in the IdP. This creates repeated operational work and can block login until updates are approved.

Recommended pattern:

  • Keep a single whitelisted callback URL (for example, https://partner.example.com/auth/callback).
  • Pass event-specific context in the state parameter.
  • On callback, parse state and route the user to the correct event context in your app.

This approach reduces onboarding friction and avoids per-event whitelist requests.

UserInfo Call for Claims

You can retrieve user identity claims using:

  • Claims from decoded id_token
  • UserInfo endpoint with bearer access_token

UserInfo endpoint:

https://prod.personifyauth.com/connect/userinfo

Example request:

curl --request GET 'https://prod.personifyauth.com/connect/userinfo' \
  --header 'Authorization: Bearer <oidc_access_token>'

Token Validation Inputs

Your token validation implementation should use onboarding-provided values:

  • Public signing key (YOUR_IDP_PUBLIC_KEY)
  • Issuer (YOUR_ISSUER)
  • Audience (YOUR_AUDIENCE)

Documented audience patterns include distinct values depending on token type.

Exhibitor Lookup Flow After Login

After user login and email claim retrieval:

  1. Extract user email from claims (profile scope required).
  2. Obtain API token using REST API auth flow (client_credentials).
  3. Call exhibitor lookup endpoint: GET /api/v1/exhibitor/event/{eventId}/contactEmail/{contactEmail}
  4. If multiple exhibitors are returned for the same user email, prompt user to choose.

Important context

The Event Portal link into the partner application does not include which exhibitor context was selected. The partner must resolve exhibitor context after SSO using the user email and event ID.

Reference implementation examples:

Multi-Exhibitor Selection After Lookup

A single user can be associated with multiple exhibitors.

If the lookup returns multiple exhibitors for the same user email, you may want to provide the user a way to choose which exhibitor context to continue with.

Do not reuse OIDC assumptions for REST authorization

User login success does not remove the need for API bearer token and X-Tenant-Id.