为什么 OAuth 中的隐式授权授予需要“Web 托管客户端资源”？

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 将用户代理重定向回客户端，访问令牌在片段中。

例如： http://www.myapp.com/googleapi/oauth/#access_token=ya29.JACdaU44_m0MQh0AAABLMVzZHm4KnUWyBECHJ9oM_0M2JC9x0xO6UoI9W8YNEw&token_type=Bearer&expires_in=3600

由于片段没有返回给服务器（哈希片段仅用于客户端），客户端脚本必须解析片段并提取 access_token 参数的值。

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

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

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

1. 把它直接放在自己的客户端中，该函数检测用户代理是否命中了重定向URI，如果是，则从片段中解析访问令牌。

2. 把它放在网络托管的客户端资源中（位于重定向URI中），当授权服务器使用访问令牌命中重定向URI时，该函数定位重定向URI解析它。

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

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