1.为什么app需要登陆这个操作？

一般来说，是否必要登录分三种情况：

①当打开应用时，就需要强制登录；

②打开应用，不强制登录，但使用部分功能时一定要登录；

③整个应用都不需要登录

①当打开应用时，就需要强制登录：

通常在即时通讯工具和SNS应用上出现。当用户做的每一个需要上传到云端服务器的动作（例如与好友聊天、点赞等等）都需要用户的账号做“背书”时，就需要在使用该应用的全过程中均保持登录。此外，还有一种情况是应用希望获得用户在使用时的所有操作记录，那也会强制用户在打开应用时就登录（例如小红书）

②打开应用，不强制登录，但使用部分功能时一定要登录：

这种情况一般出现在用户获取内容但不向服务器发送信息的应用里，比如资讯类、工具类等等。用户可以在非登录模式下获取应用推荐给用户的内容或者使用应用提供的工具等。但当用户需要定制化服务或者记录下自己的一些操作时，则可以用登录的方式解决。

③整个应用都不需要登录：

这类型的应用很有趣，甚至都不需要去设计登录功能。通常来说，一些纯粹的工具类软件便是这样。举个例子，在我的手机里有一款应用是没有登录功能的——彩云天气。每次用户打开它，查看天气，看看还有多长时间下雨，仅此而已。因此从当前这样的状况来看，它设置登录功能反而是多余的。不过随着产品不断发展，当推出了一些可玩性较高的功能时，可以配套着登录页面的实现，对应用来说，是一个促进留存的好方式。

是否必须登录才能使用app？

此必要性与用户和应用之间的交互方式有关。当用户需要发送信息给应用才能实现该应用的核心功能时，登录是必须的；而当用户不需要发送信息而只需要接收信息便能实现核心功能时，就并非一定要登录，只有当用户发送了发送信息给应用这一交互时，才会要求用户进行登录。

2.注册登录过程中如何保证账号和密码的安全？

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

客户端向服务器第一次发起登录请求（不传输用户名和密码）。

服务器利用RSA算法产生一对公钥和私钥。并保留私钥， 将公钥发送给客户端。

客户端收到公钥后， 加密用户密码， 向服务器发起第二次登录请求（传输用户名和加密后的密码）。

服务器利用保留的私钥对密文进行解密，得到真正的密码。

3.第一次登录需要输入账号密码，之后再次启动APP时不需要输入账号密码，这是为什么？（登陆保持）

         服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

客户端向服务器第一次发起登录请求（不传输用户名和密码）。

服务器利用RSA算法产生一对公钥和私钥。并保留私钥， 将公钥发送给客户端。

客户端收到公钥后， 加密用户密码，向服务器发送用户名和加密后的用户密码； 同时另外产生一对公钥和私钥，自己保留私钥, 向服务器发送公钥； 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。

服务器利用保留的私钥对密文进行解密，得到真正的密码。 经过判断， 确定用户可以登录后，生成sessionId和token， 同时利用客户端发送的公钥，对token进行加密。最后将sessionId和加密后的token返还给客户端。

客户端利用自己生成的私钥对token密文解密， 得到真正的token。

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端

4.App自动登陆的流程：

App发送保存的加密串到服务器，（加密串，用户名，mac，随机数）==>RSA公钥加密 

服务器用RSA私钥解密，再用AES解密加密串，判断用户名是否一致。如果一致，再以（用户名+Android/IOS/WP）为key到缓存里查询。如果判断缓存中的salt值和客户端发送过来的一致，则用户登陆成功。否则登陆失败。 

不用AES加密，用RSA公钥加密也是可以的。AES速度比RSA要快，RSA只能存储有限的数据。