隐式授权流程如何工作？答案

【问题标题】：How does the implicit grant flow work?隐式授权流程如何工作？
【发布时间】：2017-01-20 16:26:56
【问题描述】：

在此页面上，https://github.com/doorkeeper-gem/doorkeeper/wiki/Supported-Features，它提到了对隐式授权的支持。看起来authorizations#create 是我想要的端点，它确实返回了一个access_token，但它没有返回所需的其他参数。

请求

https://localhost/oauth/authorize?client_id=<client_id>&response_type=token&redirect_uri=urn:ietf:wg:oauth:2.0:oob

我被重定向到：

重定向

https://localhost?access_token=<access_token> with the body:
{"resource_owner_id":<user_id>,"scopes":[],"expires_in_seconds":7776000,"application":{"uid":"<client_id>"},"created_at":1484857630}

按照规范，我需要的是带有查询参数的重定向：

https://localhost#access_token=<access_token>&token_type=bearer&expires_in=<seconds>&scope=<scope>

使用“redirect_uri=urn:ietf:wg:oauth:2.0:oob”的测试重定向值是否会改变响应？
还要注意 ?而不是响应查询参数之前的#。我不确定规范对此有何规定，但 Amazon OAuth2 客户端需要 # 号。
如何让 token_type=bearer 被包含在内？

谢谢。

【问题讨论】：

标签： ruby-on-rails doorkeeper alexa-skill

【解决方案1】：

通过查看代码，我能够让我的服务正常工作。所以我上面的问题的答案是：

urn:ietf:wg:oauth:2.0: 称为原生 URI。代码中有分支，当它设置为本机 URI 时会改变响应。使用 ngrok 在我的本地机器上创建一个外部可调用端点，我使用了一个真正的 redirect_uri 值，并且 Doorkeeper 在响应中使用正确的参数进行响应（包括 token_type=bearer 和 # 符号）。

注意：只有在修改 Doorkeeper 代码以允许包含查询参数的重定向 URL 后，它才能在我的 Amazon Alexa 技能中起作用。 Amazon 的重定向 URL 采用 https://pitangui.amazon.com/spa/skill/account-linking-status.html?vendorId=<vendorId> 格式，目前 Doorkeeper 不支持这种格式，并且会抛出有关无效重定向 URI 的错误。

【讨论】：