[Bug Report]: OIDC autodiscovery fails in Azure environment

[ssddanbrown]

Describe the Bug

Microsoft can provide the following format at its jwks_uri:

{
      "kty": "RSA",
      "use": "sig",
      "kid": "abcabcabc",
      "x5t": "abcabcabc",
      "n": "xxxxyyyyyzzzz",
      "e": "AQAB",
      "x5c": [
        "aaaabbbbcccc"
      ],
      "issuer": "https://login.microsoftonline.com/xxx-xxx-xxx/v2.0"
    }

We have the following logic to filter keys to the compatible ones:

BookStack/app/Auth/Access/Oidc/OidcProviderSettings.php

Lines 166 to 168 in 6e325de

	return array_filter($keys, function (array $key) {
	return $key['kty'] === 'RSA' && $key['use'] === 'sig' && $key['alg'] === 'RS256';
	});

This fails due to the alg property being non-existent.

Couple of things we need to do:

• Check MS provided keys against the standard, support their format if we can identity.
• Update our filtering to not hard fail on potentially non-assured properties (Relevant to the spec)

[ssddanbrown]

Research

From https://www.rfc-editor.org/rfc/rfc7517.html#section-4.4, in reference to the alg parameter:

Use of this member is OPTIONAL.

Another location in the code will need adjustment:

BookStack/app/Auth/Access/Oidc/OidcJwtSigningKey.php

Lines 63 to 65 in 024924e

	if ($jwk['alg'] !== 'RS256') {
	throw new OidcInvalidKeyException("Only RS256 keys are currently supported. Found key using {$jwk['alg']}");
	}

For comparison, example jwks_uri return content from okta:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "kid": "ddeeff",
      "use": "sig",
      "e": "AQAB",
      "n": "aabbcc"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "kid": "bbccdd",
      "use": "sig",
      "e": "AQAB",
      "n": "aabbccc"
    }
  ]
}

Found this as a good example of endpoint of Azure's keys:
https://login.microsoftonline.com/common/discovery/v2.0/keys

Similar Cases

awslabs/aws-jwt-verify#6
jpadilla/pyjwt#603

Likely Path Forward

Think we'll need to assume that a kty=RSA and a non-set alg is essentially the same as RS256. Doing this should not affect existing use and should error down the chain if the key cannot be parsed anyway. Seems a bit tricky/short-sighted for MS not to provide the exact alg though, not sure what their approach may be once the provide additional types of RSA keys.