Annexe
Configuration existante
Fournisseurs d’authentification (existants)
Fournisseurs d’authentification OpenID Connect (OIDC) (existants)

Fournisseurs d’authentification OpenID Connect (OIDC) (existants)

ℹ️
Cette rubrique fait référence à la syntaxe de configuration existante. Les fournisseurs d’authentification OIDC sont désormais définis comme des applications OIDC, avec un fournisseur OIDC correspondant.

Maverics Orchestrator peut être configuré pour agir comme un fournisseur OpenID Connect (OIDC).

Il prend en charge l’autorisation d’accès qui est optimisée pour les clients confidentiels utilisant :

Les clients publics OAuth 2.0 utilisant l’autorisation d’accès sont vulnérables à l’attaque par interception du code d’autorisation. Cette menace peut être atténuée grâce à l’utilisation de la fonction PKCE. Pour utiliser la fonction PKCE, le client qui s’authentifie doit envoyer un code_challenge et un code_challenge_method=S256 avec sa requête d’autorisation, et le code_verifier correspondant avec sa requête de jeton.

Name

La valeur name doit être un nom unique pour chaque instance du fournisseur OIDC.

Type

Le type de protocole d’identité OIDC, qui sera utilisé.

Issuer

issuer correspond au domaine auquel le jeton d’identification sera attribué. Le domaine « Issuer » est une URL sensible à la casse utilisant le schéma https et contenant les éléments suivants : schéma, hôte et, éventuellement, numéro de port et chemin d’accès, mais aucun élément de requête ou de fragment.

L’émetteur du fournisseur OIDC (qui est généralement obtenu au cours de la phase « Discovery ») doit correspondre exactement à la valeur de la réclamation iss (émetteur) dans le jeton d’identification.

Well Known Endpoint

wellKnownEndpoint renvoie une réponse contenant un ensemble de réclamations concernant la configuration du fournisseur d’authentification OIDC. Ce terminal peut notamment être utilisé pour découvrir les terminaux exposés par le serveur, les champs d’application disponibles auprès du serveur et les algorithmes permettant de signer et/ou de chiffrer les jetons d’accès et d’identification.

Un exemple de réponse :

{
  "issuer": "https://example.com/",
  "authorization_endpoint": "/auth",
  "token_endpoint": "/token",
  "userinfo_endpoint": "/userinfo",
  "jwks_uri": "/jwks",
  "response_types_supported": [
    "code"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "phone"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post"
  ],
  "grant_types_supported": [
    "authorization_code"
  ]
}

Cela correspond aux sections 4.1, 4.2et 3.0 d’OpenID Connect Discovery 1.0.

JWKS Endpoint

Le terminal jwksEndpoint renvoie des informations concernant l’ensemble de clés Web JSON (JWK) pour le fournisseur OIDC. Ce point de terminaison doit correspondre à la réclamation jwks_uri renvoyée par le terminal connu.

Un exemple de réponse :

{
  "keys": [
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "A_qELBkAfjj6wONiJqiLRbmFPEM",
      "alg": "RS256",
      "n": "qONXrtLtRIRg_xKDX8LQPXRAbK-zc9hqDgWymfSrGMzj3agDZ9e_kA2pe8p6b6g7Od-93WdvFwhyxlvkb8VwYznrGYp6sNqmDW4TeT-DwzIPTHKd5FAul1nkk0eCxM0356OXu9rs_GlAQ1_XLPvaZ61teD0WZx4-dn6a-LcB-Sz7j455uE5GFSLs4M6OSOaHlMKxgkvIeAicSCoHYCbyyRdDKn2ShFVhvBod6_sBhFkRDuY-K-CW32ABr0lD-m249zFDWCrfRRLNW4uR4phmRIHTM0ucIcrw1Xn56_BvzDOC7z3lzxzPOfk4ou--pJpDL4_9RK72BVLLfExuWsmFWQ",
      "e": "AQAB"
    }
  ]
}

La rotation des clés de signature et la rotation des clés de chiffrement peuvent être effectuées en utilisant ce terminal.

Authorization Endpoint

Le terminal authorizationEndpoint correspond à l’emplacement où le fournisseur OICDP répondra à la demande d’autorisation OAuth 2.0 afin d’authentifier l’utilisateur final. La partie utilisatrice utilisera ce terminal pour lancer le processus d’authentification d’un utilisateur final.

