10签名登录数据：主要是用客户端私钥签名设备的唯一标识和挑战码，在开启指纹认证时指定了必须采用指纹授权的方式才能使用私钥，这样能确保签名是由认证过的用户发起的（准确的说是手机上登录过指纹的所有用户，在开启指纹认证时已经提示用户所有录入的指纹都将可以用来登录，同时如果指纹发生变化，会让用户重新确认，所以可以认为他们都是有权限的用户）；服务端如果验证签名通过，则代表数据在传输过程中没有被篡改，登录是在可信的客户端发起的；前后端的认证结果结合起来就代表登录是由认证过的用户发起的。
在开启指纹阶段，已经将设备唯一标识、客户端公钥绑定到了用户记录，所以签名验证通过后，就可以生成当前用户的登录Token，并在后续的客户端与服务端的一般交互中使用这个Token。在关键的交互，比如支付中，还是要使用指纹认证这种安全性更高的方式。
以上就是APP中的指纹认证原理，指纹登录和指纹登录的过程差不多，只不过支付需要更高的安全等级，指纹认证可以满足这个安全要求。
客户端身份认证的问题在上文APP的指纹注册阶段，客户端生成了一对非对称密钥，用于后续服务端认证客户端的身份，这个密钥在当前的手机中已经有了成熟的安全存储和使用方法，这就是TEE（可信执行环境）：
客户端私钥被TEE安全密钥加密存储在手机中，目前没有破解之法；同时还可以指定只有通过了本机指纹认证才能使用私钥对数据进行签名和加密；再者如果手机中加入了新的指纹或者删除了指纹，存储的私钥就会失效；所以密钥的存储和使用是可以保证安全的。
但是还存在其它的安全隐患：
1、服务端无法确认上传的客户端公钥能否代表客户端身份，任何程序都可以生成一对非对称密钥，然后对数据进行签名，再把公钥一起发到服务端，服务端仅能验证签名的正确性，但是无法验证公钥的来源，也就无法验证客户端的身份。某些解决方案中会在客户端集成一个认证器SDK，这个SDK生成的认证信息中会携带一些特殊识别信息，而且每个应用每个机器不同，很难破解，后端可以据此判断是在集成了认证器SDK的应用中发起的。但是也有一些难题，识别信息的生成方法可能会被破解，还有怎么确认是用户发起的还是恶意程序发起的？
2、密钥生成过程中可能被黑客替换，存储和使用再怎么安全也无济于事了。这个在微信的技术资料中提到过，Android的密钥生成有被拦截的可能，不确定当前是不是解决了。这也说明底层框架和操作系统也可能是不可信的，在某些场景下必须慎重考虑。
3、以上两个问题在Root或者越狱之后的手机中更严重，APP、SDK和操作系统都无法信任了，所以很多金融类APP不支持在Root或者越狱的手机上使用指纹认证，不过道高一尺魔高一丈，还是有一些方法来欺骗APP，这也不乏部分用户的支持（自作X啊）。
这个问题有好的办法解决吗？有，设备出厂前就把私钥保存到TEE中。
Android中的密钥安全大家应该知道Android系统是开源的，很多手机厂商都在生产Android手机，市面上有多个厂商在竞争，谁也不服谁，所以要想推广上文提到的出厂前内置私钥的方法，就必须统一标准。在国内腾讯和阿里具备这样的影响力，腾讯搞了SOTER，阿里搞了IFAA，两者都要求手机厂商在产线上生成一对非对称密钥，私钥写入手机TEE，即使拿到了手机当前也没有破解之法，私钥也就不会被泄漏，除非手机厂商搞事情，不过如果手机厂商真的这样做了，就离倒闭不远了；公钥上传到认证服务器，认证的时候用于验证手机APP上传的数据签名，验证通过了就能代表是在对应的手机发起的认证。
同时为了推广这个技术，这种协议还支持别的厂商APP接入进来。但是这样就很容易泄漏APP的商业隐私 ，比如SOTER每次支付都要去腾讯的认证服务器认证一下，据此就可以推断你的业务行为和交易量，所以SOTER又搞了应用密钥和业务密钥，来尽量消除这个商业风险；同时针对Android密钥生成可能被拦截的问题，让手机厂商装个补丁包就解决了，比如替换掉不安全的中间环节。下边来看下应用密钥和业务密钥的产生过程。