fix: 3LO secrets by name, and provider config that actually renders

[Robobc]

What

The Google/GitHub/Notion 3LO credential providers had two defects, one hiding the other.

The one we went looking for: client secrets travelled as plaintext (-c google_client_secret / GOOGLE_CLIENT_SECRET) and were rendered verbatim into the synthesized template — the same exposure class already closed for the enterprise-IdP secret.

The one we found underneath: the provider config was passed as a raw dict whose top-level key spelled OAuth with a capital A, which doesn't match the CloudFormation model. The L1 mapping silently dropped the entire block — every 3LO provider synthesized with Oauth2ProviderConfigInput: {}. They could never have worked, and nothing failed: deploys were green, the providers just had no configuration.

Fixes (all following existing precedent in this repo)

• identity_stack takes *_client_secret_name and renders {{resolve:secretsmanager:...}} dynamic references, exactly like the auth stack's IdP secret. A client_id without a secret name fails at synth with an actionable message.
• Typed L1 property classes replace the raw dicts, so a wrong key raises at synth instead of vanishing. Google/GitHub use their vendor configs (the Token Vault knows their endpoints). Notion publishes no OIDC discovery document, so it's CustomOauth2 with explicit authorization/token endpoints — the same shape as the deployed-and-working gateway M2M provider.
• The old scopes lists were dead weight inside the dropped dicts: scopes are requested per token via @requires_access_token(scopes=[...]), not stored on the provider. Not carried over.
• app.py rejects the plaintext keys outright and reads the names through cfg(), so platform.yaml participates.
• deploy.sh: upsert_oauth_secret generalizes the IdP upsert (whitespace trim, bring-your-own secret name, plaintext unset after storing) and upsert_3lo_secrets covers the three vendors. The secret name is exported, not just assigned — CDK invocations that carry no context args (the bootstrap probe synthesizes the app too) must see it; found live when the first deploy failed only at the bootstrap step.

Verified live

Deployed to a test environment with GITHUB_CLIENT_ID and a secret carrying a trailing newline:

Check	Result
Provider created as GithubOauth2 with real vendor config	pass — was {} before this change
Secrets Manager holds the trimmed value	20 chars, newline gone
The deployed CloudFormation template (via get-template)	dynamic reference present, no plaintext
CfnOAuth2CredentialProvider accepts the dynamic reference	UPDATE_COMPLETE, both directions

Environment restored afterwards: provider removed, test secret deleted, health invoke green.

Checks

• Check (m) in check-deploy-config.sh: trim + naming + plaintext-unset across all three vendors, asserting on the arguments passed to the stubbed CLI.
• tests/test_3lo_providers.py: static guards — no plaintext secret parameters, dynamic references present, the raw-dict key cannot come back, deploy.sh passes names only.
• The test_platform_config cfg-guard tightened: its old allowlist entries for the 3LO lookups are gone (they now go through cfg()); the only exception left is the plaintext-rejection loop, which deliberately probes keys that must not resolve.
• 120 tests green, ruff and shellcheck clean.

[github-actions]

Commit: 06f6899 | Updated: 2026-08-23 20:19:51 UTC

Security Scan Results

Scanner	S	C	H	M	L	I	Time	Action	Result	Thresh
bandit	0	0	0	0	53	0	608ms	0	PASSED	MED (g)
cdk-nag	0	0	0	0	0	0	4.0s	0	PASSED	MED (g)
cfn-nag	0	0	0	0	0	0	4ms	0	PASSED	MED (g)
checkov	0	0	0	0	0	0	4.3s	0	PASSED	MED (g)
detect-secrets	0	5	0	0	0	0	603ms	5	FAILED	MED (g)
grype	0	0	0	0	0	0	37.3s	0	PASSED	MED (g)
npm-audit	0	0	0	0	0	0	114ms	0	PASSED	MED (g)
opengrep	0	0	0	0	0	0	10.1s	0	PASSED	MED (g)
semgrep	0	0	0	0	0	0	<1ms	0	MISSING	MED (g)
syft	0	0	0	0	0	0	1.2s	0	PASSED	MED (g)