Cela correspond à la section 3.1.2 d’OpenID Connect Core 1.0.

Token Endpoint

tokenEndpoint correspond au terminal où le fournisseur OIDC répondra à la partie utilisatrice avec un jeton d’accès et un jeton d’identification. La partie utilisatrice utilisera ce terminal pour terminer le processus d’authentification.

Cela correspond à la section 3.1.3 d’OpenID Connect Core 1.0.

UserInfo Endpoint

UserinfoEndpoint correspond à l’emplacement où le fournisseur OIDC renverra les réclamations concernant l’utilisateur final authentifié. S’il est disponible, le terminal renverra les réclamations associées à l’un des champs d’application suivants : profile, openid, phone, email et address.

Si l’option claimsMapping a été définie pour le client correspondant, ces mappages seront appliqués à la réponse userinfo.

Cela correspond à la section 5.3 d’OpenID Connect Core 1.0.

Le lien entre les champs d’application et les réclamations est défini dans la section 5.4 d’OpenID Connect Core 1.0.

Vous trouverez ci-dessous un exemple de réponse du terminal userinfo.

{
  "sub": "e1ac5f1d-902c-461e-8608-7ddf2ff62c6e",
  "family_name": "Doe",
  "given_name": "Jennifer",
  "name": "Jen Doe",
  "nickname": "Jen",
  "phone_number": "+56 (2) 687 2400",
  "address": {
    "formatted": "123 Doetown Ave"
  }
}

Introspect Endpoint

Le terminal introspectEndpoint correspond à l’emplacement où le fournisseur OIDC renverra les réclamations pour le jeton qui lui a été transmis.

Cela correspond au document RFC 7662, OAuth 2.0 Token Introspection.

Vous trouverez ci-dessous un exemple de réponse du terminal introspect.

{
  "active": true,
  "aud": [
    "https://app.sonarsystems.com"
  ],
  "exp": 1657838608,
  "iat": 1657835008,
  "iss": "https://maverics.strata.io",
  "sub": "e1ac5f1d-902c-461e-8608-7ddf2ff62c6e",
  "preferred_username": "jdoe",
  "scope": "openid profile"
}

Token Signing

tokenSigning définit les clés qui seront utilisées pour signer les jetons JWT. Les formats standards PKCS1, PKCS8 et PKIX sont pris en charge.

⚠️
À défaut de définition, une paire de clés éphémères sera générée par souci de confort. Cette paire de clés ne sera maintenue que pendant la durée de vie d’une instance d’orchestrateur donnée. La paire de clés générée automatiquement ne doit être utilisée qu’à des fins de test et ne convient pas aux environnements de production.

Algorithm

algorithm représente l’algorithme de chiffrement utilisé pour générer la paire de clés. Actuellement, seul RSA256 est pris en charge.

Private Key

privateKey correspond à la clé privée encodée au format PEM. Ce champ peut éventuellement être chargé à partir d’un fournisseur de secrets.

Public Key

publicKey (obsolète) précédemment utilisé pour une clé publique encodée au format PEM correspondant à la clé privée privateKey. Dans les versions actuelles de l’orchestrateur, ce paramètre est ignoré et la clé publique est dérivée de la clé privée.

Fournisseurs d’attributs

Les fournisseurs attrProviders constituent une configuration facultative pour un système d’identité ou un magasin de données à partir duquel l’OIDCProvider peut récupérer des attributs supplémentaires utilisés dans claimsMapping. Si cette configuration est définie au niveau de l’AuthProvider, elle sera transmise à tous les clients.

Connector

connecteur est une référence au nom du connecteur défini qui sera utilisé en tant que fournisseur d’attributs.

Mappage des noms d’utilisateur

usernameMapping définit l’attribut qui sera utilisé en tant que clé de recherche pour interroger les attributs de l’utilisateur.

Clients

clients correspond aux clients OIDC enregistrés (parties utilisatrices).

ID

L’identifiant clientID est unique au client.

L’identifiant du client envoyé dans la requête d’autorisation doit correspondre à l’identifiant du client configuré.

Client Secret

