Emphasise that OIDC is only for interactive users (#3875)

OpenID Connect is a protocol for authenticating interactive users.
However, because identity platforms that support OIDC often support
other protocols that can be used for non-interactive users, it is common
for readers to end up on the OIDC page looking for ways to authenticate
non-interactive users.

The docs attempt to correct this misconception by refering to a "web
application" but that was easy to miss. This change makes it more
explicit that OIDC is not a viable option for service authentication and
recommends JWT instead.

Author: tvernum

deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

@@ -470,6 +470,13 @@ xpack.security.authc.providers:
 
 The OpenID Connect realm is designed to allow users to authenticate to {{kib}}. As a result, most sections of this guide assume {{kib}} is used. This section describes how a custom web application could use the relevant OpenID Connect REST APIs to authenticate the users to {{es}} with OpenID Connect.
 
+::::{note}
+The OpenID Connect protocol enables authentication for interactive users through a web browser. Users must be able to open a login URL in their browser and enter credentials when prompted.
+
+{{es}} does not support using OpenID Connect to authenticate non-interactive users such as service principals or automated processes. If you want to authenticate a service, the [JWT](jwt.md) realm might be a suitable alternative.
+The JWT realm is able to authenticate tokens that are produced by OpenID Connect providers.
+::::
+
 Single sign-on realms such as OpenID Connect and SAML make use of the Token Service in {{es}} and in principle exchange a SAML or OpenID Connect Authentication response for an {{es}} access token and a refresh token. The access token is used as credentials for subsequent calls to {{es}}. The refresh token enables the user to get new {{es}} access tokens after the current one expires.
 
 ::::{note}