OAuth 2.0有多个工作流程。我对这两个问题有几个问题。
这两种方法在安全性方面有什么区别？哪一个更安全，为什么？
当服务器可以直接发出访问令牌时，我没有看到为什么在一个工作流中添加额外步骤（令牌的交换授权代码）的原因。
不同的网站表示，当客户端应用可以保证凭据安全时，会使用授权代码流。为什么呢？
答案 0 :(得分：183)
access_token是调用受保护资源（API）所需的。在授权代码流程中，有两个步骤可以获得它：
code。code交换＃1获得的access_token，使用client_id和client_secret对自身进行身份验证access_token。因此，有一个双重检查：拥有通过API浮出资源的用户和使用API的客户端（例如网络应用程序）。两者都经过验证可以获得授权。请注意OAuth的“授权”性质：用户授予对应用程序的资源访问权限（通过身份验证后返回的code），应用程序获取access_token，然后代表用户进行呼叫。 / p>
在隐式流程中，省略步骤2。因此，在用户身份验证之后，将直接返回access_token，您可以使用该access_token来访问资源。 API不知道谁在调用该API。任何拥有client id的人都可以，而在前面的例子中只有网络应用程序（它的内部结构通常不会被任何人访问）。
隐式流通常用于不建议存储client secret和{{1}}的情况（例如设备，尽管很多人都这样做）。这就是免责声明的含义。人们可以访问客户端代码，因此可以获取凭据并假装成为资源客户端。在隐式流程中，所有数据都是易失性的，并且应用程序中没有任何内容存储。
答案 1 :(得分：49)
我会在这里添加一些我认为在上述答案中没有说清楚的内容：
tl; dr 如果您不信任用户计算机持有令牌但 信任您自己的服务器，则不使用隐式流。
答案 2 :(得分：13)
两者之间的区别在于：
在Implicit流中，令牌直接通过带有“＃”符号的重定向URL返回，这主要用于javascript客户端或没有服务器端的移动应用程序，客户端不需要在某些实施中提供其秘密。
在授权代码流程中，代码以“？”返回如果服务器端可以读取，则服务器端必须在此时向令牌URL提供客户端密钥，以便从授权服务器获取令牌作为json对象。它用于以下情况：如果您有可以处理此问题的应用程序服务器，并将用户令牌与他/她的配置文件存储在他自己的系统上，并且主要用于常见的移动应用程序。
所以它取决于客户端应用程序的性质，哪一个更安全的“授权代码”，因为它在客户端请求秘密，并且令牌可以在非常安全的连接上在授权服务器和客户端应用程序之间发送，并且授权提供程序可以限制某些客户端仅使用“授权代码”并禁止隐式
答案 3 :(得分：3)
隐式授权类似于授权代码授予，具有两个明显的差异。
它旨在用于基于用户代理的客户端（例如单页Web应用程序），这些客户端无法保密客户端，因为所有应用程序代码和存储都可以轻松访问。
其次，授权服务器返回一个访问令牌的授权代码，而不是授权服务器返回一个访问令牌的授权代码。
请在此处查找详细信息 http://oauth2.thephpleague.com/authorization-server/which-grant/
答案 4 :(得分：1)
让我总结一下我从上述答案中学到的几点，并加上我自己的一些理解。
答案 5 :(得分：1)
引文：https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows
答案 6 :(得分：0)
从实际角度来看（我的理解），拥有Authz代码流程的主要原因是：
“授权服务器验证资源所有者（通过用户代理）并确定资源所有者是否授予或拒绝客户端的访问请求”
除此之外，使用刷新令牌，应用程序可以获得对用户数据的长期访问。
答案 7 :(得分：0)
哪个更安全，为什么？
它们都是安全的，这取决于您使用它的环境。
我看不出为什么需要执行额外步骤（交换授权码）的原因 服务器可以直接在一个工作流程中添加令牌） 发出访问令牌。
很简单。您的客户不安全。让我们详细看看。
考虑到您正在针对Instagram API开发应用程序，因此您要向Instagram注册APP并定义所需的API's。 Instagram将为您提供client_id和client_secrect
在您的网站上，您设置了一个链接，上面写着。 “来并使用我的应用程序”。单击此Web应用程序应该对Instagram API进行两次调用。
First使用以下参数向Instagram Authentication Server发送请求。
1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.
您没有发送client_secret ，您无法信任客户端（尝试使用您的应用程序的用户和/或他的浏览器）。客户端可以看到url或Java脚本，并轻松找到您的client_secrect。这就是为什么您需要进一步的步骤。
您会收到code和state。这里的code是temporary，没有保存在任何地方。
然后（从您的服务器）对second进行Instagram API调用
1. `grant_type` with the value of `authorization_code`
2. `client_id` with the client identifier
3. `client_secret` with the client secret
4. `redirect_uri` with the same redirect URI the user was redirect back to
5. `code` which we have already received.
由于是从我们的服务器发出呼叫，因此我们可以安全地将client_secret与code一起使用client_id（这表明用户已使用access_token来使用资源）。
作为回应，我们将有- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
ImgCollectionCell *cell=[collectionView dequeueReusableCellWithReuseIdentifier:@"CollectionCell" forIndexPath:indexPath];
Mainimg.image = cell.img.image;
}
答案 8 :(得分：0)
到目前为止，似乎有两个关键点尚未讨论，这解释了为什么授权码授予类型中的绕行增加了安全性。
短篇小说：授权代码授予类型保留浏览器历史记录中的敏感信息，令牌的传输仅取决于授权服务器的HTTPS保护。
长版：
在下文中，我将坚持使用RFC（快速阅读）中定义的OAuth 2术语：资源服务器，客户端， 授权服务器，资源所有者。
假设您希望某些第三方应用程序（=客户端）访问您的Google帐户（=资源服务器）的某些数据。假设Google使用OAuth2。您是Google帐户的资源所有者，但是现在您正在操作第三方应用。
首先，客户端打开浏览器，将您发送到Google授权服务器的安全URL。然后，您批准访问请求，授权服务器将您发送回客户端先前提供的重定向URL，其中授权代码位于查询字符串中。现在有两个关键点：
使用授权码授予类型，令牌最终是通过从客户端到授权服务器的调用获得的，其中传输安全性仅取决于授权服务器，而不取决于客户端