clientSecret peut fournir un secret à utiliser dans le flux du code d’autorisation OAuth 2.0. La valeur du secret peut être stockée dans le fournisseur de secrets et référencée à l’aide de flèches.

Le secret du client envoyé dans la requête de jeton doit correspondre au secret configuré.

Redirects

La clé redirects correspond à la liste des URI auxquels la réponse à la demande d’authentification sera envoyée.

L’URI de redirection envoyé dans la requête d’authentification doit correspondre exactement à l’une de ces valeurs configurées.

Authentification avec les fournisseurs d’identité

Le champ authentication permet de répertorier les fournisseurs d’identité qui seront utilisés pour authentifier un utilisateur.

Dans l’exemple ci-dessous, l’utilisateur sera invité à s’authentifier dans un premier temps avec Azure, puis avec Okta.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    # ...
    clients:
      - clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        redirects:
          - https://app.sonarsystems.com/oidc/callback
        authentication:
          idps:
            - azure
            - okta
ℹ️
La section idps ne peut pas être utilisée avec les extensions de services isAuthenticatedSE et authenticateSE décrites ci-dessous.

ClaimsMapping

claimsMapping permet la mise en correspondance des attributs de la session d’un utilisateur avec des réclamations standard sur le jeton d’identification.

Les réclamations ajoutées au jeton d’identification sont déterminées par la valeur du paramètre « scope query » envoyé dans la requête d’autorisation. Les champs d’application pis en charge en plus du champ d’application openid requis, sont email, profile, address et phone. Une liste des correspondances entre les valeurs des réclamations et les champs d’application est fournie dans le document OpenID Connect Core 1.0, section 5.4.

Le remplacement des sous-réclamations standard par un attribut fourni par le fournisseur d’identité n’est possible que via l’extension de service buildUserInfoClaimsSE.

Le renvoi d’un nonce fourni dans la requête d’autorisation par le biais d’une réclamation dans la réponse du jeton d’identification est également pris en charge.

Par exemple, si les champs d’application de email et profile sont demandés dans la requête d’autorisation, qu’Azure est le fournisseur d’identité utilisé et que le mappage des réclamations contient des mappages vers des attributs Azure, alors les réclamations relatives aux champs d’applications email et profile seront incluses dans la réponse IDtoken avec la valeur de l’attribut associé.

Exemple de configuration :

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    # ...
    clients:
      - clientID: exampleID
        # ...
        claimsMapping:
          email: azure.name
          name:  azure.displayname
          family_name: azure.surname
          given_name: azure.givenname

Exemple de requête d’autorisation :

https://{oidcprovider-hostname}/auth?scope=openid%20email%20profile&response_type=code&client_id=exampleID&nonce=n-0S6_WzA2Mj&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback

Exemple de charge utile JOSE pour le jeton d’identification (décrypté et décodé) suivant la configuration et la requête ci-dessus.

{
  "aud": [
    "https://app.sonarsystems.com"
  ],
  "email": "[email protected]",
  "exp": 1632514213,
  "family_name": "Jones",
  "given_name": "Bob",
  "iat": 1632510613,
  "iss": "https://maverics.strata.io",
  "maverics.sid": "a65fd195-1292-430d-aef5-13254bdcaa0b",
  "name": "Bob Jones",
  "nonce": "n-0S6_WzA2Mj",
  "sub": "78412345-7890-abba-cabb-80e26c0b36c3"
}

Fournisseurs d’attributs

Les fournisseurs attrProviders constituent une configuration facultative pour un système d’identité ou un magasin de données à partir duquel l’OIDCProvider peut récupérer des attributs supplémentaires utilisés dans claimsMapping. Cette configuration au niveau du client remplacera toute configuration au niveau du fournisseur.

Connector

connecteur est une référence au nom du connecteur défini qui sera utilisé en tant que fournisseur d’attributs.

Mappage des noms d’utilisateur

usernameMapping définit l’attribut qui sera utilisé en tant que clé de recherche pour interroger les attributs de l’utilisateur.

Allowed Audiences

Le bloc allowedAudiences est une configuration facultative qui présente une liste des utilisateurs autorisés à consommer des jetons d’accès. Lorsqu’un client adresse une requête au terminal d’autorisation, il est possible d’inclure un paramètre de ressource facultatif indiquant le public cible du jeton. La valeur fournie dans le paramètre de ressource doit figurer dans la liste des utilisateurs autorisés.

