【问题标题】:Microsoft Graph API redirect_uri doesn't allow query stringsMicrosoft Graph API redirect_uri 不允许查询字符串
【发布时间】:2018-05-09 01:06:05
【问题描述】:

我们正在尝试从旧的 WindowsLive API 迁移到新的 Microsoft Graph API。在此过程中,我们遇到了应用程序中所需的 OAuth 2.0 redirect_uri 参数的困难。

根据Oauth 2.0 RFCredirect_uri 必须是绝对路径,但可以包含正确编码的查询字符串。

在我们的 Windows 应用中,我们设置了绝对路径 - 他们的应用工具不允许添加查询字符串:https://example.com/index.php

我们发出的 OAuth 请求使用带有 URL 编码的 redirect_uri,包括查询参数。这是必要的,我们使用 CMS (Joomla) 需要知道应该处理请求的内容:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
 response_type=code&
 client_id={string}&    
 redirect_uri=https%3A%2F%2Fexample.com%2Findex.php%3Foption%3Dcom_jfbconnect%26task%3Dauthenticate.callback%26provider%3Dwindowslive&
 scope=user.read&
 state={string}&
 access_type=offline&
 approval_prompt=auto

但是,Graph API 拒绝这样做:

“请求中指定的回复url与为应用配置的回复url不匹配”

还有其他人遇到这种情况或了解为什么 Graph API 不接受应用配置或令牌请求中的查询参数吗?

编辑 - 5/8 - 但是,应用程序设置区域不允许在 redirect_uri 设置中允许查询字符串,根据 RFC,这是正确的。但是,Graph API 不尊重 RFC 的此注释:

The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters.

【问题讨论】:

    标签: oauth-2.0 azure-active-directory microsoft-graph-api


    【解决方案1】:

    这实际上并没有被 Microsoft Graph 拒绝。 Microsoft Graph 只是一个 API,它不会生成或管理访问令牌。该过程由 Azure Active Directory 处理。

    您遇到的错误是由于您的redirect_uri 未在您的应用注册https://apps.dev.microsoft.com 中配置。 URL 必须明确匹配注册中配置的 URL。来自documentation

    您的应用的redirect_uri,您的应用可以在其中发送和接收身份验证响应。它必须完全匹配您在门户中注册的重定向 URI 之一,但它必须是 url 编码的。

    对于需要传递数据的场景,您应该在 state 参数中对这些值进行编码。这将与授权代码一起返回到您的重定向 URI。

    还要注意access_type=offlineapproval_prompt=auto 都不是有效的查询参数:

    • 要检索refresh_token,请将offline 添加到作用域列表(user.read+offline)。
    • 要设置用户收到的提示类型,请使用prompt 参数。有效选项为 loginnoneconsent

    【讨论】:

    • 感谢您的回复。我同意链接与apps.dev.microsoft.com 中的内容不匹配。但是,应用程序设置区域不允许在 redirect_uri 设置中允许查询字符串,根据 RFC 是正确的。但是,Graph API 不遵守 RFC 的此注释:The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters.!App Setup area rejecting query strings
    • 抱歉,评论的格式很糟糕。我用相同的细节编辑了原始帖子,以便于阅读。无法再编辑我的评论,但希望上面的图片链接有助于解释为什么我无法让客户端 URL 与服务器端 URL 匹配。
    • 这总是标准的问题。您如何解释“可能包括”取决于您的观点。在这种情况下,AAD 认为它们对规范是可选的,并且没有实现这方面。我会将这些信息包含在您的state 中。当用户被重定向回来时,您的端点可以解码state 值。
    • 这不是一个正确的解释。 'MAY' 来自客户端,'MUST' 来自服务器端,即 AAD。因此,作为客户端,我们应该能够包含查询字符串,如果我们这样做,则必须保留它。如果无法使用查询字符串,这似乎是一个错误。 state 参数也不是一个选项。它是一个 CMS,如果 CMS 不知道将响应通知我们的代码,那么我们将永远无法对其采取行动。
    • 所有其他社交网络(Google、Facebook、Instagram、Twitter、Meetup、Github 等)都支持某种形式的查询字符串。无论是在其应用程序设置中以获取有效的重定向 URL,还是严格遵循仅允许在应用程序设置中使用绝对路径但保留查询字符串的 RFC。甚至以前的 WindowsLive OAuth2 协议也能正确支持这一点,这就是我们试图从中迁移的内容:/
    猜你喜欢
    • 2014-09-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多