Skip to main content

Partner access quickstart

Set up SecureAuth Connect for partner access, giving contractors, vendors, and partner-company employees scoped access to your apps and APIs with federated identity, time-bounded grants, and full audit trails. Partners typically sign in through a partner portal, bring their own identity, and need access to only a defined set of your systems.

What is partner access?​

Partner identity is distinct from both consumer and B2B-customer identity:

  • External users, not your customers. Partners use your tools to do work for you. They're accountable to an outside employer, so you want their home IdP to be the source of truth for their identity.

  • Scoped to a defined app set. Partners should see only the apps they need. A vendor working with one business unit should not see another unit's tools.

  • Lifecycle management is critical. Onboarding is fast, rotation is routine, and offboarding must be automatic when the contract ends or the partner relationship changes. Stale partner access is a common audit finding.

  • Audit and attestation. Data-sharing agreements, SOC 2, and similar frameworks require traceable records of who accessed what and which internal owner certified the relationship.

Partners are modeled in SecureAuth the same way B2B customers are: as Organizations inside your tenant. See B2B access for the foundational architecture. This page layers partner-specific patterns on top.

Architecture at a glance​

The partner portal is often the primary entry point. Some teams build it with SecureAuth; others connect an existing portal to SecureAuth as the authorization layer. Either way, SecureAuth handles identity brokering, per-partner policy, and scoped token issuance.

Federate with each partner's identity​

Most partners already run their own IdP. Bring-your-own-identity keeps you out of their user directory and removes responsibility for their password resets and offboarding.

Scope and control app access​

Partners should see only what they need. SecureAuth scopes access at three levels:

  • Application — assign only the apps a partner is entitled to use; unlisted apps don't appear.
  • Scope — within an app, restrict to read vs write operations or specific API endpoints via access control policies.
  • Approval — apply MFA policies or approval workflows to high-value actions (production data, admin operations).

Time-bound and auto-revoke​

Stale partner access is the most common audit finding. Build expiration into the grant, not into a calendar reminder.

  • Configure short access token lifetimes and custom token time-to-live per Organization.
  • Use Identity Pool attributes or partner-IdP claims to drive automatic deprovisioning when a contract attribute changes.
  • Pair with your partner-management system: when the partner record is deactivated, the SecureAuth Organization or user is disabled.

Let partners manage their own users​

Your team should not handle routine partner user changes.

Act-on-behalf-of patterns​

Some partner integrations need a system to call your APIs on behalf of a partner user (a partner portal fetching an invoice, a vendor system pulling purchase order data for a specific buyer).

Audit and attestation​

Partner activity often carries tighter compliance requirements than internal employee access.

  • Every token issuance and policy decision is recorded in SecureAuth's audit log, scoped by Organization so you can filter activity by partner.
  • Include organization_id and partner metadata in token claims so downstream systems log partner context, not just user ID.

Next steps​