Cette configuration est utilisée lorsque les serveurs de ressources, tels que les API, procèdent à des autorisations par le biais du jeton d’accès. Pour plus d’informations, veuillez vous référer au document RFC 9068.

Allow Offline Access

La configuration allowOfflineAccess permet de définir si un client a la possibilité de demander des jetons d’actualisation. Les jetons d’actualisation ne seront délivrés que si l’indicateur allowOfflineAccess est défini sur « true » et que la requête d’autorisation inclut le champ d’application offline_access.

Configuration du jeton d’accès

Type

Les jetons d’accès client peuvent être configurés dans la section accessToken. Le type peut être défini comme étant jwt (par défaut) ou opaque.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    clients:
      - clientID: exampleClient
        clientSecret: <exampleSecret>
        accessToken:
          type: jwt # opaque | jwt
        # ...

Longueur

Si le type est défini comme étant opaque, la longueur peut être comprise entre 22 et 256 caractères. Si elle n’est pas définie, la longueur par défaut est de 28 caractères.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    clients:
      - clientID: exampleClient
        accessToken:
          type: opaque
          length: 64 # 22 - 256
        # ...

Lifetime

Par défaut, les jetons d’accès disposent d’une durée de vie d’une heure. Vous pouvez configurer la durée de vie du jeton d’accès de chaque client, en définissant la balise lifetimeSeconds sous la section accessToken, sur une valeur valide en secondes (nombre entier).

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    clients:
      - clientID: exampleID
        accessToken:
          type: jwt
          lifetimeSeconds: 3600
        # ...

Refresh Token Length

La valeur refreshToken.length peut être comprise entre 22 et 256 caractères. Si elle n’est pas définie, la longueur par défaut est de 28 caractères. Les jetons d’actualisation sont toujours opaques, même lorsque les jetons d’accès sont définis sur type: jwt.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    clients:
      - clientID: exampleID
        refreshToken:
          length: 32
    # ...

ID Token Lifetime

Par défaut, les jetons d’identification disposent d’une durée de vie d’une heure. Cette valeur est utilisée pour la durée d’expiration du jeton et de ses réclamations. En option, vous pouvez configurer la durée de vie du jeton d’identification de chaque client, en définissant la balise idTokenLifetimeSeconds, sur une valeur valide en secondes (nombre entier).

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    clients:
      - clientID: exampleClient
        idTokenLifetimeSeconds: 3600
        # ...

Token Signing

La signature tokenSigning peut éventuellement être définie sur un client, mais devrait dans la plupart des cas être définie sur AuthProvider. Pour plus de détails, reportez-vous à la documentation relative au niveau AuthProvider.

Token Encryption

tokenEncryption définit la configuration du chiffrement des jetons d’identification.

Algorithm

algorithm représente l’algorithme de chiffrement utilisé pour générer la paire de clés. Actuellement, seul RSA256 est pris en charge.

Public Key

publicKey correspond à la clé publique codée au format PEM qui sera utilisée pour chiffrer le jeton d’identification.

Extensions de services

Les extensions de services donnent aux administrateurs la possibilité de personnaliser le comportement du fournisseur d’authentification OIDC.

isAuthenticatedSE

isAuthenticatedSE est une extension de services optionnelle qui peut être utilisée pour modifier le comportement par défaut qui détermine si un utilisateur est déjà authentifié.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    authentication:
      isAuthenticatedSE:
        funcName: IsAuthenticated
        file: /etc/maverics/extensions/isAuthenticated.go
    # ...

/etc/maverics/extensions/isAuthenticated.go

package main

import (
	"net/http"

	"maverics/auth"
	"maverics/session"
)

func IsAuthenticated(op *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) bool {
	if session.GetString(req, "azure.authenticated") == "true" {
		return true
	}

	return false
}

authenticateSE

L’extension de service optionnelle authenticateSE est utilisée pour contrôler la manière dont l’authentification est effectuée.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    authentication:
      authenticateSE:
        funcName: Authenticate
        file: /etc/maverics/extensions/authenticate.go
    # ...

/etc/maverics/extensions/authenticate.go

package main

import (
	"net/http"

	"maverics/auth"
)

func Authenticate(op *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) {
	op.IDPs["azure"].CreateRequest().Login(rw, req)
}

