atoti.OidcConfig#

final class atoti.OidcConfig#

The config to delegate authentication to an OpenID Connect provider (Auth0, Google, Keycloak, etc.).

The user’s roles are defined using atoti.security.Security.oidc and individual_roles.

Example

>>> config = tt.OidcConfig(
...     provider_id="auth0",
...     issuer_url="https://example.auth0.com",
...     client_id="some client ID",
...     client_secret="some client secret",
...     name_claim="email",
...     scopes={"email", "profile"},
...     roles_claims={
...         "https://example.com/roles",
...         ("other", "path", "to", "roles"),
...     },
... )
access_token_format: Literal['jwt', 'opaque'] = 'jwt'#

The format of the access tokens delivered by the OIDC provider.

Opaque tokens involve another request to the OIDC provider’s user info endpoint to retrieve the user details. The URL of this user info endpoint will be fetched from the f"{issuer_url}/.well-known/openid-configuration" endpoint.

See also

Opaque tokens can be used with atoti.OAuth2ResourceOwnerPasswordAuthentication.

client_id: str#

The app’s client ID, obtained from the authentication provider.

client_secret: str#

The app’s client secret, obtained from the authentication provider.

issuer_url: str#

The issuer URL parameter from the provider’s OpenID Connect configuration endpoint.

name_claim: str | None = None#

The name of the claim in the ID token to use as the name of the user.

provider_id: str#

The name of the provider.

It is used to build the redirect URL: f"{session_url}/login/oauth2/code/{provider_id}".

roles_claims: Set[str | tuple[str, ...]] = frozenset({})#

The claims of the ID token from which to extract roles to use as keys in the role_mapping.

When an element of the set is a tuple, the tuple elements will be used as a path pointing to a nested value in the token.

scopes: Set[str] = frozenset({})#

The scopes to request from the authentication provider.

use_client_secret_as_certificate: bool = False#

If True, the passed client_secret must be a client certificate instead of a random secret. This client certificate will be passed in the X-Cert header of the request made to the OIDC provider to retrieve an access token.