<commit_before># Client Metadata-based CORS Origin whitelist

- built for version: ^6.0.0
- no guarantees this is bug-free

The following OIDC routes are CORS-enabled and by default have all origins whitelisted. This works
for developing and testing but at some point you might want to restrict the origins.

These endpoints have CORS enabled from all origins all the time, no real reason to restrict it.
- certificates (`jwks_uri`)
- discovery (`/.well-known/openid-configuration`)

These endpoints have CORS enabled from all origins by default, but as these always get their origin
client resolved during the request (either through client authentication or the token's client).

- `device_authorization_endpoint`
- `introspection_endpoint`
- `revocation_endpoint`
- `token_endpoint`
- `userinfo_endpoint`

Since neither one of the specifications defines a field client's allowed CORS origins here's how to
implement a custom client metadata field and have it used during CORS requests (both actual and
preflights).<commit_msg>docs: update client based origins md<commit_after># Client Metadata-based CORS Origin whitelist

- built for version: ^6.0.0
- no guarantees this is bug-free

OIDC routes that are ever needed to be called from a browser user-agent are CORS-enabled and by
default have all origins whitelisted. This works for developing and testing but at some point you
might want to restrict the call's origins.

These endpoints have CORS enabled from all origins all the time, no real reason to restrict it:

- certificates (`jwks_uri`)
- discovery (`/.well-known/openid-configuration`)

These endpoints have CORS enabled from all origins by default:

- `device_authorization_endpoint`
- `introspection_endpoint`
- `revocation_endpoint`
- `token_endpoint`
- `userinfo_endpoint`

As these always get their client resolved during the request (either through client authentication
or the token's client) you can use any mechanism available to you to have them fail the moment
client is identified. In this recipe we'll use a custom client metadata to register an array of
origins that will be allowed when  encountered, otherwise the requests will fail.

Since neither one of the specifications defines metadata for client's allowed CORS origins here's
how to implement a custom client metadata field and have it used during CORS requests (both actual
and preflights).
{'fraction_non_alphanumeric': 0.05044136191677175, 'fraction_numerical': 0.0025220680958385876, 'mean_word_length': 4.8765432098765435, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5876993', 'n_tokens_mistral': 609, 'n_tokens_neox': 583, 'n_words': 323}