BFF tutorial with Azure Entra ID External

[hajekt2]

I am trying to configure Azure Entra ID External in the setup based on BFF tutorial from Baeldung (https://www.baeldung.com/spring-cloud-gateway-bff-oauth2)
I believe I am struggling with the correct configuration for Azure. Tried a lot of different variants.

Now I have this config in bff:

issuer: https://{tenantId}.ciamlogin.com/{tenantId}/v2.0
spring:
    security:
        oauth2:
            client:
                provider:
                    azure:
                        issuer-uri: ${issuer}
                registration:
                    azure:
                        provider: azure
                        authorization-grant-type: authorization_code
                        client-id: ${client-id}
                        client-secret: ${client-secret}
                        scope: openid,profile,email,offline_access
com:
  c4-soft:
    springaddons:
      oidc:
        ops:
        - iss: ${issuer}
          authorities:
          - path: ${authorities-json-path}
          aud: ${audience}
        client:
          client-uri: ${reverse-proxy-uri}${bff-prefix}
          security-matchers:
          - /api/**
          - /login/**
          - /oauth2/**
          - /logout/**
          permit-all:
          - /api/**
          - /login/**
          - /oauth2/**
          post-logout-redirect-host: ${hostname}
          csrf: cookie-accessible-from-js
          oauth2-redirections:
            rp-initiated-logout: ACCEPTED
          back-channel-logout:
            enabled: true
            internal-logout-uri: ${scheme}://localhost:${bff-port}/logout
        resourceserver:
          permit-all:
          - /login-options
          - /error
          - /v3/api-docs/**
          - /swagger-ui/**
          - /actuator/health/readiness
          - /actuator/health/liveness

After successful login and redirect, the call to API is getting JWT of type designated for Microsoft Graph API (with nonce field in the header). My custom API fails to validate it and throw error: Signed JWT rejected: Invalid signature

So I figured I probably need to create and use custom API scope instead so my backend API can validate it.

However when I change the scope to contain only my custom application API scope:
scope: api://{app id url}/Account.Manage

BFF Oauth2 client gets token and than fails with 401 UNAUTHORIZED from GET https://graph.microsoft.com/oidc/userinfo and redirect ends on error page with: An error occurred reading the UserInfo response: [invalid_user_info_response]
I believe it is expected to fail because this time it has JWT designated for my custom API (that would eventually validate signature OK in my API I think, but I cannot get through the userinfo).

What should be the correct approach here? Disable Oauth2 client to call userinfo? If so how can I achieve this?

I would really appreciate advice how to get from here.

[hajekt2]

Hello and Thank you for you insights.

My Openid configuration is https://119795fe-f178-444f-ae7a-14cbcc173d64.ciamlogin.com/119795fe-f178-444f-ae7a-14cbcc173d64/v2.0/.well-known/openid-configuration

Oauth2 and Spring security is quite new for me so I'm learning on the go. I dig further into this and here are my findings:

When I get access token for scopes openid,profile,email,offline_access, I get token that looks similar to JWT(but probably is not JWT), has nonce in the header, and "iss": "https://sts.windows.net/119795fe-f178-444f-ae7a-14cbcc173d64/", this is as I understand the access token to be used against MS Graph API (and possibly other MS services), and so call to https://graph.microsoft.com/oidc/userinfo works OK.
This is I believe exactly what you have described above. Seems it behaves the same for Entra ID (that presumably you tested) and Entra External ID (that I use).

We then send this access token to API/resource server when frontend do API call through bff. In the API the validation fails (as resource server has to validate it) as expected because this access token is not supposed to be used for custom APIs. Validation fails also at https://jwt.io

To get a valid JWT ID token I figured out that I have to get access token for my custom API scope only api://3cbf5bfd-41d0-4388-9573-ed94452838fb/Account.Manage, I had to register Entra ID Application and exposed an API with this custom scope.
Then I get JWT ID token, and "iss": "https://119795fe-f178-444f-ae7a-14cbcc173d64.ciamlogin.com/119795fe-f178-444f-ae7a-14cbcc173d64/v2.0", is correct. This validates OK at https://jwt.io. Everything seems good here. BUT Oauth2 client in bff calls userinfo with this and fails with 401 UNAUTHORIZED.

Sources that refers to this issue:
AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#609
https://stackoverflow.com/questions/66336695/configuring-spring-boot-starter-oauth2-client-to-authenticate-with-azure-ad
https://stackoverflow.com/questions/77261584/azure-ad-login-does-not-work-with-custom-scopes-invalid-user-info-response
https://apisandclients.com/posts/azure-ad-troubleshooting#4-access-tokens-issued-to-the-spa

I was not able to figure out what is supposed to be the correct approach here and how to set it up (with spring security and/or spring-addons).

I have thought of 2 possibilities:

1. bff oauth client gets JWT ID token for my API, but we need to disable call to userinfo in bff.
2. bff oauth client gets access token for MS graph first, calls userinfo with that, and afterwards we get JWT ID token with scope for the API, only the later is then sendt with the requests to the API/resource server.

I found there exists the spring boot starter for Entra ID spring-cloud-azure-starter-active-directory that possibly I hope may solve this issue but I was not able to get it working with spring-addons. I tried to disable spring.security.oauth2.client and enable instead spring.cloud.azure.active-directory, with no luck yet.

[ch4mpy]

There are things I don't understand in Microsoft Entra ID and I opened a ticket. Two weeks ago, I asked why issuer is not the same in tokens and OpenID discovery endpoints. I'm still waiting for an answer. Here is a copy of the message I sent yesterday after having no answer to the preceeding:

I want to authorize requests between an OAuth2 confidential client and some OAuth2 resource servers using Microsoft Entra ID as an OpenID provider.

My OAuth2 client is a Spring Cloud Gateway instance configured with authorization code and refresh token flows. It is a "confidential" client (uses a client-id and a client secret). It expects the authorization server to comply with OIDC.

My OAuth2 resource servers are Spring REST APIs validating Bearer access tokens using a JWT decoder. All expect the authorization server to issue JWT access tokens and to comply with OIDC.

When I write "comply with OIDC" I mean:

• there is a discovery endpoint from which RPs (OpenID Relying Parties) can auto-configure authorization, token, JWK-set, and end-session endpoints
• discovery endpoint is available from {issuer-uri}/.well-known/openid-configuration
• ID token is included in the token response when the openid scope is requested

What I managed to do so far:

• use https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0 as issuer for my RPs (Spring OAuth2 client and resource servers) to auto-configure using the .well-known/openid-configuration
• declare an API and request its ID as scope to get JWT access token (API ID is api://4f68014f-7f14-4f89-8197-06f0b3ff24d9/spring-addons)

What does not work:

• the access token is opaque as soon as I ask for the openid scope in addition to the API ID
• the issuer in the JWTs (access and ID tokens) is wrong (it is https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/ instead of https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0 as stated on both of https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0/.well-known/openid-configuration and https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0/.well-known/openid-configuration discovery endpoints). This breaks JWTs validation with the default Nimbus decoder.

What behaves differently than I expect:

• ID token should be included in the token response only when the openid scope is requested
• openid scope being requested should not influence the access token format
• I'd expect the API ID to be provided as audience - rather than scope - with the authorization request
• when using the endpoints listed in a .well-known/openid-configuration, the issued access & ID tokens should have as iss claim exactly the value of the discovery endpoint issuer entry
• there should be a way to introspect access tokens when the audience is my API but issued access tokens aren't JWTs (either an introspection endpoint or a userinfo endpoint accepting opaque tokens)
• if https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0/.well-known/openid-configuration had https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0 or https://sts.windows.net/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0/ as value for its issuer entry:
  1. tokens would be valid
  2. issuer and discovery URL would be aligned
• when the openid scope is not requested (like I have to do to get JWT access tokens), the user claims should be available from the userinfo endpoint - and not from the ID token which shouldn't be in the response. unfortunately, my JWT access tokens are rejected by the graph API - which is set as userinfo on the discovery endpoints - because of a bad audience (I'd expect the audience to be an array containing my API ID and the userinfo).

[ch4mpy]

Microsoft Entra ID looks like an OIDC Provider, but doesn't satisfy the OIDC discovery and OpenID tokens specifications for V1 tokens (which is the default for Entra apps).

To switch to V2 tokens, edit the manifest to set api.requestedAccessTokenVersion: 2.

This can be done under Applications -> App registrations -> {appName} -> Manifest -> Microsoft Graph App Manifest (New)

Another option is to disable OIDC discovery and issuer validation during tokens validation (leave issuer-uri and iss empty in properties). But this is pretty dirty and I'd rather advise using something else than a Microsoft authorization server, or hiding it behind an actual OIDC Provider if you can't do without.

Sample configuration setting neither issuer-uri nor iss to disable OIDC discovery:

oauth2-client-id: 561973cf-b7bc-4db7-856d-c2a2d6c5a1fa
oauth2-client-secret: change-me
tenant: 4f68014f-7f14-4f89-8197-06f0b3ff24d9

spring:
  security:
    oauth2:
      client:
        provider:
          entra:
            authorization-uri: https://login.microsoftonline.com/${tenant}/oauth2/v2.0/authorize
            token-uri: https://login.microsoftonline.com/${tenant}/oauth2/v2.0/token
            jwk-set-uri: https://login.microsoftonline.com/${tenant}/discovery/v2.0/keys
        registration:
          bff:
            provider: entra
            redirect-uri: http://localhost:7080/login/oauth2/code/quiz-bff
            client-id: ${oauth2-client-id}
            client-secret: ${oauth2-client-secret}
            authorization-grant-type: authorization_code
            scope:
            - openid
            - api://561973cf-b7bc-4db7-856d-c2a2d6c5a1fa/quiz

com:
  c4-soft:
    springaddons:
      oidc:
        ops:
        - jwk-set-uri: ${spring.security.oauth2.client.provider.entra.jwk-set-uri}
          authorities:
          - path: $.roles

With, as explained in "Is iss configuration property mandatory?", this spring-addons custom properties resolver bean:

@Configuration
@EnableMethodSecurity
public class WebSecurityConfig {

  @Component
  public class FirstOpenidProviderPropertiesResolver implements OpenidProviderPropertiesResolver {
    private final Optional<OpenidProviderProperties> opProperties;

    public FirstOpenidProviderPropertiesResolver(SpringAddonsOidcProperties properties) {
      this.opProperties = properties.getOps().isEmpty() ? Optional.empty()
          : Optional.of(properties.getOps().get(0));
    }

    @Override
    public Optional<OpenidProviderProperties> resolve(Map<String, Object> claimSet) {
      return opProperties;
    }
  }
}

[ch4mpy]

@hajekt2 I finally got a hint from Microsoft support asking me the "accesstokenAcceptedVersion value from the metadata file". I found it in the deprecated version of the Manifest. I also figured out that when setting its api.requestedAccessTokenVersion: 2 equivalent in the new version of manifest files, Microsoft Entra ID finally behaves as an OIDC Provider. With https://login.microsoftonline.com/4f68014f-7f14-4f89-8197-06f0b3ff24d9/v2.0 as Issuer Identifier (aka issuer-uri in Spring Security conf), I now have:

• discovery URI equal to {issuer-uri}/.well-known/openid-configuration
• the "issuer" property in the OpenID configuration is exactly equal to the {issuer-uri}
• the "iss" claim in tokens is exactly equal to the {issuer-uri}

I updated the README and the answer above.