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

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

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

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

希望这能有所帮助。

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

因为谷歌员工:

你授权第三方访问你的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

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