> There's multiple overlapping standards, each with a dozen different variants. The Keycloak OIDC config refers to OAuth2 over a dozen times. To put it simply,

> There's multiple overlapping standards, each with a dozen different variants. The Keycloak OIDC config refers to OAuth2 over a dozen times. To put it simply, OIDC = OAuth2 + id_token (a standard way for the provider to let your client knows who the user is) > There's thousands of blogs and articles, each 1000s of words long and each recommending different things. I have yet to find a concrete guideline for what a 'sane default' set of choices are. There's only one sane default for client-side application: Authorization Code with PKCE > Am I vulnerable to the issue described in the article? I guess I must be, given I don't see the server-side JWT validator doing anything special beyond validating the signature, so there's no validation of whether the token was generated for my app.[1][2] The id_token provide by OIDC has the standard field `aud`, which should contain you `client_id`. Match them together and you can check whether the tokens was issued for your app. > What are best practices for "client scopes"? I notice that the more I add the larger the JWT, but are there any gotchas to watch out for? Best practice for "client scopes" is as small as possible, the only required scope for OIDC is `openid`, which allows you to fetch the `id_token`. Any other scope like `email`, `profile`, etc... is optional, and provider-specific so should be look up from the provider documents.