oauth - 为什么 OAuth 中的隐式授权授予需要 "Web-hosted Client Resource"？

Question

我指的是以下链接的图 4 以了解其背后的工作:

https://tools.ietf.org/id/draft-ietf-oauth-v2-31.html#grant-implicit

我不明白为什么需要 Web 托管客户端资源？为什么 User-Agent 不直接将 Access Token 直接传递给客户端？

Answer 1

首先，将您对 OAuth 2.0 的引用更新为 the latest one .

众所周知，在隐式授权中，
在资源所有者授予访问权限后，授权服务器使用重定向 URI 将用户代理重定向回客户端，并且访问 token 在片段中。

例如:
http://www.myapp.com/googleapi/oauth/#access_token=ya29.JACdaU44_m0MQh0AAABLMVzZHm4KnUWyBECHJ9oM_0M2JC9x0xO6UoI9W8YNEw&token_type=Bearer&expires_in=3600
由于片段不会返回到服务器(哈希片段仅用于客户端)，客户端脚本必须解析片段并提取 access_token 参数的值。

现在，问题来了，当然我们可以在客户端写一个函数来解析fragment中的access token并直接使用，简单明了。 Here is a tutorial using this manner .

但是，在标准中，有 Web 托管客户端资源。为什么？
'Web-Hosted Client Resource'是一个客户端资源，它可能包含一些html页面和JavaScript，当然它是web-hosted，而不是在User-Agent中。由于授权服务器将再次访问我们的 web 应用程序，并使用片段中的访问 token 在 redirect_uri 处访问我们的 web 应用程序，我们的客户端 web 应用程序服务器将响应它(解析哈希片段)。 Here is a tutorial using this manner

总之，这两种方式的区别在于你把解析函数放在哪里。

将其直接放入客户端，该函数会检测用户代理是否命中重定向 URI，如果是，则解析片段中的访问 token 。

把它放在 web-hosted 客户端资源中(位于重定向 URI 中)，当授权服务器用访问 token 命中重定向 URI 时，函数定位重定向 URI 解析它。

第二个是标准的，因为它充分利用了重定向 URI，你也可以使用第一个。

据我所知，我还没有发现关于第二种方式的任何安全考虑。