保护使用Play框架开发的REST API

我目前正在使用Play Framework 2.3开发一个REST/JSON API。我目前正在考虑一种有效但简单的方法来保护API。所谓安全性，我的意思是某些操作需要最终用户通过身份验证才能被接受

目前，我依靠的是Play Framework会话管理（作为提醒，它将所有会话数据存储在一个签名cookie中，并在每个查询中发送-因此，它是无状态的，即使客户端可以读取cookie，也无法更新）

流程非常简单：

最终用户通过API客户端发送登录查询进行登录

如果接受，则在回复中设置cookie

当发送下一个查询时，API客户机自动添加cookie，因此最终用户被API识别

我的问题是：我真的需要在安全方面更进一步吗？我找不到现有机制无法正常工作的原因

提前谢谢

PS：目前我既是API的开发者又是API的消费者，没有公开发布的计划

---

PPS：我正在开发的客户端是一个使用AngularJS的简单Web应用程序，您不需要它。这是正确的解决方案

你可以只从可用性的角度考虑使用代币

---

当然，我假设您使用https

我不理解这个问题，因为“进一步”是非常广泛的。既然你是唯一的消费者，为什么还要对自己施加进一步的安全限制？您关心的是什么？只是一般的安全最佳实践、框架安全性的完整性，还是其他什么？正如我所说，API确实不是公开的。在这种情况下，这只是为了确保我不会忘记一些可能导致安全漏洞的大问题（是的，最佳实践）。但老实说，我的问题也适用于其他使用公共API的用例。请看这篇文章，它解释了基于HTTPs的issueYep上play和play自身上下文中的跨站点请求伪造。因此，我看不到任何使用令牌（JWT）的安全理由。不同的方面-是的，代币是更“休息”的方式，更灵活。关于cookie还有一件事——它甚至比其他头安全一点，但只有一点——比如“HTTPOnly”和“Secure”。您可以尝试使用Http头x-auth-token，而不是在cookie中设置值。尽管这不是一个可以遵循的规则，但它是基于令牌的身份验证的标准