2015-06-16 252 views
3

以下认证制度似乎合理的:简单的令牌,如身份验证

  1. 客户端调用与到主服务器的用户名和密码登录终点。主服务器将其发送给另一个验证服务器(将不会再提及),如果这是有效的,并且主服务器知道用户ID,则返回yes/no。如果是,则生成一个随机标记(使用一些加密随机字符串的加密库),并存储该标记的哈希值(使用PHP的password_hash()),并在用户记录中保存12个小时到期。将令牌返回给客户端。

  2. 客户现在向其他终端添加“授权:令牌TOKEN + HERE + ABCD1234”。服务器确保auth头中令牌的哈希匹配数据库中的令牌(通过PHP的password_verify()使用salt),并且过期未被命中。如果它不匹配,或者超过期满,则发回一个401

似乎至少为基本HTTP认证,这只是具有base-64编码的用户为安全的:在报头中的密码?我之所以考虑这个方案是因为主服务器不会存储认证服务器用来登录的用户名/密码。

我忘了什么?这是非常不安全的?

回答

3

你的方案是不是从标准服务器端的会话,其中SESSION-ID通常是一个cookie中没有什么比一个随机令牌和存储在客户端不同,有2项改进:

  • 而不是一个cookie,您可以使用授权标头来传递令牌。这起到了CSRF保护的作用。
  • 你会在服务器端散列一个令牌。这有助于防止会话劫持,以防有人访问服务器端的令牌存储。
+0

现在查看会话ID。你的回答似乎表明这是一个合理的解决方案,然后呢? – Luke

+1

如果实施正确 - 我没有发现任何问题。但是请注意,“密码安全随机数生成器”实际上不是“一些加密随机字符串的加密库”。 –

+0

哈哈指出。文档似乎表明它具有密码安全性,但我会确保。干杯! – Luke

2

如果您看到Google的oAuth流程,那么您将了解Authorization如何为他们工作。

enter image description here

他们对授权和API调用不同的服务器。用户将身份验证详细信息发送到授权服务器并接收代码。 Google正在取得用户同意的过程以访问详细信息,但您可以跳过此流程以取得同意并仅在成功的详细信息中返回代码。

此代码可以进一步用于从API服务器获取访问令牌。所以你对API服务器的第一个请求就是获得访问令牌。谷歌也有能力刷新你的访问令牌。

所有后续对API服务器的请求都必须包含访问令牌。所以你似乎错过了这个代码交换过程,使它更安全。

更多信息:https://developers.google.com/identity/protocols/OAuth2

+0

该代码交换添加了什么? – Luke

+0

@Luke,它会添加两步验证。 – Avinash