From 2a5a039d905ea096264b288156ab62db1598d708 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Wacongne?= Date: Mon, 7 Oct 2024 13:32:24 -1000 Subject: [PATCH] Update README.MD --- spring-addons-starter-oidc/README.MD | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spring-addons-starter-oidc/README.MD b/spring-addons-starter-oidc/README.MD index 1718b58cc..f0e688e24 100644 --- a/spring-addons-starter-oidc/README.MD +++ b/spring-addons-starter-oidc/README.MD @@ -480,11 +480,11 @@ On a Spring OAuth2 client with `oauth2Login`, OpenID auto-configuration relies o ### Why can't I get things working easily with Microsoft authorization servers? Microsoft authorization servers (like Entra ID, formerly known as Azure Active Directory, or AAD, or Azure AD B2C, etc.), look like OIDC Providers but aren't. [The OIDC discovery spec](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) states that *"OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string `/.well-known/openid-configuration` to the Issuer"*. Also, [the OpenID token validation spec](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) requires that *"The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim"*. The candidates for the *Issuer Identifier* of the Entra ID instance with `4f68014f-7f14-4f89-8197-06f0b3ff24d9` as tenant ID look as follows: -- `https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/` -- `https://login.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9` -- `https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0` +- `https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/` => the issuer on [the discovery endpoint](https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9//.well-known/openid-configuration) and in ID tokens claims are the expected ones, but we won't get JWT access tokens using the `token_endpoint` & `authorization_endpoint` listed in the OpenID configuration. +- `https://login.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9 => tokens are opaque and [the OpenID configuration](https://login.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/.well-known/openid-configuration) contains `"issuer": "https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/"` +- `https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0` => the [OpenID configuration](https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0/.well-known/openid-configuration) contains the expected issuer and we get access tokens in the JWT format but with `"iss": "https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/"` -But whatever we use, we can't be issued JWT access tokens and have a match of the *Issuer Identifier* between the discovery URI, the OpenID configuration payload, and tokens `iss` claim. Sometimes, the discovery URI is not even standard (there are samples of [AAD B2C with request parameters like `?p=B2C_1_signupsignin`](https://learningakash.b2clogin.com/learningakash.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signupsignin)). +So, whatever we use, we can't be issued JWT access tokens and have a match of the *Issuer Identifier* between the discovery URI, the OpenID configuration payload, and tokens `iss` claim. Sometimes, the discovery URI is not even standard (there are samples of [AAD B2C with request parameters like `?p=B2C_1_signupsignin`](https://learningakash.b2clogin.com/learningakash.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_signupsignin)). A workaround is to disable OIDC discovery and replace the default JWT decoder with one skipping issuer validation (see [Is `iss` configuration property mandatory?](#2-10)), which is unsafe. A better option is to **use an actual OIDC Provider** like Keycloak, Spring Authorization Server, Auth0, Amazon Cognito, etc.. About anything but a Microsoft product. In the case where the Microsoft authorization server can't be removed (for instance if this is where corporate users are stored), we can still hide it behind a decent OIDC Provider. If the Microsoft authorization server is the sole identity source for an actual OpenID Provider, this can be transparent for end-users, and Spring applications can stick to OIDC.