# client.auth.providers

> client.auth.providers — the auth.providers operations.

`client.auth.providers` — the `auth.providers` operations.

On `AsyncKindgi` every method is the same, awaited.

## `client.auth.providers.list()`

```python signature
list(*, timeout: float | None = None) -> IdentityProviderCollectionPage
```

List identity providers configured for the tenant. `GET /v1/auth/providers`

Returns the tenant's identity providers (OIDC, SAML), each with `signIn` when the deployment sets it. Secrets appear only as REFERENCES (`clientSecretRef`, `spSigningKeyRef`…); a plaintext secret is never on the wire.

## `client.auth.providers.register()`

```python signature
register(
    body: RegisterIdentityProviderBody | Mapping[str, Any] | None = None,
    /,
    *,
    idempotency_key: str | None = None,
    timeout: float | None = None,
    **fields: Any,
) -> RegisterIdentityProviderResult
```

Register an identity provider (OIDC or SAML). `POST /v1/auth/providers`

Unique per tenant on `providerId`: re-registering a known provider returns `409 identity-provider-already-registered`; change it with `PATCH /v1/auth/providers/{providerId}`, which keeps its sign-in URLs. Secrets are given by reference (`clientSecretRef`, `spSigningKeyRef`…); a `clientSecret` (or a raw key) is refused with `400 invalid-provider-config`, as is `allowedRedirectUris`, which nothing would enforce (sign-in runs in the deployment, at its own callback URL). The deployment may check the configuration (OIDC discovery, SAML metadata): `422 identity-provider-invalid` says what failed. The answer carries the stored provider when the deployment returns it, with `signIn`: what to give the identity provider.

## `client.auth.providers.get()`

```python signature
get(
    provider_id: str | UUID,
    /,
    *,
    timeout: float | None = None,
) -> GetIdentityProviderResult
```

Get one identity provider. `GET /v1/auth/providers/{providerId}`

The provider as stored, with `signIn` when the deployment sets it. Secrets appear only as references.

## `client.auth.providers.update()`

```python signature
update(
    provider_id: str | UUID,
    body: UpdateIdentityProviderBody | Mapping[str, Any] | None = None,
    /,
    *,
    idempotency_key: str | None = None,
    timeout: float | None = None,
    **fields: Any,
) -> UpdateIdentityProviderResult
```

Change an identity provider, keeping its sign-in URLs. `PATCH /v1/auth/providers/{providerId}`

Merges the changes into the stored provider and checks the result as a registration is (`400 invalid-provider-config`; `422 identity-provider-invalid` when the deployment can't use it). The provider keeps its `signIn`, so nothing changes on the identity provider's side. Not mounted when the deployment can't update providers.

## `client.auth.providers.sign_in()`

```python signature
sign_in(
    provider_id: str | UUID,
    /,
    *,
    kind: Literal['oidc', 'saml'] | None = None,
    timeout: float | None = None,
) -> IdentityProviderSignInUrls
```

What to give the identity provider, before or after registering. `GET /v1/auth/providers/{providerId}/sign-in`

The redirect URI (OIDC) or the ACS URL, entity ID and metadata URL (SAML) a provider under this `providerId` gets: the same before it's registered, after, and after an unregister and a new registration. So an admin sets up the identity provider's side first, then registers with what it gives back. `kind` is required until the provider is registered. Not mounted when the deployment can't say.

## `client.auth.providers.unregister()`

```python signature
unregister(
    provider_id: str | UUID,
    /,
    *,
    idempotency_key: str | None = None,
    timeout: float | None = None,
) -> UnregisterIdentityProviderResult
```

Unregister an identity provider. `POST /v1/auth/providers/{providerId}/unregister`