buildIDTokenClaimsSE

buildIDTokenClaimsSE est une extension de services optionnelle qui permet de personnaliser la façon dont sont construites les réclamations dans le jeton d’identification.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    buildIDTokenClaimsSE:
      funcName: BuildIDTokenClaims
      file: /etc/maverics/extensions/buildIDTokenClaims.go
    # ...

/etc/maverics/extensions/buildIDTokenClaims.go

package main

import (
	"net/http"

	"maverics/auth"
	"maverics/session"
)

func BuildIDTokenClaims(op *auth.OIDCProvider, req *http.Request, session *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"example": "claim"}, nil
}

buildAccessTokenClaimsSE

L’extension de services optionnelle buildAccessTokenClaimsSE permet de personnaliser la façon dont sont construites les revendications dans le jeton d’accès.

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    buildAccessTokenClaimsSE:
      funcName: BuildAccessTokenClaims
      file: /etc/maverics/extensions/buildAccessTokenClaims.go

    # ...

/etc/maverics/extensions/buildAccessTokenClaims.go

package main

import (
	"net/http"

	"maverics/auth"
	"maverics/session"
)

func BuildAccessTokenClaims(op *auth.OIDCProvider, req *http.Request, session *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"scope": "admin:read admin:write"}, nil
}

buildUserInfoClaimsSE

buildUserInfoClaimsSE est une extension de services optionnelle permettant de personnaliser les réclamations renvoyées par le terminal userinfo. L’argument session fourni dans l’extension de services pointe vers les attributs de session associés à l’utilisateur requis.

⚠️
En tant qu’auteur d’une extension de services, vous êtes responsable de son comportement et devez vous assurer que la réponse est conforme à la spécification.
authproviders:
  - name: exampleOIDCProvider
    type: oidc
    buildUserInfoClaimsSE:
      funcName: BuildUserInfoClaims
      file: /etc/maverics/extensions/buildUserInfoClaims.go

/etc/maverics/extensions/buildUserInfoClaims.go

package main

import (
	"net/http"

	"maverics/auth"
	"maverics/log"
	"maverics/session"
)

func BuildUserInfoClaims(op *auth.OIDCProvider, req *http.Request, sess *session.Session) (map[string]interface{}, error) {
	log.Info("msg", "returning custom userinfo attributes")

	return map[string]interface{}{
		"given_name":  sess.GetString("azure.name"),
		"family_name": sess.GetString("azure.surname"),
		"email":       sess.GetString("azure.email"),
		"sub":         sess.Subject(),
	}, nil
}

Utilisation des extensions de services

Les extensions de service peuvent être définies au niveau du fournisseur et/ou du client. Si une extension de services est spécifiée pour un fournisseur, tous les clients du fournisseur utiliseront cette extension de services, à l’exception des clients qui remplacent l’extension de services au niveau du fournisseur. Les extensions de services au niveau du client auront toujours la priorité.

Pour les extensions de services au niveau du fournisseur, spécifiez les fonctions au même niveau YAML que celui du fournisseur. Au niveau du client, spécifiez les fonctions isAuthenticatedSE et authenticateSE dans la section authentication: client au même niveau que la liste idps:. Spécifiez les options buildIDTokenClaimsSE et buildAccessTokenClaimsSE au même niveau que celui du client.

Exemple complet de toutes les extensions de service définies au niveau du fournisseur et du client :

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    isAuthenticatedSE:
      funcName: IsAuthenticated
      file: /etc/maverics/extensions/authprovider.go

    authenticateSE:
      funcName: Authenticate
      file: /etc/maverics/extensions/authprovider.go

    buildIDTokenClaimsSE:
      funcName: BuildIDTokenClaims
      file: /etc/maverics/extensions/authprovider.go

    buildAccessTokenClaimsSE:
      funcName: BuildAccessTokenClaims
      file: /etc/maverics/extensions/authprovider.go

    clients:
      - clientID: alpha
        clientSecret: <alphaClientSecret>
        redirects:
          - https://foo.com/bar
        authentication:
          isAuthenticatedSE:
            funcName: IsAuthenticated
            file: /etc/maverics/extensions/alphaClient.go    
          authenticateSE:
            funcName: Authenticate
            file: /etc/maverics/extensions/alphaClient.go

        buildIDTokenClaimsSE:
          funcName: BuildIDTokenClaims
          file: /etc/maverics/extensions/alphaClient.go

        buildAccessTokenClaimsSE:
          funcName: BuildAccessTokenClaims
          file: /etc/maverics/extensions/alphaClient.go

