Choose an authentication model
Select imported, application, installation, or user-delegated authority for an integration.
Choose the narrowest authority that matches the work. The protocol name alone is not enough: OAuth user authority and application installation authority solve different problems.
Decision table
| Requirement | Recommended model | Typical scope |
|---|---|---|
| Store a secret already issued by a service | Imported Credential | Tenant or customer |
| Background automation independent of a person | Application or installation Credential | Tenant or customer |
| Act as a specific person | OAuth user Credential | Principal |
| Authenticate who may invoke a Channel | AuthProvider, not CredentialProvider | Incoming request |
| Use a different integration for every downstream company | Customer-scoped Resource and Credential | Customer |
Imported secrets
Use Store an existing secret when the service already issued an API key, password, signing secret, or token and no provider should rotate it automatically. Imported material is easy to start with, but renewal remains an operator responsibility.
Application and installation authority
Use application authority for unattended work. Prefer a provider that mints short-lived, least-privilege material from a durable application identity. For GitHub, this means a GitHub App installation Credential rather than a user OAuth token.
User-delegated authority
Use OAuth when operations must be attributable to and constrained by a person. Install the provider once for the tenant-owned application, then create one Credential per authorized grant. Store those Credentials under principal scope when a shared agent acts as the authenticated user.
Do not conflate sign-in and delegation
An AuthProvider may use OAuth to establish identity for incoming requests. A CredentialProvider may use the same protocol to acquire an outbound token. These flows can share an external application and callback infrastructure, but they have different records, Policies, consent, and lifecycles.
If a user only needs permission to invoke an agent, do not create an outbound Credential. If the agent must also act on that user's behalf, ask separately and bind the resulting Credential to that principal.