Update README.MD

spring-addons-starter-oidc/README.MD

@@ -481,7 +481,7 @@ On a Spring OAuth2 client with `oauth2Login`, OpenID auto-configuration relies o
 ### <a name="2-11"/>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/` => 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.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/"`
 
 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)).