/etc/maverics/extensions/authprovider.go

package main

import (
	"errors"
	"net/http"

	"maverics/auth"
	"maverics/session"
)

func IsAuthenticated(op *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) bool {
	return true
}

func Authenticate(ag *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) {
	req.Header.Set("foo", "provider authenticate")
}

func BuildIDTokenClaims(op *auth.OIDCProvider, sess *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"test": "provider ID token claim"}, errors.New("provider test error")
}

func BuildAccessTokenClaims(op *auth.OIDCProvider, sess *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"test": "provider access token claim"}, errors.New("provider test error")
}

/etc/maverics/extensions/alphaClient.go

package main

import (
	"errors"
	"net/http"

	"maverics/auth"
	"maverics/session"
)

func IsAuthenticated(op *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) bool {
	return true
}

func Authenticate(ag *auth.OIDCProvider, rw http.ResponseWriter, req *http.Request) {
	req.Header.Set("foo", "client authenticate")
}

func BuildIDTokenClaims(op *auth.OIDCProvider, sess *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"test": "client ID Token claim"}, errors.New("client test error")
}

func BuildAccessTokenClaims(op *auth.OIDCProvider, sess *session.Session) (map[string]interface{}, error) {
	return map[string]interface{}{"test": "client access token claim"}, errors.New("client test error")
}

Dans l’exemple ci-dessus, les méthodes d’extension de services au niveau du fournisseur seraient analysées, mais étant donné que le client définit ses propres versions de chaque méthode, seules les extensions de services au niveau du client seraient appliquées. Utilisez les méthodes d’extension de services au niveau du fournisseur pour les appliquer à tous les clients ; utilisez les méthodes au niveau du client pour un client spécifique.

Exemples

Configuration standard 

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    wellKnownEndpoint: https://maverics.strata.io/.well-known/openid-configuration
    jwksEndpoint: https://maverics.strata.io/.well-known/jwks.json
    authorizationEndpoint: https://maverics.strata.io/authorize
    tokenEndpoint: https://maverics.strata.io/token
    userInfoEndpoint: https://maverics.strata.io/userinfo
    introspectEndpoint: https://maverics.strata.io/introspect
    issuer: https://maverics.strata.io
    tokenSigning:
      - algorithm: RSA256
        privateKey: <oidcRSATestPrivateKey>

    clients:
      - clientID: exampleID
        clientSecret: <exampleSecret>
        accessToken:
          type: opaque  # opaque or jwt
          length: 32
          lifetimeSeconds: 1800
        refreshToken:
          length: 32
        idTokenLifetimeSeconds: 1800
        redirects:
          - https://app.sonarsystems.com/oidc/callback

        tokenEncryption:
          - algorithm: RSA256
            publicKey: <oidcRSAEncryptionPublicKey>

        authentication:
          idps:
            - azure

        claimsMapping:
          sub: azure.objectidentifier
          email: azure.name
          name:  azure.displayname
          family_name: azure.surname
          given_name: azure.givenname

        allowedAudiences:
          - https://app.sonarsystems.com

        allowOfflineAccess: true

Clients publics et confidentiels avec PKCE

La fonction PKCE est prise en charge par le fournisseur d’authentification OIDC. Pour tous les clients confidentiels, même lorsque la fonction PKCE est utilisée, le secret client_secret est requis pour les requêtes d’authentification et de jeton. Cependant, pour les clients publics, le secret client_secret peut être omis en faveur de la seule communication du code_verifier.

Si la propriété publicClient n’est pas définie, le client sera considéré comme confidentiel.

Exemple de client public :

authproviders:
  - name: exampleOIDCProvider
    type: oidc
    # ...
    clients:
      - clientID: exampleID
        clientSecret: <exampleSecret>
        idTokenLifetimeSeconds: 1800
        redirects:
          - https://app.sonarsystems.com/oidc/callback
        publicClient: true # false by default
Fournisseurs d’authentification SAML (existants)