[7.x] Document support of OIDC Implicit flow in Kibana. (#46329)

Author: azasypkin

docs/reference/settings/security-settings.asciidoc

@@ -1284,9 +1284,9 @@ The OAuth 2.0 Client Secret that was assigned to {es} during registration
 at the OpenID Connect Provider
 
 `rp.redirect_uri`::
-The Redirect URI within {kib}. Typically this is the
-"api/security/v1/oidc" endpoint of your Kibana server. For example,
-`https://kibana.example.com/api/security/v1/oidc`.
+The Redirect URI within {kib}. If you want to use the authorization code flow, this is the
+"api/security/v1/oidc" endpoint of your {kib} server. If you want to use the implicit flow,  it is the "api/security/v1/oidc/implicit" endpoint.
+For example, `https://kibana.example.com/api/security/v1/oidc`.
 
 `rp.response_type`::
 OAuth 2.0 Response Type value that determines the authorization

x-pack/docs/en/security/authentication/oidc-guide.asciidoc

@@ -5,8 +5,7 @@
 
 The Elastic Stack supports single sign-on (SSO) using OpenID Connect via {kib} using
 {es} as the backend service that holds most of the functionality. {kib} and {es}
-together represent an OpenID Connect Relying Party (RP) that supports the Authorization
-Code Flow as this is defined in the OpenID Connect specification.
+together represent an OpenID Connect Relying Party (RP) that supports the authorization code flow and implicit flow as these are defined in the OpenID Connect specification.
 
 This guide assumes that you have an OpenID Connect Provider where the
 Elastic Stack Relying Party will be registered.
@@ -39,8 +38,8 @@ RP that you commonly need to provide for registration are the following:
 nor the Elastic Stack implementation impose any constraints on this value.
 - `Redirect URI`: This is the URI where the OP will redirect the user's browser after authentication. The
 appropriate value for this will depend on your setup and whether or not {kib} sits behind a proxy or
-load balancer. It will typically be +$\{kibana-url}/api/security/v1/oidc+ where _$\{kibana-url}_
-is the base URL for your {kib} instance. You might also see this called `Callback URI`.
+load balancer. It will typically be +$\{kibana-url}/api/security/v1/oidc+ (for the authorization code flow) or +$\{kibana-url}/api/security/v1/oidc/implicit+ (for the implicit flow) where _$\{kibana-url}_  is the base URL for your {kib} instance. You might also see this
+called `Callback URI`.
 
 At the end of the registration process, the OP will assign a Client Identifier and a Client Secret for the RP ({stack}) to use.
 Note these two values as they will be used in the {es} configuration.
@@ -158,8 +157,8 @@ op.authorization_endpoint::
 
 op.token_endpoint::
     The URL for the Token Endpoint in the OpenID Connect Provider. This is the endpoint where
-    {es} will send a request to exchange the code for an ID Token, in the case where the Authorization Code
-    flow is used. The value for this setting should be provided by your OpenID Connect Provider.
+    {es} will send a request to exchange the code for an ID Token.  This setting is optional when
+    you use the implicit flow. The value for this setting should be provided by your OpenID Connect Provider.
 
 op.jwkset_path::
     The path to a file or a URL containing a JSON Web Key Set with the key material that the OpenID Connect
@@ -522,23 +521,23 @@ The three additional settings that are required for OpenID Connect support are s
 
 [source, yaml]
 ------------------------------------------------------------
-xpack.security.authProviders: [oidc]
+xpack.security.authc.providers: [oidc]
 xpack.security.authc.oidc.realm: "oidc1"
 server.xsrf.whitelist: [/api/security/v1/oidc]
 ------------------------------------------------------------
 
 The configuration values used in the example above are:
 
-`xpack.security.authProviders`::
+`xpack.security.authc.providers`::
 Set this to `[ oidc ]` to instruct {kib} to use OpenID Connect single sign-on as the
 authentication method. This instructs Kibana to attempt to initiate an SSO flow
 everytime a user attempts to access a URL in Kibana, if the user is not already
 authenticated. If you also want to allow users to login with a username and password,
-you must enable the `basic` authProvider too. For example:
+you must enable the `basic` authentication provider too. For example:
 
 [source, yaml]
 ------------------------------------------------------------
-xpack.security.authProviders: [oidc, basic]
+xpack.security.authc.providers: [oidc, basic]
 ------------------------------------------------------------
 
 This will allow users that haven't already authenticated with OpenID Connect to
@@ -552,8 +551,8 @@ for this Kibana instance.
 {kib} has in-built protection against _Cross Site Request Forgery_ attacks, which
 is designed to prevent the {kib} server from processing requests that
 originated from outside the {kib} application.
-In order to support OpenID Connect messages that originate from your
-OP or a third party (see <<third-party-login>>, we need to explicitly _whitelist_ the
+If you use the authorization code flow, {kib} needs to support unsolicited messages that originate from your
+OP or a third party (see <<third-party-login>>). In order to do so, you must explicitly _whitelist_ the
 OpenID Connect authentication endpoint within {kib}, so that the {kib} server will
 not reject these external messages.