移动 APP 端与服务器端用户身份认证的安全方案

公司的 mobile app 是外包给其他公司做的，所以现在他们需要我们提供 API 接口进行调试，由于没有 API 开发的经验，所以现在一个比较难把握的问题就是如何实现服务器端与移动 APP 端通信时的用户身份认证问题。
搜集了一些资料，大部分的建议是在服务器端生成一个 token 然后在通信报文的 headers 利用这个 token 来进行验证。
这里有两个问题，首先这样直接生成 token 进行认证的安全性。其次，生成的 token 应该怎么保存呢？存在 DB 里面还是哪个地方？(服务器端使用的是 php)

因为本身产品对安全性要求不是特别高，远没有达到网银之类的需求，所以在不考虑使用 oauth 等授权协议基础上，我比较希望知道一些常用的身份验证机制，以保证基本的安全性即可。

再把问题写清楚点：
1.怎么生成安全性比较高的 token。
2.token 需不需要设置过期时间（考虑到是 mobile app，所以这个比较难设计，因为很少
有人会在 app 上会 log out 再重新登录）。
3.token 除了存在 db 内，有没有一些更方便合适的方式。

回复内容：

公司的 mobile app 是外包给其他公司做的，所以现在他们需要我们提供 API 接口进行调试，由于没有 API 开发的经验，所以现在一个比较难把握的问题就是如何实现服务器端与移动 APP 端通信时的用户身份认证问题。
搜集了一些资料，大部分的建议是在服务器端生成一个 token 然后在通信报文的 headers 利用这个 token 来进行验证。
这里有两个问题，首先这样直接生成 token 进行认证的安全性。其次，生成的 token 应该怎么保存呢？存在 DB 里面还是哪个地方？(服务器端使用的是 php)

因为本身产品对安全性要求不是特别高，远没有达到网银之类的需求，所以在不考虑使用 oauth 等授权协议基础上，我比较希望知道一些常用的身份验证机制，以保证基本的安全性即可。

再把问题写清楚点：
1.怎么生成安全性比较高的 token。
2.token 需不需要设置过期时间（考虑到是 mobile app，所以这个比较难设计，因为很少
有人会在 app 上会 log out 再重新登录）。
3.token 除了存在 db 内，有没有一些更方便合适的方式。

1. APP里预埋一个token，结合时间戳/每次请求的一个随机值randstr，生成一个最终signature，在Server进行验证即可，（安全级别不是很高，但防大部分恶意请求没问题了）。
2. 如果还需要针对不同用户生成不同的sigature，可以结合手机的DeviceId，在首次请求是上报这个，以后的请求就把DeviceId也作为因子带入sigature的生成里。当然，这个过程也不是绝对安全的。

看你的意思是不需要绝对安全的，所以猜测你的目的是防恶意请求的，以上两种方式应该可以满足了。

告诉你一个很好的学习方式，去各大网站，微博、腾讯、Facebook、Google，看他们的OpenApi是怎么实现的，需要提供什么样的参数，你就可以依葫芦画瓢做出来了。

1. token一般可以用用户名和密码处理后生成。
2. token过期可做可不做，如果移动端发现token过期则跳到登录界面让用户重新登录即可。
3. 你是指客户端存token的地点还是服务器端？一般都可以存在数据库中，不过对移动设备来说存在XML中作为键值对更为普遍。

首先回答第三个问题：存在rdb不妥，本来保存的就是临时数据，没有持久化的必要，用缓存即可，memcached/redis均可。

为何说是临时数据，token本来是用来做授权的，应当只能允许可信用户使用，假如是长久数据，那么一旦token泄露，就难免会造成伪造访问的风险。

不知道提主的应用是用什么做用户认证，假定是传统的用户名密码认证方式，其实可以参考http的session，认证通过后生成的sessionid信息其实就可以作为后续访问的token。用户每次请求是携带uid+sid信息来即可，通过sid反查uid或者uid查询sid，然后匹配即可。在token超时时让用户重新来申请即可。对于移动端，建议走https通道。

如何生成安全性高的token，常规的签名算法就可以了，毕竟是不可逆的，原串组合方式不泄露就行，md5的话记得加盐。

对于在app中内置token的做法不建议。首先，内置的token所有应用统一呢？这样获取到了token，基本就可以伪造了，不同的设备不同呢？其实也差不多。而且这样实现起来也比较负责，因为server端要进行验证，猜测应当是用对称加密算法，签名验证？其实最大的疑问是真能用来授权么？我看题主提到了多账户的问题，那么设备与用户就不是一一对应的关系。

最简单用session，业务层上不用做太大的变动，呵呵。

应该采用 OAuth 2.0 Client Credentials Grant（最容易），或者 JSON Web Token模型（安全性更高）