Improve wording to avoid implying pinniped is used either way. (#5695)

Signed-off-by: Michael Nelson <minelson@vmware.com>

<!--
Before you open the request please review the following guidelines and
tips to help it be more easily integrated:

 - Describe the scope of your change - i.e. what the change does.
 - Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.

 Thank you for contributing!
 -->

### Description of the change

<!-- Describe the scope of your change - i.e. what the change does. -->
While chatting about [OIDC
configuration](#5671 (comment))
with @RGPosadas I was looking through the docs and found that it reads
currently as if you should use Pinniped either way.

This change just clears that up a bit, I hope, so that people use the
cluster's own OIDC support when they can, and pinniped when they can't.

### Benefits

<!-- What benefits will be realized by the code change? -->

### Possible drawbacks

<!-- Describe any known limitations with your change -->

### Applicable issues

<!-- Enter any applicable Issues here (You can reference an issue using
#) -->

- ref #5671

### Additional information

<!-- If there's anything else that's important and relevant to your pull
request, mention that information here.-->

Signed-off-by: Michael Nelson <minelson@vmware.com>

site/content/docs/latest/tutorials/using-an-OIDC-provider.md

@@ -18,7 +18,7 @@ _OpenID Connect (OIDC)_ is a simple identity layer on top of the OAuth 2.0 proto
 
 In Kubernetes, one of the authentication strategies for incoming requests to the API server is using [OpenID Connect tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). The cluster can be configured to trust an external OIDC provider so that authenticated requests can be matched with defined RBAC. Additionally, some managed Kubernetes environments enable authenticating via plain OAuth2.
 
-However, for Kubernetes to be able to use OIDC-based authentication it is required to [enable certain flags in the API server](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server), which is not always possible on certain environments (such as managed Kubernetes distributions by a cloud provider). To work around this limitation, it is recommended having a look at the [Pinniped project](https://pinniped.dev/).
+However, for Kubernetes to be able to use OIDC-based authentication it requires you being able to [enable certain flags in the API server](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server), which is not always possible on certain environments (such as managed Kubernetes distributions by a cloud provider). If you are unable to configure your cluster's API server flags for OIDC, then it is recommended that you have a look at the [Pinniped project](https://pinniped.dev/), which enables dynamic OIDC authentication configuration of clusters.
 
 This tutorial describes how to use an existing OAuth2 provider, including OIDC, to authenticate users within Kubeapps.
 
@@ -75,7 +75,6 @@ The main difference in the authentication is that instead of accessing the Kubea
 
 There are a number of available solutions for this use-case, like [keycloak-gatekeeper](https://github.com/keycloak/keycloak-gatekeeper) or [oauth2_proxy](https://github.com/oauth2-proxy/oauth2-proxy).
 
-
 The next sections explain how you can deploy this proxy either using the Kubeapps chart or manually:
 
 - [Using Kubeapps chart](../howto/OIDC/OAuth2OIDC-oauth2-proxy.md#using-the-chart)