Developers
Developers
Integrate Harbor as a standards-based OIDC/OAuth 2.1 relying party with PKCE, or bridge in a legacy SAML stack. Reference the canonical control-plane/api/openapi.yaml contract for the self-service management API.
OIDC / OAuth 2.1 with PKCE
Register as an OpenID Connect relying party and use the authorization code flow with PKCE. Each user connecting to your app receives Harbor's pairwise per-relying-party identifier, not a shared, cross-site ID.
Official sign-in button kit
Every active application on your dashboard has a copy-paste sign-in button snippet with its client_id, redirect_uri, and issuer already filled in — no separate discovery step.
SAML bridge for legacy stacks
Applications that only speak SAML integrate through the SAML bridge (enterprise/saml-bridge), which fronts Harbor's OIDC provider with a standard SAML 2.0 service-provider interface — no changes to Harbor's core identity model.
Self-service management API
Once you're a tenant, the /api/v1/me/ routes let you manage API keys, webhooks, and your billing plan from your own systems, secured with a per-tenant Bearer API key.
Official sign-in button kit
Once an application is active, its dashboard page on /dashboard/oidc-applications shows a copy-paste snippet with sign-in button markup and that application’s client_id, redirect_uri, and issuer already filled in.
<a class="harbor-sign-in-button" data-harbor-client-id="..." data-harbor-redirect-uri="...">
Sign in with Harbor
</a>See it working end to end at demo.harborauth.com, a live sample relying party that completes its own Authorization Code + PKCE flow against Harbor and displays the pairwise subject identifier it receives.
API reference
The management API — tenant self-service, API keys, webhooks, and billing plans — is defined in control-plane/api/openapi.yaml, an OpenAPI 3.1 document. It’s the same contract the customer portal itself is generated against, so it never drifts from what’s actually deployed.
Integration effort and what’s on you
Harbor Cloud provides the standards-based identity provider, the SAML bridge, and the management API. Integrating it, running your trial, and operating your side of the connection are your responsibility — this isn’t a fully managed migration.
- Registering your application as a relying party and configuring redirect URIs, scopes, and claims mapping for your environment.
- Running your own trial/pilot and validating the integration against your authentication and authorization requirements before production traffic.
- Ongoing operational tasks on your side of the integration: session handling in your application, your own uptime and monitoring, and rotating your client credentials.