feat: OIDC: Call userinfo if no claims found in id token

[cmintey]

What this PR does / why we need it:

Some IdPs don't put user claims into the ID token for enhanced security and instead will return the necessary claims from the UserInfo endpoint. There is usually some setting you can change in the IdP to allow sending the claims in the ID token, so this isn't really an issue. However, it makes sense for Mealie to follow this convention and to pull the user info from the UserInfo endpoint. In order to keep compatibility with existing installs (though it shouldn't be breaking), I've decided to add this as a fallback mechanism. If we can't find the claims we need in the ID token, then we will make the necessary call to the UserInfo endpoint of the IdP to obtain them.

Which issue(s) this PR fixes:

N/A

Testing

Tested manually with Authelia 4.38 and 4.39 as well as Authentik, both with and without the option to include claims in the ID token.
Unfortunately, it seems we cannot set up an E2E test for this as the mock OAuth server we use doesn't allow for returning mock data from the UserInfo endpoint

[michael-genson]

Changes LGTM. How much lift would it be to make our own mock server or extend the existing one? If it's too much work I'd be okay with just accepting that we won't test this case, as long as the existing tests are passing (looks like you just pushed a commit to fix those)

[cmintey]

How much lift would it be to make our own mock server or extend the existing one?

Probably would be quite a bit of work to roll our own or extend the existing one. Though we could potentially utilize Authelia (which is what I use in my homelab) as our "mock" server. It's completely configured via YAML and users can also be defined within a file.

Edit: Though with Authelia, we wouldn't be able to test both of these flows without restarting the server or changing the clientId env var in Mealie at runtime

[michael-genson]

That's alright, I think this is fine as-is. If it becomes a bigger problem later down the line maybe we can consider it

[james-d-elliott]

For clarity the intention behind the change is not security but privacy since the information is not necessary to perform the link to a user account.

See Claim Stability and Uniqueness. This section forms the basis for this choice as the ID Token itself doesn't necessarily require user information as the account can be linked without it.

When taking into account the UserInfo Endpoint, the Claim Stability and Uniqueness previously mentioned, and the ID Token combined with Standard Claims; as well as Requesting Claims using the "claims" Request Parameter it seems very apparent the intentions of the spec are to not include extra claims by default but does allow for it.

I believe for these reasons we clearly made an error by including them by default in the base spec, and it also seems clear from the spec the intention is to link accounts in a user flow which links a user intending to log in or already logged in user to the pairwise of iss and / sub claims.