[Bug Report]: OIDC autodiscovery fails in Azure environment #2610

New Issue

OVERLORD · 2026-02-05T04:37:01+03:00

OVERLORD commented

2026-02-05 04:37:01 +03:00

Originally created by @ssddanbrown on GitHub (Jan 27, 2022).

Originally assigned to: @ssddanbrown on GitHub.

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:

6e325de226/app/Auth/Access/Oidc/OidcProviderSettings.php (L166-L168)

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)

Originally created by @ssddanbrown on GitHub (Jan 27, 2022). Originally assigned to: @ssddanbrown on GitHub. ### Describe the Bug Microsoft can provide the following format at its jwks_uri: ```json { "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: https://github.com/BookStackApp/BookStack/blob/6e325de226fd930dae481a13ba80e002c6214a74/app/Auth/Access/Oidc/OidcProviderSettings.php#L166-L168 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)

OVERLORD added the 🐛 Bug 🚪 Authentication 🏭 Back-End labels 2026-02-05 04:37:01 +03:00

OVERLORD closed this issue

2026-02-05 04:37:04 +03:00

OVERLORD commented

2026-02-05 04:37:08 +03:00

@ssddanbrown commented on GitHub (Jan 27, 2022):

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:

024924eef3/app/Auth/Access/Oidc/OidcJwtSigningKey.php (L63-L65)

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

https://github.com/awslabs/aws-jwt-verify/issues/6
https://github.com/jpadilla/pyjwt/issues/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.

@ssddanbrown commented on GitHub (Jan 27, 2022): ### 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: https://github.com/BookStackApp/BookStack/blob/024924eef38179ecb12ef5cd6d7bcdcb8c15a298/app/Auth/Access/Oidc/OidcJwtSigningKey.php#L63-L65 For comparison, example jwks_uri return content from okta: ```json { "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 https://github.com/awslabs/aws-jwt-verify/issues/6 https://github.com/jpadilla/pyjwt/issues/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.

OVERLORD referenced this issue

2026-02-05 10:23:00 +03:00

[PR #2610] [CLOSED] Added Sitemap generator #6029

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2610