The Implicit Flow makes the whole flow pretty easy, but also less secure. As the client application, which is typically JavaScript running within a Browser is less trusted, no refresh tokens for long-lived access are returned. You should use this flow for applications that need temporary access (a few hours) to the user’s data. Returning an access token to JavaScript clients also means that your browser-based application needs to take special care – think of XSS Attacks that could leak the access token to other systems.

https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow

在“隐式”流中，客户端(可能是浏览器)将通过浏览器重定向(get操作)获得访问令牌。基于浏览器的通信是不安全的，您的客户端机密或令牌可能被拦截或窃取。

在“授权码”流程中，客户端(通常是web服务器)仅通过浏览器重定向(get操作)获得授权码。然后服务器通过对授权服务器进行POST调用(非浏览器)，将此代码与令牌交换。服务器包含客户端秘密仅用于令牌访问调用。

注意:根据oauth最佳实践，“客户端不应该使用隐式授权(响应类型“令牌”)或其他响应类型颁发访问权限 授权响应中的令牌”。

希望这能有所帮助。

谈论授权代码授予类型，我们有更多的安全性，通过删除客户端(用户代理或网站)对终端资源的特权访问，其中客户端(网站所有者)假装是你使用授权代码，也可以避免黑客在你的浏览器上使用XSS(网站漏洞)的CRSF(如果使用隐式方法可能会发生)。

关键成分是在向认证服务器发出的第一个请求中使用的客户端id。您可以将验证码步骤视为签名验证。

Moreover, even after finished with the Authorization code steps in acquiring an Access token, ultimately, the access_token ends up in the hands of the client. At that point there is no need to have a client-id for signature verification anymore with the Auth Server. So, I am not sure if Authorization Code method is also perfectly safe (from the client itself). Which is why you see the Auth Server asks you for Consent even after providing the login credentials. Meaning you trust the client with your Access Tokens.

For us, our clients wanted to be able to authenticate with our app on their phones once, and not have to log in again for weeks at a time. With code flow, you get a refresh token along with your access token. Implicit flow does not give you a refresh token. The access token has a relatively short expiration, but the refresh tokens can have up to a 90 day expiration. Whenever the access token expires, the client and server code can use that refresh token to get a new access token plus refresh token, all behind the scenes, without any user intervention whatsoever. A refresh token can only be used once. You cannot do this with Implicit Flow. If you're using Implicit Flow, and your user doesn't interact with your app for over an hour, they will have to log in again when they come back. That was not acceptable in our use case, and Code Flow supports our use case securely.

这是有效的，而且是安全的，因为可以撤销刷新令牌。如果客户说他们丢失了手机或笔记本电脑，或者黑客侵入了他们的桌面，我们可以简单地撤销该用户的所有刷新令牌。在整个过程中，没有任何个人身份信息(PII)触及我们的代码，即用户的密码。

代码流很棒，但它确实需要更多的工作。MS目前没有Angular的库来处理它，所以我不得不写一个。如果你感兴趣，我可以帮你。

因为谷歌员工:

你授权第三方访问你的Gmail联系人 访问权限以令牌的形式授予 任何拥有有效令牌的人都将获得访问权限 因此，您不希望公开令牌，并最小化其传输 使用隐式流，(不受控制的)浏览器获得访问令牌，从而将令牌放在公共位置 使用认证代码流，浏览器只能获得一个临时的认证代码，但从来没有访问令牌，而且如果没有只有第三方和Gmail知道的秘密，认证代码是无用的

结论

For an attacker to gain access to your Gmail contacts, it must break into your 3rd party account However, the attacker never gets a hold on the access token thus is unable to perform operations to your Gmail contacts directly You may authorize a 3rd party to access many services, so you do not want to store all the important tokens locally on your computer However, there is one scenario you can only use implicit flow: when the 3rd party runs locally, and does not have a backend to store tokens Then it can only rely on the front-end to store the tokens, which it has little control

比喻

Implicit flow: YOU ask PROVIDER for a key, YOU store it in your wallet, YOU are responsible to keep it safe, YOU use the key directly with care, and YOU exchange it for a new key in time Auth code flow: YOU ask for a code, code is handed to your VALET, your VALET combines the code and a secret text then exchange it for a key with PROVIDER, YOU ask your VALET to use the key when needed but never sees the key yourself, and your VALET is responsible to exchange new keys Most of the time your VALET is more security-aware than YOU :) When YOU do not have a VALET, YOU are on your own

我的回答是:你不能在web应用服务器上以一种安全简单的方式实现隐式流。

web应用程序授权过程涉及用户交互，因此认证服务器应该在用户认证和同意后将用户的浏览器重定向到web应用程序的目标页面(我没有看到任何其他方法在与认证服务器交互后将用户传递回web应用程序)。

所以令牌应该通过web应用程序使用重定向URL，对吗?

正如@NicolasGarnier在他的回答和评论中解释的那样，没有办法将token作为URL片段传递-它不会到达web应用程序服务器。

并且将token作为重定向URL的URL参数即使在HTTPS下也是不安全的:如果目标页面(让它是“问候页面”)包含资源(图像，脚本等)，这些资源将由浏览器通过一系列HTTP(S)请求获得(每个请求都有Referer HTTP头，包含“问候页面”的确切URL，包括URL参数)。这就是令牌泄漏的方式。

因此，似乎没有办法在重定向URL传递令牌。这就是为什么需要第二次调用(从身份验证服务器到客户端(但是到哪个URL?)或从客户端到身份验证服务器(授权代码流中的第二次调用))