--- title: "OpenID Connect authentication" method: GET path: "/credentials/oidc" tags: ["Account Management"] --- # OpenID Connect authentication `GET /credentials/oidc` Lists the supported [OpenID Connect](http://openid.net/connect/) providers (OP). OpenID Connect Providers MUST support [OpenID Connect Discovery](http://openid.net/specs/openid-connect-discovery-1_0.html). It is highly RECOMMENDED to implement OpenID Connect for public services in favor of Basic authentication. openEO clients MUST use the **access token** as part of the Bearer token for authorization in subsequent API calls (see also the information about Bearer tokens in this document). Clients MUST NOT use the id token or the authorization code. Back-ends MAY request user information ([including Claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims)) from the [OpenID Connect Userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) using the access token (without the prefix described above). Therefore, both openEO client and openEO back-end are relying parties (clients) to the OpenID Connect Provider. ## Response `200` Lists the OpenID Connect Providers. - object - `providers` object[], required — The first provider in this list is the default provider for authentication. Clients can either pre-select or directly use the default provider for authentication if the user does not specify a specific value. - `id` string, required — A per-back-end **unique** identifier for the OpenID Connect provider. Is used as prefix for the openEO token. - `issuer` string, uri, required — The [issuer location](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) (also referred to as 'authority' in some client libraries) is the URL of the OpenID Connect provider, which conforms to a set of rules: 1. After appending `/.well-known/openid-configuration` to the URL, a [HTTP/1.1 GET request](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) to the concatenated URL MUST return a [OpenID Connect Discovery Configuration Response](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse). The response provides all information required to authenticate using OpenID Connect. 2. The URL MUST NOT contain a terminating forward slash `/`. - `scopes` string[] — A list of OpenID Connect scopes that the client MUST at least include when requesting authorization. Clients MAY add additional scopes such as the `offline_access` scope to retrieve a refresh token. If scopes are specified, the list MUST at least contain the `openid` scope. - `title` string, required — The name that is publicly shown in clients for this OpenID Connect provider. - `description` string, commonmark — A description that explains how the authentication procedure works. It should make clear how to register and get credentials. This should include instruction on setting up `client_id`, `client_secret` and `redirect_uri`. [CommonMark 0.29](http://commonmark.org/) syntax MAY be used for rich text representation. - `default_clients` object[] — List of default OpenID Connect clients that can be used by an openEO client for OpenID Connect based authentication. A default OpenID Connect client is managed by the back-end implementer. It MUST be configured to be usable without a client secret, which limits its applicability to OpenID Connect grant types like "Authorization Code Grant with PKCE" and "Device Authorization Grant with PKCE" A default OpenID Connect client is provided without availability guarantees. The back-end implementer CAN revoke, reset or update it any time. As such, openEO clients SHOULD NOT store or cache default OpenID Connect client information for long term usage. A default OpenID Connect client is intended to simplify authentication for novice users. Setting up a dedicated OpenID Connect client is RECOMMENDED for production-ready back-ends. - `id` string, required — The OpenID Connect Client ID to be used in the authentication procedure. - `grant_types` string[], required — List of authorization grant types (flows) supported by the OpenID Connect client. A grant type descriptor consist of a OAuth 2.0 grant type, with an additional `+pkce` suffix when the grant type should be used with the PKCE extension as defined in [RFC 7636](https://www.rfc-editor.org/rfc/rfc7636.html). Allowed values: - `implicit`: Implicit Grant as specified in [RFC 6749, sec. 1.3.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-1.3.2) - `authorization_code` / `authorization_code+pkce`: Authorization Code Grant as specified in [RFC 6749, sec. 1.3.1](https://www.rfc-editor.org/rfc/rfc6749.html#section-1.3.1), with or without PKCE extension. - `urn:ietf:params:oauth:grant-type:device_code` / `urn:ietf:params:oauth:grant-type:device_code+pkce`: Device Authorization Grant (aka Device Code Flow) as specified in [RFC 8628](https://www.rfc-editor.org/rfc/rfc8628.html), with or without PKCE extension. Note that the combination of this grant with the PKCE extension is *not standardized* yet. - `refresh_token`: Refresh Token as specified in [RFC 6749, sec. 1.5](https://www.rfc-editor.org/rfc/rfc6749.html#section-1.5) - `redirect_urls` string[] — List of redirect URLs that are whitelisted by the OpenID Connect client. Redirect URLs MUST be provided when the OpenID Connect client supports the Implicit Grant or the Authorization Code Grant (with or without PKCE extension). - `authorization_parameters` object — Additional parameters that an openEO client MUST include when requesting the authorization endpoint. This can be used to enforce specific [request parameters such as `prompt`](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). - `links` Link[] — Links related to this provider, for example a help page or a page to register a new user account. For relation types see the lists of [common relation types in openEO](#section/API-Principles/Web-Linking). - `rel` string, required — Relationship between the current document and the linked document. SHOULD be a [registered link relation type](https://www.iana.org/assignments/link-relations/link-relations.xml) whenever feasible. - `href` string, uri, required — The value MUST be a valid URL. - `type` string — The value MUST be a string that hints at the format used to represent data at the provided URI, preferably a media (MIME) type. - `title` string — Used as a human-readable label for a link. ## Other responses - `4XX` — The request can not be fulfilled due to an error on client-side, i.e. the request is invalid. The client SHOULD NOT repeat the request without modifications. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). This request MUST respond with HTTP status codes 401 if authorization is required or 403 if the authorization failed or access is forbidden in general to the authenticated user. HTTP status code 404 SHOULD be used if the value of a path parameter is invalid. See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json) - `5XX` — The request can not be fulfilled due to an error at the back-end. The error is never the client’s fault and therefore it is reasonable for the client to retry the exact same request that triggered this response. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json) --- [API](https://skmtc.net/open-eo/apis/openeo-api.md) · [All operations](https://skmtc.net/open-eo/apis/openeo-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/open-eo/openeo-api/revisions/0c5e31955a19/schema)