此问题与本机移动应用程序中基于OAuth的登录有关。根据授权授权类型流，用户在登录页面中输入用户ID，密码，作为响应，在URL中获得授权代码（因为其URL，基于https的加密也不起作用）。
这意味着授权代码在代理中可用，任何人都可以使用它，前提是它们也具有客户端密钥。客户端密钥不能存储在移动应用程序中，因为移动应用程序也不被认为是安全的。我想要绕过客户端密钥的安全性的方法是提供服务器端端点，移动客户端可以在其中调用客户端ID，授权代码和重定向网址。端点将丰富客户端密钥，然后调用实际令牌端点以获取accessstoken。由于整个通信都是通过HTTPS进行的，因此accessstoken是安全的。
现在的问题是 - URL参数中的授权代码是不安全且易受攻击的。或者我是否在思考安全问题。这是主要问题，如果这确实是一个安全问题，采取的缓解措施是什么？
我能想到的一个选项是来自旧的stackoverflow线程之一是保护令牌端点，它将从服务器端提供访问令牌。有关如何做到这一点的任何建议？ - 如果是证书，则证书将打包在移动应用程序中，使其再次不安全）
答案 0 :(得分：2)
无耻的插件......但是由于我阅读了完整的规范并进行了一些离线讨论，我想提供相同的观点。
一个。客户端和authroization服务器之间的TLS - 在授权提供程序中进行少量重定向后完成完整身份验证时，授权提供程序会将位置标头设置为重定向uri以及位置标头内查询参数中的授权代码。由于授权代码在位置标头内，并且响应头仍受TLS保护，因此窃听不会公开授权代码。
湾如果客户端是移动应用程序 - 重定向uri应该指向一个自定义URI方案，该方案将指向移动应用程序本身。因此，当浏览器根据位置标题执行重定向时，浏览器将调用移动应用程序。呼叫不会离开设备，因此授权代码不会暴露给外界。
℃。如果客户端是Web应用程序 - 重定向uri将通过浏览器执行，授权代码将在代理日志中显示（在https卸载后）和浏览器缓存中，或者如果存在重定向，则它将容易受到影响。代码的泄漏。授权代码的保护有两种方式 - a。可以使用生命周期设置授权代码，该生命周期可以很小。湾授权码只能使用一次。因此，如果实际客户端已经使用它，则没有人可以重用auth代码来再次获取访问令牌。
d。基于Kris在下面的评论中提到的观点，该规范定义了一种保护滥用授权代码的方法。如果代码被多次使用，则授权服务器可以撤消使用授权代码创建的所有访问令牌。