这两个工作stream程有什么区别？ 何时使用授权码stream？
OAuth 2.0有多个工作stream程。 我有两个关于这两个问题。
- 授权码stream – 用户从客户端应用程序login，授权服务器将授权码返回给应用程序。 该应用程序然后交换访问令牌的授权码。
- 隐式授权stream程 – 用户从客户端应用程序login，授权服务器直接向客户端应用程序发出访问令牌。
这两种方法在安全性方面有什么区别？ 哪一个更安全，为什么？
当服务器可以直接发出Access令牌时，我看不到为什么在一个工作stream中添加额外步骤（令牌的交换授权码）的原因。
不同的网站说，当客户端应用程序可以保证凭证安全时使用授权码stream。 为什么？
access_token是你需要调用一个受保护的资源（一个API）。 在授权码stream程中有两个步骤来获取它：
- 用户必须authentication并向API使用者（称为“客户”）返回
code。 - API的“客户端”（通常是您的Web服务器）将＃1中获得的
code与access_token进行交换，使用client_id和client_secret身份validation - 然后可以使用
access_token调用API。
所以，有一个双重检查：拥有资源的用户通过API和使用API的客户端（例如Web应用程序）浮出水面。 两者都被validation为授予访问权限。 在这里注意OAuth的“授权”性质：用户授予对他的资源的访问权限（通过authentication后返回的code ）到应用程序，应用程序得到一个access_token ，并代表用户调用。
在隐式stream程中，步骤2被省略。 所以在用户authentication之后，直接返回一个access_token ，你可以使用它来访问资源。 API不知道谁在调用该API。 具有access_token任何人都可以，而在前面的例子中，只有web应用程序（它是内部通常不能被任何人访问）。
隐式stream程通常用于不build议存储client id和client secret情况下（例如，尽pipe许多设备都是这样做的）。 这是免责声明的意思。 人们可以访问客户端代码，因此可以获得凭据并假装成为资源客户端。 在隐式stream程中，所有数据都是不稳定的，应用程序中没有任何内容。
我会在这里添加一些我不认为在上面的答案中明确的东西：
- 授权代码stream允许最终的访问令牌永远不会到达，也不会被浏览器/应用存储在机器上 。 临时授权代码通过浏览器/应用程序提供给机器，然后发送到服务器。 然后，服务器可以用一个完整的访问令牌来交换它，并可以访问API等。具有浏览器的用户只能通过带有令牌的服务器访问API。
- 隐式stream只能涉及到两方， 最终的访问令牌通过浏览器/应用程序存储在客户端。 如果这个浏览器/应用程序受到威胁，那么他们的authentication令牌可能是危险的。
tl; dr不使用隐式stream如果你不相信用户机器持有令牌，但你确实相信你自己的服务器。
两者的区别在于：
-
在隐式stream程中，令牌直接通过带有“＃”符号的redirectURL返回，这主要用于没有服务器端的javascript客户端或移动应用程序，客户端在某些实现中不需要提供其秘密。
-
在授权码stream程中，代码返回“？” 要被服务器端读取，那么服务器端必须提供客户机密钥给令牌url以从授权服务器获取令牌作为json对象。 如果您的应用程序服务器可以处理此操作并将用户令牌存储在自己的系统上，并且主要用于常见的移动应用程序，则可以使用它。
所以这取决于你的客户端应用程序的性质，哪一个更安全的“授权码”，因为它是请求客户端的秘密，令牌可以在授权服务器和客户端应用程序之间在非常安全的连接上发送，授权提供者可以限制一些客户端只使用“授权码”并禁止隐含
隐式授权与授权代码授权类似，有两个不同的区别。
它旨在用于基于用户代理的客户端（例如单页networking应用程序），因为所有的应用程序代码和存储都很容易访问，所以不能保持客户端的秘密。
其次，代替授权服务器返回交换访问令牌的授权码，授权服务器返回访问令牌。
请在这里find详细信息http://oauth2.thephpleague.com/authorization-server/which-grant/
隐式stream
优点
- 最简单的实施
缺点
- 访问令牌对浏览器可见
- 访问令牌的来源无法确定
- 访问令牌不能过期（通过Google政策）
授权码stream程
优点
- 最安全的
- 只有知道共享密钥时才可以创build访问令牌和刷新令牌
- 可以通过新的安全和UXfunction进行增强
缺点
- 必须实施多个auth端点
引用： https ： //developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows
从实际的angular度（我所理解的），Authz代码stream的主要原因是：
- 支持刷新令牌（由用户代表用户长期访问），不支持隐式支持：请参阅https://tools.ietf.org/html/rfc6749#section-4.2
- 支持同意页面，这是资源所有者可以控制提供什么访问权限的地方（您在Google中看到的权限/授权页面）。 同样不存在隐含的。 请参阅： https : //tools.ietf.org/html/rfc6749#section-4.1 ，点（B）
“授权服务器（通过用户代理）authentication资源所有者，并确定资源所有者是否授予或拒绝客户端的访问请求”
除此之外，应用程序可以使用刷新令牌长期访问用户数据。
让我总结一下我从上面的答案中学到的几点，并加上一些我自己的理解。
授权码stream！
- 如果您有一个充当OAuth客户端的Web应用程序服务器
- 如果你想拥有长久的访问权限
- 如果你想离线访问数据
- 当你负责你的应用程序的API调用
- 如果您不想泄漏您的OAuth令牌
- 如果您不希望应用程序在每次需要访问数据时都通过授权stream程运行。 注意：隐式授权stream程不允许刷新令牌，因此如果授权服务器定期访问令牌，则只要需要访问权限，应用程序就需要运行授权stream程。
隐含的授权stream程！
- 当您没有Web应用程序服务器充当OAuth客户端时
- 如果您不需要长时间访问，即只需要临时访问数据。
- 如果您信任应用程序运行的浏览器，并且访问令牌泄漏给不受信任的用户的限制。
