Seamless SSO from SAP CDC to QUP Redemption

Introduction

This guide shows exactly what to implement so users who are already logged in to SAP Customer Data Cloud (CDC) inside your mobile app can open the QUP redemption web experience (webframe or external browser) without logging in again.

The important detail: QUP uses AWS Cognito as the authentication front door and federates to SAP CDC via OpenID Connect (OIDC).

Staying logged in

A “no re-login” experience is possible when the browser context that opens QUP can access the same CDC SSO session.

That is typically true when you use:

• iOS: ASWebAuthenticationSession (best) or SFSafariViewController
• Android: Chrome Custom Tabs

It is often not true when you use:

• iOS WKWebView / Android WebView (cookie jars are usually isolated)

❗️

If you must use an isolated WebView, please refer to the regular Integration and Authorization guide.

What you will receive from QUP

During onboarding, QUP provides:

• Redemption launch URL (per environment)
• Allowed return URL(s) (deep link/app link or web)
• Any required identifiers (e.g., campaign/promotion code)

📘

You do not need to configure Cognito or CDC. QUP owns the Cognito ↔ CDC federation.

Integration steps

End-to-end flow (for reference)

sequenceDiagram
  autonumber
  participant App as Your Mobile App
  participant B as System Browser / OS Auth Session
  participant Q as QUP Redemption Web
  participant C as QUP Auth (Cognito)
  participant I as SAP CDC

  App->>B: Open QUP redemption URL
  B->>Q: Load redemption page
  Q->>C: Redirect to Cognito /authorize (if no QUP session)
  C->>I: Federate to CDC (OIDC)
  I-->>C: Silent SSO if CDC session exists
  C-->>Q: Redirect back QUP session established
  Q-->>B: User redeems points
  Q-->>App: Redirect to return URL (success/cancel)

Step 1 — Make sure your app loging uses a sharable SSO context

If your app currently logs the user into CDC using a native SDK only, you may not have a browser SSO session that QUP can reuse. To maximize “no re-login” success:

• Perform CDC login in a system-auth browser context (ASWebAuthenticationSession / Custom Tabs), or
• Ensure your CDC setup establishes an SSO session that is visible to those contexts.

If you don’t control how CDC login is done in your app, still follow Step 2–4; QUP will fall back to login if needed.

Step 2 — Construct the QUP redemption URL

Your app opens a single QUP URL that includes the context QUP needs.

Typical parameters:

• campaign (which promotion)
• partner_user_id (your internal user id)
• return_url (deep link / app link back into your app)
• state (random string; used to correlate launch ↔ return)

Example (illustrative):

https://<qup-redemption>/start?campaign=ABC123&partner_user_id=U-99881&return_url=myapp://qup/return&state=<random>

QUP will confirm the exact parameter names.

Step 3 — Launch redemption in the recommended way (no re-login)

iOS

Use ASWebAuthenticationSession (recommended). This shares the right cookie context for SSO.

If you cannot, use SFSafariViewController as a fallback.

Android

Use Chrome Custom Tabs.

Why this matters

When QUP redirects through Cognito to CDC, CDC can only do silent SSO if it can see the existing CDC session cookies.

Step 4 — Handle the return to your app

When the user finishes redemption (or cancels), QUP redirects to your return_url.

You should handle:

• status (e.g., success, cancel, error)
• a reference like redemption_id or order_id
• state (must match what you sent)

Suggested handling:

• Verify state matches your original value
• Show confirmation UI (or return user to the right screen)
• Store the redemption_id for support/troubleshooting

---

Mix & match: Web redemption + user-scoped API access

QUP supports mixed integration models.

A common setup is to:

• use the QUP redemption web experience (via seamless SSO), and
• access user-specific data (such as tickets or entitlements) via headless API calls in your own application.

In this model, redemption and API access are separate but complementary.

User-scoped access using a public bearer

User-specific endpoints (such as /me, tickets, or fulfillment data) must be called using a public bearer.

A public bearer:

• represents an authenticated end user
• is scoped to /me-level resources
• must not be replaced by an admin or client-credentials token

Admin (client credentials) tokens are only suitable for partner-level or administrative operations.

Token exchange responsibility

Partners do not exchange SAP CDC or Cognito tokens themselves.

When the QUP redemption web experience is used:

• the user authenticates via Cognito (federated to SAP CDC)
• QUP performs all required token exchanges inside the webframe
• QUP establishes a user session and issues a public bearer

There is no public API for exchanging Cognito or CDC tokens directly, and this is by design.

Obtaining a public bearer for /me API calls

If your integration combines web redemption with headless API access, the public bearer used for /me endpoints is obtained via QUP’s authorization mechanisms, not via Cognito directly.

Depending on your setup:

• The public bearer may be created as part of the web redemption flow, or
• Your backend may obtain a public bearer via the session_code-based authorization flow

In both cases, authentication remains anchored in QUP, and partners do not integrate Cognito directly.

For the detailed authorization mechanics, including:

• creating a session_code
• exchanging it for a public bearer
• calling /me endpoints securely

refer to the following documentation:

📘

👉 Authorization Flow https://docs.funtrips.io/docs/authorization-flow

Choosing the right integration approach