具有多个客户端平台的应用服务器API的会话devise
我想要构build一个支持多种平台的应用程序：桌面应用程序（Mac / PC），Web（angularJS前端）和原生移动应用程序。
所以我正在考虑一个应用服务器，为上面的平台提供内部API。 我有一些关于如何支持login/注销的假设。 我会很高兴，如果任何人可以评论，如果我的想法是错的。
- 对于桌面和移动应用程序，“login”function将使用内部API来传递凭证，并作为回报将收到永久令牌。 桌面/移动应用程序将存储令牌并将其用于对应用程序服务器的任何后续请求。 从桌面/移动应用程序“注销”时，令牌将在服务器端丢弃，在前端应用程序端遗忘。
- 对于Web界面，angular度应用程序会将login后提供的令牌保留为cookie，并将其加载并将其用于对应用程序服务器的任何请求。
这是一种常见的模式？
您具有正确的基本结构，但是使用OAuth2则永远不会存储访问令牌。 访问令牌通常是一个不透明的string，允许访问您的API，将其存储在cookie或本地存储是好的，但从服务器发出一个永不过期的令牌将是非常不明智的（一个MITM攻击可能会永远支持您的身份） 。
为了解决这个问题，OAuth2的实现通常会将刷新令牌与访问令牌一起使用。 刷新令牌通常比访问令牌（访问令牌的到期时间和我想说的月份之间的任何地方）具有更长的到期时间范围。 刷新令牌类似于临时用户密码 – 它们不直接授予对API的任何访问权限，但是一个用户可以通过调用您的OAuth2刷新API来授权您的系统，并获得新的访问权限并刷新令牌，并具有新的到期时间。 这使您的应用程序有机会定期重新validation用户声明（可能他们的访问/angular色已更改，他们需要更新的声明）。
JWT令牌
访问令牌可能是您存储在服务器上的不透明string，但我强烈build议使用JWT令牌。 JWT令牌比不透明的（无意义的）令牌有两大好处：
1.客户索赔
你需要在你的客户端应用程序授权后做的第一件事就是查找各种东西来构build你的UI。 JWT令牌的优点在于，它们将所有用户声明（包括您的应用程序自定义用户声明）作为JSON对象有效内容存储在编码的string中，可以通过首先拆分令牌对客户端进行解码. ，将其分解成[ header, payload, sig ] 64位编码string。 然后，您可以base 64解码有效负载string，并通过JSON.parse运行它，这将产生您的声明键值对：
const access_token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ' const claims = JSON.parse(atob(access_token.split('.')[1])) console.info(claims)
我build议你看看我在这里所做的与authentication有关的答案： 使用Active Directory的REST API的授权方法
问题是关于活动目录，但我专注于OAuth，以及如何使用thinktecture或oauth2orize等工具实现自定义OAuth身份validation服务器。
一旦你有一个Oauth身份validation服务器（开箱即用的ADFS，自定义思想在.net，自定义oauth2orize在nodeJs），你可以插入任何东西，因为它是一个标准的身份validation协议。 例如，Xamarin有任何oauth2服务器进行身份validation： https ： //components.xamarin.com/gettingstarted/xamarin.auth 。 正如我在之前的回答中所提到的，任何Web服务器技术或JavaScript技术都可以处理OAuth2。
不要犹豫，问任何问题，以获得更多的细节，任何这些主题。
是的，这就是我现在为我的项目所做的。 这是一个常见的模式。
应用架构：
[Web Applications] <-HTTPS/TLS-> [Restful Web API] [PC Applications] <-HTTPS/TLS-> [Restful Web API] [Mobile Applications] <-HTTPS/TLS-> [Restful Web API] [Restful Web API] <-Authenticate-> [over LDAP or SQL Database] [Restful Web API] <-File Stream-> [File system/file server]
笔记：
有一些笔记会影响你的devise：
-
pipe理令牌生活时间。
- 确保您的令牌有一个短的过期date（必须在30分钟或更less）。 如果令牌已过期（或即将过期），则必须刷新令牌（有关更多详细信息，请参阅OAUTH2中的
refresh token）。 - 确保您的令牌在注销后被丢弃。
- 如果最终用户报告有人在未经他们许可的情况下使用他们的帐户。 确保你可以终止小偷的代币（这在企业应用程序中很重要）
- 确保您的令牌有一个短的过期date（必须在30分钟或更less）。 如果令牌已过期（或即将过期），则必须刷新令牌（有关更多详细信息，请参阅OAUTH2中的
-
保护您的令牌
- 避免将您的令牌存储在cookie中。 如果可以，请使用本地存储。
- 使用HTTPS而不是HTTP。
- 每个平台必须使用分离的令牌：这将是帮助如果您打算公开您的API到另一个开发人员/平台/供应商。
- 确保您logging所有发出的令牌历史logging（何时，由谁发出）。 想象一下，你的应用程序受到攻击，你不知道令牌来自哪里。 它会帮助你回答：
Were your private key stolen by attacker?!
-
保护你的静态资源（* .pdf，images，* .doc，…）
- 你不能以正常的方式保护你的静态资源（发送授权HTTP头）。 那么你必须通过Cookie发送（我不鼓励）。 所以，你必须为一个静态资源生成一个安全的令牌，这个令牌必须在5分钟或更短的时间内存在
是的，这与你所描述的有特别的偏差。 阅读OAuth2身份validation跳舞，因为它可能涉及第三方使用应用程序服务器validation客户端（桌面/networking/本地移动设备）。
例如，你可能想使用Facebook作为你的身份提供者，你的应用程序服务器将是服务提供者，试图login的用户将被引导到FB，在那里他将被发出令牌，他将用来与你的服务进行通信。
当你在这里时也检查JWT ，因为它为令牌authentication提供了额外的安全级别。
另外， Auth0即使你不打算使用它们，在各种 平台上提供了很好的身份validation文档。
@cchamberlain已经回答了，但是，你可以参考[这里]（利用活动目录的REST API的授权方法），我认为这将帮助你解决你的问题，
谢谢！