{{- $clientID := .Get "client_id" | default "example" }} {{- $policy := .Get "policy_name" | default $clientID }} {{- $claims := .Get "claims" | default "rat,groups,email,email_verified,alt_emails,preferred_username,name" }} {{- $example := .Get "example" }}

Potential Escape Hatch Configuration Required

Unfortunately at the time of writing this integration this client does not support OpenID Connect 1.0. Fortunately Authelia has implemented an escape hatch that works for most clients which don't properly support OpenID Connect 1.0. This requires additional configuration to that which is described above. You can read more about this in the OpenID Connect 1.0 Claims Guide.

Clients are required to operate under the assumption that claims requested by scope values are available by using the Access Token (the scope is granted and issued to the Access Token) at the UserInfo Endpoint as described by 5.4. Requesting Claims using Scope Values with the exception of an Implicit Flow that does not return an Access Token, or explicitly request them via the claims parameter as described by 5.5. Requesting Claims using the "claims" Request Parameter .

The requirement to use this option is also often a clear indication the client also ignores the claims stability requirements which only allows clients to anchor accounts via the sub and iss claims. This requirement is strictly required by the specification.

Both of these elements are clear indications the client does not properly support OpenID Connect 1.0 and is not conformant.

The following is an example of adaptation to the above configuration that works around the fact this client does not support OpenID Connect 1.0: {{- if not (eq $example "disable") }} ```yaml identity_providers: oidc: claims_policies: {{ $policy }}: id_token: ['{{ delimit (split $claims ",") "', '" | safeHTML }}'] clients: - client_id: '{{ $clientID }}' claims_policy: '{{ $policy }}' ``` {{- end }}