1. 扫码登录

在微信网页版或者支付宝网页版，这种很常见。具体的流程是：
step1: 用户打开了页面，页面生成一个二维码（里面有一个新生成的ID，此生成流程可能通过服务器完成，如果是本地，服务端也已经知会该ID的意义）后，即发起对服务器的短连接轮询或者长连接请求。

step2: 用户在客户端内扫码，将扫码得到的ID和账号id提交到server，server记录该行为，认定扫码得到的ID可以通过该账号登录。

step3: 此时轮询或者长连接进行中，server响应返回该账号相关的信息，登录完成。

总结：打开页面并且二维码被用户看见时，代价已经开始支付了。无论是短连接的轮询（支付宝是3秒一次）还是长连接的保持对server都存在不小的开销。这里的流程设计是通过server的开销换回了比较自然、安全的登录体验。

2. 第三方登录

这里的第三方是指中立的平台，相对于某app的用户和某app的服务器，比如微信或者支付宝、QQ这些就是第三方。通过可信的第三方平台让app的用户可以无感知或者说小代价的创建账号并且登录到app的服务器端。

这里的业务分为三种情况:
1.首次登录。首次登录需要app方通过得到的第三方信息在后台自动创建账号并且与第三方信息绑定。
2.用户已经有账号并登录。这里只是进行了和第三方信息的绑定操作。
3.用户的第三方登录账号已经被创建过。这里会拿到第三方信息，在后台匹配到已经存在的账号，完成登录。

那么这里的业务是很好理解的，交互过程或者说第三方鉴权等操作是怎么完成的呢？这里的流程主要集中在平台方，作为app开发者可能很少关注这个实现的原理或者说方案细节，只是集成了平台方提供的sdk并在app内填入申请到的appkey和secret就万事大吉。那么我们就仔细分析一下，平台方究竟需要做哪些事情，才可以打通一个完整的流程。（从抓包流程来看QQ的比较好分析，我这里以QQ为例，各个平台实现的方案细节是有差异的的）

step1: 用户点击第三方登录请求，通过openurl拉起了平台app，可能传递了申请的渠道信息（用于表明自己的身份，属于合法的请求，不然平台方不认识你，连门岗都不给你靠近）。

step2: 进入平台app以后，如果用户点击了返回，立刻返回原app，通过sdk处理了相关的回调，sdk会知道请求被拒绝了，走失败的流程并且通知到用户（qq是这样的，微信是直接就通过了，没有这个流程）；如果用户点击同意了，获取到一个access code一样的东西（有一个有效期）返回到原app；原app拿这个code去请求平台服务器。这部分请求的代码是集成在sdk里面的，从抓包来看，qq的请求url是openmobile.qq.com。从时序分析可以看出来，该请求是在原app中发起而不是QQapp。这样我们就会拿到第三方的信息（比如头像之类的，应该还有一个用于匹配的唯一id,我们姑且称为openid），我们把该openid存在app的账号数据库内，用来标识和第三方的绑定关系。

需要注意的是这里有一个falldown的流程，如果用户没有安全平台的app,那么会弹出一个网页可以输入用户名密码进行oauth的鉴权，感兴趣的同学可以自行查看oauth2.0相关的资料。

3.简单的应用内跳转登录

这里的场景是这样，A和B是两个应用，我们希望在A应用直接可以跳转到B,并且进去之后可以免登录跳转到指定页面。

如果A和B是一个开发者账号下面的且共享账号密码，那么事情就非常简单，在iOS我们可以通过app group共享秘钥来实现免登录；

我们假设A和B是两个不同的应用开发商，A可以把账号信息在后台同步到B.我们可以设计一个简单的流程：A在后台和B的服务器相连，获取到B对应账号的有时限的token；在A跳转去B时我们带上这个token和其他信息，B拿这个token自动登录并根据其他信息直接展示指定页面。