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

Question

我参考以下链接中的图4来理解它的工作原理：https://tools.ietf.org/id/draft-ietf-oauth-v2-31.html#grant-implicit。

我不明白为什么需要 Web-Hosted Client Resource？为什么用户代理不能直接将访问令牌传递给客户端？

- user3660367

Answer 1

首先，将您的OAuth 2.0参考文献更新到最新版本。

我们知道，在隐式授权中，资源所有者授予访问权限后，授权服务器使用重定向URI将用户代理重定向回客户端，访问令牌在片段中。

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

现在，问题来了，当然我们可以在客户端中编写一个函数来从片段中解析访问令牌并直接使用它，这很简单明了。 这是一种使用此方式的教程。

但是，在标准中，有Web托管的客户端资源。为什么呢？“Web托管的客户端资源”是客户端资源，它可能包括一些HTML页面和JavaScript，当然它是Web托管的，而不是在用户代理中。由于授权服务器将再次使用片段在redirect_uri处访问我们的Web应用程序，因此我们的客户端Web应用程序服务器将对其进行响应（解析哈希片段）。这是一种使用此方式的教程。

总之，这两种方式之间的区别在于您放置解析函数的位置。

1. 将其直接放在客户端本身中，并且该函数检测用户代理是否命中了重定向URI，如果是，则从片段中解析访问令牌。 2. 将其放在Web托管的客户端资源中（位于重定向URI中），当授权服务器使用访问令牌命中重定向URI时，该函数会定位重定向URI并解析它。

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

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

- Owen Cao

---

两个教程链接目前都已失效。 - gstackoverflow