Skip to main content

Partner Access quickstart

Partner Access covers external humans who aren't on your payroll but need to use some of your applications: contractors, vendors, consultants, distributors, and employees of partner companies. They usually come in through a partner portal, bring their own identity, and need access to only a curated slice of your systems.

What is Partner Access?​

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

  • External humans, not your customers. Partners access 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 curated app set. A vendor servicing a line of business should see that line of business's apps and nothing else. A contractor on a 90-day engagement gets one app, not ten.
  • Lifecycle is everything. 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 top 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 plug an existing portal into 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 off the hook for their password resets and offboarding.

Scope and gate 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. Bake 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 be the middleman for 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 PO 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 pull "everything Acme Consulting did last quarter" cleanly.
  • Include organization_id and partner metadata in token claims so downstream systems log partner context, not just user ID.

Next steps​