Minor updates to OIDC docs (#6551)

website/source/api/auth/jwt/index.html.md

@@ -102,8 +102,8 @@ entities attempting to login. At least one of the bound values must be set.
 ### Parameters
 - `name` `(string: <required>)` - Name of the role.
 - `role_type` `(string: <optional>)` - Type of role, either "oidc" (default) or "jwt".
-- `bound_audiences` `(array: <required>)` - List of `aud` claims to match
-  against. Any match is sufficient.
+- `bound_audiences` `(array: <optional>)` - List of `aud` claims to match against.
+   Any match is sufficient. Required for "jwt" roles, optional for "oidc" roles. 
 - `user_claim` `(string: <required>)` - The claim to use to uniquely identify
   the user; this will be used as the name for the Identity entity alias created
   due to a successful login. The claim value must be a string.

website/source/docs/auth/jwt.html.md

@@ -164,6 +164,8 @@ why things aren't working. Some tips for setting up OIDC:
 http/https, 127.0.0.1/localhost, port numbers, whether trailing slashes are present.
 - Start simple. The only claim configuration a role requires is `user_claim`. After authentication is
 known to work, you can add additional claims bindings and metadata copying.
+- `bound_audiences` is optional for OIDC roles and typically not required. OIDC providers will use
+the client_id as the audience and OIDC validation expects this.
 - If you're seeing claim-related errors in logs, review the provider's docs very carefully to see
 how they're naming and structuring their claims. Depending on the provider, you may be able to
 construct a simple `curl` implicit grant request to obtain a JWT that you can inspect. An example