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

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

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

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

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

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

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

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

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

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

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

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

谈论授权代码授予类型，我们有更多的安全性，通过删除客户端(用户代理或网站)对终端资源的特权访问，其中客户端(网站所有者)假装是你使用授权代码，也可以避免黑客在你的浏览器上使用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.

OAuth规范:

4.2. Implicit Grant The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server. Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request. The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

所以我们可以考虑:

This is for public OAuth i.e. when client not needed to be registered and doesn’t have it’s own client secrets. But what auth server checks redirect url and this is actually enough for security. The Access token occurs in browser’s address bar so user can copy the url and send to someone else and it also becomes logged as the user i.e. it’s something like Session fixation. But the browser make an additional redirect with replacing history to remove hash fragment from the url. It also possible to a hacker to stole the access token by sniffing a HTTP trafic but this can be easily protected by HTTPS. Some malicious browser extensions can have an access to urls from address bar but this is ultimately bad situation like broken HTTPS cert. And even Auth code flow can’t help here ether. So what I can see is that passing access token via hash fragment of url is absolutely safe. The separation of ephemeral access token and refresh token are useless when using a HTTPS and to be honest not so useful even on raw HTTP. But the fact that client via implicit flow can’t receive the refresh token is also nonsense.

因此，我认为我们应该引入一个新的授权流“安全隐式”，它严格地工作在https之上，允许刷新令牌(或者我们应该完全摆脱它们)，并且比认证Cose授权流更可取

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的库来处理它，所以我不得不写一个。如果你感兴趣，我可以帮你。

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