Concept

OpendID Connect is a standard for authentication at an HTTP endpoint/resource server (here Lobster Integration).

The idea is that an HTTP endpoint/resource server no longer has to manage authorised clients itself and, for example, check credentials such as user name and password. Instead, authentication is carried out by a third party (OpenID provider). Well-known examples of this are Azure Entry (formerly Azure Active Directory) or Auth0.

The entire process is an additional layer on top of the familiar OAuth2 technology with authorisation code and the concepts of an authorisation and token URL. The OpenID provider also generates the access token, which the HTTP client then transfers to the desired resource server (here Lobster Integration). Upon receiving the request, the resource server then checks whether the requester is authorised to access the resource, using the access token received from the OpenID provider.

OpenID itself does not provide any information on how to check an access token. However, the token introspection procedure in accordance with RFC7662 has become established as best practice. Here, the access token is transmitted in the industry standard JSON Web Token (JWT). This is a structure that is available as machine-readable JSON and contains all the necessary information for the recipient. A key aspect here is that the structure has been digitally signed by the OpenID provider and can therefore no longer be subsequently changed (integrity) and also ensures the identity of the owner. Details on the standard can be found at https://jwt.io/, for example. With the information in the JSON Web Token, the resource server (here Lobster Integration) can now check whether an authorisation exists using the JSON fields "Audience" and "Issuer" it contains (called claims in JSON Web Token jargon). The JSON Web token also contains information on when the token was issued and how long it is valid for. The "Audience" is usually a unique identifier that is specified in the OpenID provider configuration for the use case (e.g. the application ID for Azure), while the "Issuer" is a unique identifier of the OpenID provider.

To ensure the trustworthiness of the token, the recipient (here Lobster Integration) can check the signature of the JSON Web Token with the publicly available certificate (from the OpenID provider). The entire procedure is based on the trust that the issuer of the token is authorised to use the endpoint.

Configuration in HTTP channel

In the concept described above, the role of Lobster Integration is to be seen as an HTTP endpoint/resource server, as already described. Unlike the HTTP authentication methods Basic/Digest or the OAuth2 server service, no further information about the user is available.

OpenID must be configured for an "HTTP" channel via the following dialogue.