实际上，微软的sso实现中有几个“特性”阻止ootb功能。

问题1：令牌包含违反jwt规范的额外nonce

解决方案：在exposeaapi下创建一个新的作用域。这个范围可以被命名为任何东西。将此范围添加到api权限部分，并更新客户端注册的范围属性以包含新范围。
有关此问题的更多信息，请访问：https://xsreality.medium.com/making-azure-ad-oidc-compliant-5734b70c43ff

问题2：无效作用域

解决方案：不包括任何graph api作用域。它们目前不适用于microsoft帐户（截至2/16/21）。

问题3：颁发者无效

解决方案：使用microsoft当前在其众所周知的端点api下公开的颁发者，无论您使用哪个api。
消费者：https://login.microsoftonline.com/consumers/v2.0/.well-known/openid-configuration
常见：https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
我不相信common目前会起作用，因为只有消费者端点有一个tenantid，并且它包含在文档化的发行者字符串中（截至2/16/21），但是api一直在为消费者端点提供一些不同的bug。21年2月15日，发行人被硬编码为“https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0“不管租户是谁，正如上面链接的文章所记录的，它是”https://sts.windows.net/407b9272-20f5-421c-a25f-e7a189309c4b/“从8/21/19开始。目前（2/16/21），发行人正确地包括租户。

***更新2/18/21：尽管众所周知的端点表示发卡机构接受租户id，但发卡机构仍然被硬编码为我在上面发布的租户id。

结果yaml：

spring:
  security:
    oauth2:
      client:
        registration:
          microsoft:
            client-id: [my app registration client id]
            client-secret: [my app registration secret id]
            scope: profile, openid, [my custom scope with the full api prefix]
            client-name: Microsoft
            authorization-grant-type: authorization_code
            provider: microsoft
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
        provider:
          microsoft:
            authorization-uri: https://login.microsoftonline.com/consumers/oauth2/v2.0/authorize
            key-set-uri: https://login.microsoftonline.com/consumers/discovery/v2.0/keys
            token-uri: https://login.microsoftonline.com/consumers/oauth2/v2.0/token
            user-info-uri: https://graph.microsoft.com/oidc/userinfo
            userNameAttribute: sub
            issuer-uri: https://login.microsoftonline.com/${app.oauth2.tenant-id}/v2.0

app:
  oauth2:
    tenant-id: [my tenant id]

对于值[my custom scope with the full api prefix]，请确保复制包含api://[app id]的完整作用域名称。