浏览器中存储访问令牌的最佳实践( 四 ) _浏览器

使用Cookie的OAuth语义Cookie仍然是传输令牌和充当API凭据的最佳选择，因为即使攻击者成功利用XSS漏洞，也无法从cookie中检索访问令牌。但是，为了做到这一点， cookie必须适当配置。
首先，将cookie标记为HttpOnly ，以便它们不可通过JavaScript访问，以解决XSS攻击的风险。另一个关键属性是Secure标志，它确保cookie仅通过HTTPS发送，以减轻中间人攻击。
其次，颁发短暂的只在几分钟内有效的访问令牌。在最坏的情况下，具有最小有效期的访问令牌只能在可以接受的短时间内被滥用。通常认为15分钟的有效期是合适的。让cookie和令牌的过期时间大致相同。
第三，将令牌视为敏感数据。只在cookie中存储加密令牌。如果攻击者设法获取加密令牌，他们将无法从中解析任何数据。攻击者也无法将加密的令牌重放到任何其他API，因为其他API无法解密令牌。加密令牌只是限制了被盗令牌的影响。
第四，在发送API凭据时要限制性强。只向需要API凭据的资源发送cookie 。这意味着确保浏览器只在实际需要访问令牌的API调用中添加cookie 。为此，cookie需要有适当的设置，比如SameSite=Strict、指向API端点域的域属性和路径。
最后，在使用刷新令牌时，请确保将它们存储在自己的cookie中。没有必要在每个API请求中都发送它们，所以请确保不是这种情况。刷新令牌必须只在刷新过期的访问令牌时添加。这意味着包含刷新令牌的cookie与包含访问令牌的cookie有稍微不同的设置。
令牌处理程序模式在JavaScript客户端中为OAuth提供最佳实践原则的设计模式是令牌处理程序模式。它遵循OAuth 2.0 for Browser-Based Apps中描述的BFF(backend for frontend)方法。该模式引入了一个后端组件，能够发出带有加密令牌和上述必要属性的cookie 。
后端组件的责任是:

作为OAuth客户端与授权服务器交互，启动用户认证并获取令牌。
管理JavaScript应用程序的令牌，使其不可访问。
代理和拦截所有API请求，以附加正确的访问令牌。

令牌处理程序模式定义了一个BFF ，它为在浏览器中运行的应用程序抽象了OAuth 。换句话说，令牌处理程序模式建议一个JavaScript应用程序可以用来认证用户并安全地调用API的API 。为此，该模式使用cookie来存储和发送访问令牌。
令牌处理程序是一个后端组件，例如可以驻留在API网关中。它由两部分组成:

OAuth代理，它处理OAuth流以从授权服务器获取令牌。
OAuth代理，它拦截对API的所有请求并将cookie转换为令牌。

文章插图
OAuth代理获取令牌后，它会发出带有以下属性的cookie:

SameSite=Strict
HttpOnly
Secure
API的路径

由于令牌处理程序是一个后端组件，所以OAuth代理是一个保密的客户端，可以向授权服务器进行身份验证(与公开的JavaScript客户端相比) 。这意味着为了获得令牌，OAuth代理需要进行身份验证。因此，攻击者需要获取客户端凭据才能成功获取新令牌。在JavaScript中运行静默流而没有客户端凭据将失败。
为了令牌处理程序模式能够工作，JavaScript应用程序和令牌处理程序组件必须部署在同一站点上(换句话说，它们必须在同一域中运行) 。否则，由于cookie上的同站限制，浏览器不会将令牌cookie添加到API请求中。
要获取数据， JavaScript应用程序只需通过OAuth代理调用API:

// http://www.example.com/app.js// Call to OAuth Proxyconst response = await fetch("https://api.example.com/orders", {// Instruct the browser to add cookies to cross-origin requestscredentials: "include"});

浏览器会自动将cookie添加到请求中。在上面的示例中，浏览器将cookie包含在跨域请求中。但是，由于cookie属性SameSite=Strict ，浏览器只会将cookie添加到同一站点(同一域)的跨域请求中。
OAuth代理解密cookie并将令牌添加到上游API 。cookie属性确保浏览器仅将cookie添加到HTTPS请求中，以确保它们在传输过程中是安全的。由于令牌是加密的，它们在休息时也是安全的。然后令牌用于安全访问API 。