我如何保护AWS Cognito生成的单页应用程序生成的Refresh_token
我计划创建一个单页网络应用程序，所有用户身份验证都将由AWS Cognito处理。通过阅读一些艺术品，他们都建议使用“代码”赠款流 + pkce而不是隐式流，因为在OAuth 2.1中隐含的流量是弃用的2.1
我用AWS Cognito创建了一个测试用户池，使用Postman使用Postman I成功地获得access_token，ID，id token并使用代码赠款流 + PKCE刷新令牌。
我与AWS Cognito Doc进行了仔细检查，如果使用代码赠款流，似乎总是会返回刷新令牌，并且在AWS控制台中找不到任何地方以禁用返回刷新令牌。所以只是想知道如何保护refresh_token？ cookie或localstorage无法停止XSS。
I am planning to create a single page web application and all user authentication would be handled by AWS Cognito. By reading through some of articals, they all suggest using "code" grant flow + PKCE rather than implicit flow since implicit flow is deprecated in OAuth 2.1
I created a test user pool with AWS Cognito, by using Postman I successfully get access_token, id token and refresh token with code grant flow + PKCE.
I double checked with AWS Cognito Doc, seems refresh token will always be returned if using code grant flow and I cannot find anywhere in AWS console to disable returning refresh token. So just wondering how can I protect refresh_token? Cookie or localStorage can not stop XSS.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，通过后端来路由令牌请求，例如实用程序API，它也代表刷新令牌为
http仅samesite =严格的加密安全cookie。请参阅此加密代码例如。后端组件还使您还可以使用客户端秘密，除了PKCE，它可以稍微提高安全性。 Cognito支持这一点，所以我建议两者都使用。
最佳实践
OAuth用于基于浏览器的应用程序建议这种方法。利益相关者通常希望您将后端用于所描述的前端，如果您必须解释应用程序的安全性，这将使生活更加自在。
XSS
使用上述HTTP cookie方法，恶意代码将无法窃取您的刷新令牌，因此，这是推荐的处理方法。
如果您的水疗中心具有XSS漏洞，则恶意代码可能能够窃取您的数据，而不管令牌还是cookie是使用访问数据的。因此，无论您的OAuth解决方案如何，仔细实施XSS保护至关重要。
It is usual to route requests for tokens via a backend, eg a utility API, which also represents the refresh token as an
HTTP Only SameSite=strict encrypted secure cookie. See this crypto code for an example.The backend component also enables you to use a client secret, in addition to PKCE, which improves security a little. Cognito supports this, so I'd recommend using both.
BEST PRACTICE
OAuth for browser based apps recommends this approach. Stakeholders often expect you to be using the backend for frontend described, and it will make life more comfortable if you have to explain your app's security.
XSS
With the above HTTP only cookie approach, malicious code would not be able to steal your refresh tokens, and this is therefore the recommended way to handle them.
If your SPA has XSS vulnerabilities, then malicious code might be able to steal your data though, regardless of whether tokens or cookies are used to access data. Therefore it is critical to implement XSS protection carefully, regardless of your OAuth solution.