Connect SAASPASS to FastSSO.

The cleanest boundary is SAASPASS as the upstream workforce identity provider and FastSSO as the broker that presents one stable OIDC contract to independent applications.

1. Architecture decision

Use a tenant-specific Generic OIDC application in the SAASPASS Admin Portal. SAASPASS performs workforce authentication and MFA. FastSSO validates the returned identity, binds it to the selected organization and connection, and issues a separate downstream authorization code to the requesting application.

This split avoids passing SAASPASS access or ID tokens to applications. It also means applications never need a SAASPASS client secret and remain independent of the provider chosen by another tenant.

2. Configuration

In SAASPASS

1. Create or select the customer company and add a Generic OIDC application.
2. Register the exact planned callback: https://<fastsso-host>/oidc/<connection_id>/callback. Do not use wildcards.
3. Select Authorization Code; enable its PKCE variant if the tenant supports it. Request only openid email profile.
4. Assign a small pilot group. Record the App Key (client ID), App Password, expected issuer value, and the application-specific signing public key shown in the Developers tab.
5. Confirm key-rotation procedure, supported signing algorithms, nonce behavior, and production issuer with SAASPASS before enabling traffic.

In FastSSO

Create a tenant-scoped connection using the saaspass preset. Store the secret outside source control and encrypt it at rest before production.

{
  "provider": "saaspass",
  "protocol": "oidc",
  "issuer": "<exact iss claim confirmed by SAASPASS>",
  "client_id": "<SAASPASS App Key>",
  "client_secret": "<secret-manager reference>",
  "signing_public_key": "<pinned application public key>",
  "authorization_endpoint": "https://www.saaspass.com/sd/oauth/authorize",
  "token_endpoint": "https://www.saaspass.com/sd/oauth/token",
  "userinfo_endpoint": "https://www.saaspass.com/sd/oauth/userinfo",
  "scopes": ["openid", "email", "profile"]
}

3. Authentication flow

1. The application sends a normal downstream request to FastSSO with state, nonce, and an S256 PKCE challenge.
2. FastSSO validates the client and exact redirect URI, discovers the organization from the verified email domain, and selects its SAASPASS connection.
3. FastSSO creates a one-time upstream transaction containing organization, connection, downstream request, random state, nonce, and a separate PKCE verifier.
4. The browser goes to SAASPASS /sd/oauth/authorize for authentication and MFA.
5. The callback rejects missing/mismatched state, errors, expired transactions, or a reused transaction before exchanging the code server-to-server at /sd/oauth/token.
6. FastSSO validates the ID token and maps the identity. Only then does it issue its own short-lived downstream code and resume the application flow.

SAASPASS documents code_challenge_method=SHA-256; the standards value is normally S256. Verify the accepted wire value in an isolated tenant and add it as an interoperability fixture instead of silently trying both in production.

4. Claim mapping and account linking

Use the tuple (connection_id, upstream sub) as the durable identity key. Email is routing and profile data, not the sole account-linking key; SAASPASS notes that a user may have multiple profiles.

5. Non-negotiable validation gates

• Allowlist the HTTPS SAASPASS hosts and block redirects or metadata fetches to private/link-local networks.
• Validate ID-token signature with the pinned tenant/application key; reject algorithm changes, unknown kid, and unsigned tokens. FastSSO must not follow the vendor reference’s suggestion that signature checking may be optional.
• Validate exact issuer, client ID audience, expiry, issued-at bounds, subject, and nonce when supported. Require an explicit reviewed fallback if SAASPASS cannot round-trip nonce.
• Consume state, authorization code, token jti, and transaction identifiers once. Keep raw codes and tokens out of logs, database diagnostics, audit metadata, and error responses.
• Use strict timeouts, response-size limits, TLS verification, application/x-www-form-urlencoded token requests, and no-store handling.
• Add fixtures for wrong issuer/audience/key, expired token, replay, state mismatch, missing email, multi-profile subjects, PKCE mismatch, and upstream error responses.

6. Lifecycle and alternative channels

SAASPASS also documents SAML, its HTTP API, application/company-scoped tokens, OTP checks, and dynamic client registration. These are separate phases:

• SAML: useful for tenants standardized on SAML, but only after FastSSO’s hardened SAML acceptance checklist is complete.
• HTTP account APIs: assess for assignment and deprovisioning only after clarifying whether they provide the lifecycle semantics FastSSO needs. Do not treat generic REST account operations as SCIM.
• Dynamic client registration: avoid initially. Manual, reviewed per-tenant registration has a smaller blast radius; DCR introduces a high-value bearer credential.
• OTP/widgets/custom SSO callback: not the preferred broker boundary because they add proprietary flows and can weaken the clean OIDC validation model.

7. Rollout plan

1. Contract capture: obtain a non-production tenant, public signing key, sample tokens, issuer confirmation, PKCE/nonce behavior, error catalogue, and key-rotation procedure.
2. Adapter: implement an OIDC client behind providers/ with encrypted credentials and transactional one-time state.
3. Adversarial tests: pass malicious and conformance fixtures before replacing HTTP 501.
4. Pilot: one organization, one verified domain, one assigned group, short sessions, and a tested break-glass rollback.
5. Operate: monitor only redacted event types and identifiers; document credential rotation, tenant offboarding, and incident revocation.

Official sources

• SAASPASS API Reference — Generic OIDC, PKCE, token, UserInfo, public-key validation, REST services, and DCR.
• SAASPASS product site — product and company overview.
• FastSSO OpenAPI, threat model, and architecture — broker contracts and release gates.

Vendor capabilities and documentation can change. Re-verify the authenticated SAASPASS Admin Portal configuration and live protocol metadata during implementation.