Update README.MD

spring-addons-starter-oidc/README.MD

@@ -481,13 +481,13 @@ This seems dumb but will work in a single tenant scenario: the 1st (and only) Op
 On a Spring OAuth2 client with `oauth2Login`, OpenID auto-configuration relies on the *Issuer Identifier* to be set as `spring.security.oauth2.client.provider.{provider-id}.issuer-uri`. If for some reason the authorization server is not accessible using the *Issuer Identifier* (misconfigured containerized environments) or does not match the OpenID spec (Microsoft), we should leave the `issuer-uri` empty, and manually provide URIs for `authorization`, `token`, `jwk-set`, and `userinfo` endpoints instead of relying on OpenID auto-configuration.
 
 ### <a name="2-11"/>Why can't I get things working easily with Microsoft authorization servers?
-Microsoft Entra ID (formerly known as Azure Active Directory, or AAD, or Azure AD B2C, etc.),  looks like an OIDC Provider, but isn'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) reqsuires that *"The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim"*. 
-
-But whatever we take as *Issuer Identifier* for a Microsoft Entra ID instance, 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. The candidates for the *Issuer Identifier* from which we can build a discovery URI look as follows:
+Microsoft Entra ID (formerly known as Azure Active Directory, or AAD, or Azure AD B2C, etc.),  looks like an OIDC Provider, but isn'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* from which we can build a discovery URI 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`
 
+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.
+
 A workaround is to replace the default JWT decoder with one skipping issuer validation (see [Is `iss` configuration property mandatory?](#2-10)). But this makes your Relying Party voluntarily opt out of the OpenID specification and 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 you really have to use a Microsoft authorization server, 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 your Spring applications can stick to OIDC.
 
 ### <a name="usage"/>3. Basic Usage