SSO-OIDC client example tokens trip secret scanners (Trivy jwt-token, gitleaks) — redact JWT-shaped values in the service model

Start with the canonical SSO-OIDC service model, examples-1.json, and inspect the id_token, assertion, and client_secret examples described in the issue. Verify the generated lib/aws-sdk-ssooidc/client.rb output and run the Trivy secret-scan reproduction; done means the examples remain useful placeholders without JWT-token findings.

Describe the feature

The generated Aws::SSOOIDC::Client documentation embeds realistic-looking JWTs in its @example blocks for create_token and create_token_with_iam. Because these are full eyJ…-shaped tokens rather than obvious placeholders, secret scanners flag them as leaked credentials when they scan an application's installed gems / built container image.

Concretely, scanning an image that bundles aws-sdk-core (3.251.0) with Trivy's secret scanner produces a false positive on lib/aws-sdk-ssooidc/client.rb via the built-in jwt-token rule. The same false positive is reproducible with gitleaks and other regex-based scanners, and the same example values appear in aws-sdk-js-v3 and botocore, so this affects downstream consumers across all AWS SDKs.

These are clearly intentional example values (account 123456789012, ssoins-111111111111, the Microsoft AbeLi@microsoft.com sample OIDC token, etc.), so this is a documentation-quality / false-positive-noise issue, not a leaked secret.

Affected examples

In aws-sdk-core 3.251.0, lib/aws-sdk-ssooidc/client.rb (generated from the SSO-OIDC examples-1.json model, API version 2019-06-10):

• id_token in the example responses (the create_token_with_iam authorization-code, JWT-bearer, and token-exchange grant examples)
• assertion in the JWT-bearer grant example request
• client_secret in the create_token example requests (VERYLONGSECRETeyJ…)

Note the inconsistency: the neighboring access_token, refresh_token, and authorization code examples already end in explicit …EXAMPLEACCESSTOKEN / …EXAMPLEREFRESHTOKEN / …EXAMPLEAUTHCODE markers, but the JWT-shaped values do not, which is exactly why scanners single them out.

Proposed change

Redact the JWT-shaped example values in the canonical SSO-OIDC service model (examples-1.json) so they are unmistakably non-secret while still illustrating the field shape — for example a short, obviously-fake stub such as eyJhbGciOiJub25lIn0.eyJzdWIiOiJFWEFNUExFIn0.EXAMPLE or a <id-token>-style placeholder — matching the EXAMPLE… convention already used for the surrounding tokens. Because the SDK clients are generated from this shared model, fixing it upstream propagates to all SDKs.

Reproduction

trivy fs --scanners secret <path-to-bundled-gems>/aws-sdk-core-3.251.0
# or against an image that bundles the gem:
trivy image --scanners secret <image>
# -> JWT (jwt-token) finding on lib/aws-sdk-ssooidc/client.rb

Environment

• aws-sdk-core 3.251.0
• Trivy 15.0.7 (jwt-token secret rule); also reproducible with gitleaks