这是一个创建于 3589 天前的主题，其中的信息可能已经有所发展或是发生改变。
在sof上看到一个答案，有点不能理解，求助。
http://stackoverflow.com/questions/3963877/creating-an-api-for-mobile-applications-authentication-and-authorization?rq=1#answer-3965689
The way I'm thinking about doing the login part of this in my projects is:
1. before login the user requests a login_token from the server. These are generated and stored on the server on request, and probably have a limited lifetime.
2. to login the application calculates the hash of the users password, then hashes the password with the login_token to get a value, they then return both the login_token and the combined hash.
3. The server checks the login_token is one that it has generated, removing it from its list of valid login_tokens. The server then combines its stored hash of the user's password with the login_token and ensures that it matches the submitted combined token. If it matches you have authenticated your user.
1、登陆前服务器先生成一个有lifetime的login_token并返回给app；
2、app先计算密码的hash值，然后将密码和login_token进行hash生成一个值，最后将login_token和combined hash一起返回；
3、服务器检查login_token，如果符合将它从可用login_token列表移除。服务器将用户密码的hash值以及login_token结合来验证和上传的token是否一致，一致则授权成功。
问题:第3步这里"its stored hash of the user's password"是什么时候保存的，第2步没有保存这个东西啊。
http://stackoverflow.com/questions/3963877/creating-an-api-for-mobile-applications-authentication-and-authorization?rq=1#answer-3965689
The way I'm thinking about doing the login part of this in my projects is:
1. before login the user requests a login_token from the server. These are generated and stored on the server on request, and probably have a limited lifetime.
2. to login the application calculates the hash of the users password, then hashes the password with the login_token to get a value, they then return both the login_token and the combined hash.
3. The server checks the login_token is one that it has generated, removing it from its list of valid login_tokens. The server then combines its stored hash of the user's password with the login_token and ensures that it matches the submitted combined token. If it matches you have authenticated your user.
1、登陆前服务器先生成一个有lifetime的login_token并返回给app；
2、app先计算密码的hash值，然后将密码和login_token进行hash生成一个值，最后将login_token和combined hash一起返回；
3、服务器检查login_token，如果符合将它从可用login_token列表移除。服务器将用户密码的hash值以及login_token结合来验证和上传的token是否一致，一致则授权成功。
问题:第3步这里"its stored hash of the user's password"是什么时候保存的，第2步没有保存这个东西啊。
 |
1
cxe2v 2015-01-30 10:15:18 +08:00
注册或者修改密码的时候保存的
|
 |
2
roricon 2015-01-30 10:49:59 +08:00  1
这个回答应该是基于这样的假设
1.应用已经存在一套使用 用户名/密码 的登录授权功能 2.新建的login_token功能，怎样跟原来的 登录授权 系统结合起来。 所以 问题:第3步这里"its stored hash of the user's password"是什么时候保存的，第2步没有保存这个东西啊。 回答如@cxe2v 是注册和保存密码时候保存的。 |
 |
3
cruelcage OP @cxe2v 谢谢，如果自己设计API的时候，是让服务器返回一个有时效的access token给app，然后app的后续请求都附带access token吗？那这样如果access token被中间人拿到了也照样是不安全的？
|
|
4
roricon 2015-01-30 10:55:27 +08:00
这也是为什么Restful的设计模式要求所有的请求都通过 TLS 的原因之一。
|
|
5
cruelcage OP @roricon 这样设计是不是就等于简化的OAuth2，因为我只想提供给自己的app可以consume的API。
1、保存access_token到一个表上，字段包括access_token的名字、时效、作用域、用户名等； 2、如果验证成功，服务器返回一个有时效的access token，app的后续请求就附带access token 3、app发送请求，服务器查找access_token表，如果找到就验证是否超时，未超时就继续执行；如果超时就删除； 4、然后验证请求的作用域，超域返回错误；未超域返回需要的数据； |
 |
6
zix 2015-01-30 12:37:05 +08:00
来看头像顺便歪楼
|
 |
7
pubby 2015-01-30 12:49:36 +08:00
@cruelcage access_token 被中间人拿到很有可能，跟访问网站时session cookie被拿到一样的。
1. 对发送数据做签名（客户端和服务端有约定好的secretkey) 2. 只允许走https 可以提高被窥探和利用的难度 |
 |
9
zhicheng 2015-01-30 16:37:49 +08:00
楼主说的是登录的设计，还是 Token Base 的 API 认证?
如果是 Token Base 的 API 认证，请使用 OAuth ，按照官方要求来。 如果是登录设计，不要在 App 中登录，请用链接跳到浏览器，并且域名用带绿条的 SSL 证书，浏览器认证完成后再带上认证之后的 blahblahblah 跳回应用即可。 当然如果对安全性要求不高的话，爱怎么搞就怎么搞。。。 |
|
10
roricon 2015-01-30 16:47:45 +08:00
@cruelcage 这个设计类似于 Django restful framework 中的 TokenAuthentication
你可以看下这里 http://www.django-rest-framework.org/api-guide/authentication/ |
Select Language