Microsoft Passport & Windows Live ID Service
Microsoft Passport
统一的登录认证服务，MS维护用户的账号、密码，提供登录认证服务
认证机制：
1. 站点加入Passport Network时，得到公钥。站点与Passport Server之间的通讯可以使用数字签名、加密方式，数字签名和加密参考http://www.cnblogs.com/RicCC/archive/2007/03/11/WSE-Security.html
2. 站点将登陆认证委托给Passport Server
3. Passport Server对用户登录认证成功之后，将PUID（Passport Unique ID）、认证时间等信息打包生成ticket（票据），发送给站点（签名、加密）
4. 站点解开票据得到认证结果
需要处理的方面：
1. 站点不能每次都向Passport Server验证登陆信息，因此将ticket存在cookie中缓存。Passport Server无法访问站点的cookie，所以存cookie的动作必须由站点操作
2. ticket需要有有效期的管理。例如30分钟的有效时间，ticket过期需要重新到Passport Server请求新的ticket
3. 多站点登录问题。比如用户已经通过站点A进行了Passport认证，Passport Server会在客户端记录自己的cookie信息，使用户在访问加入了Passport Network的站点B而又需要登录认证时，可以实现后台自动登录
4. 退出登录。在cookie中存储各个已登录站点，退出时对每个站点调用登出处理页面
Passport Server的cookie信息：
MSPAuth: MS Passport Authentication，存储加密的ticket，其中包括：最后刷新时间、最后手动登录时间（与自动登录区别）、密码标记以及其他标记
MSPSec: MS Passport Security，支持SSL的浏览器会存储该cookie值，使用HTTPS协议，内容包括用SSL编码的PUID和密码，用于自动登录
MSPVis: MS Passport Visited Sites，存储当前登录之后访问过的，退出登录时需要回call的站点列表，存放的是站点ID列表，不加密
详细处理流程：
1. 第一次登录
a). 用户在站点1请求需要登录认证的页面，站点1检查cookie发现没有登录，给用户显示一个登陆提示信息
b). 用户点击登录按钮，登录认证请求直接委托给Passport Server
c). 因为是第一次登录，Passport Server向用户显示登录页面（Passport Server读取自己的cookie可以判断用户在Passport Server上的登录认证情况）
d). 用户向Passport Server提交账号、密码等认证信息
e). Passport Server进行登录验证，验证成功后生成2份票据（票据包含用户的PUID、时间戳等信息），1份以QueryString方式传给站点1（这份使用站点的密钥加密），1份保存在Passport Server域名的cookie中（MSPAuth，这份使用Passport Server的密钥加密）。另外也在Passport Server域名的cookie中生成MSPSec、MSPVis项。最后将用户界面重定向到站点1
f). 站点1将票据记录到cookie，正常显示用户请求的页面
说明：
设计Passport时，在步骤a的时候，站点1有2种处理方式
一是直接显示一个站点1自己的登录界面，让用户提供账号、密码，由站点1自动向Passport的登录认证页面提交，这种方式存在一个问题，即用户将账号、密码暴露给了站点1
另外一个是上面描述的流程，站点1仅显示一个登陆提示信息的界面，用户点击登录按钮后重定向到Passport的登录认证页面去，这样用户的账号、密码仅提供给Passport Server
关于Passport Server将票据返回给站点1，也可以有2种处理方式。一是每个站点定义一个登录成功后的处理页面，接受票据写入cookie，然后再重定向到最初请求的页面；另一种是直接由最初请求的页面进行登录成功后的处理操作，可以采用公共处理方法实现，Passport认证成功后就直接将票据传给最初请求的页面
后续的认证验证，站点1直接读取cookie可以判断出来，如果有票据过期策略，则站点需要处理票据过期，重新请求票据
2. 单点登录
结合1中第一次登录，单点登录的处理是比较好理解的。不同之处在于Passport Server接收到登陆认证请求之后，从Passport Server的cookie中读取信息，知道用户已经登录，因此不需要再向用户显示Passport的登录界面，直接使用cookie中Passport Server的票据，为站点2生成票据并发送给他
说明：
设计Passport实现SSO，单点登录站点2时，站点2不可避免需要向Passport Server进行一次认证请求的交互处理，因为Passport Server和站点2之间都无法互访问cookie，而站点2的cookie中没有票据信息
只是类似1.第一次登录中的说明，在界面流程设计上可以有些变化，例如站点2可以不用向用户显示登录信息界面，直接将登陆请求委托给Passport Server，因为对于站点2来说，其处理方式就是一个第一次登录的处理流程
3. 退出登录
详细处理流程：
a). 用户在某个站点，例如站点2点击退出按钮，退出登录的操作直接委托给Passport Server
b). Passport Server从cookie读取已登录站点列表，逐个站点执行退出登录操作（包括清除站点自己的cookie票据信息等），另外Passport Server也需清除自己的cookie（与本次登录相关的）
c). 重定向到站点2退出登录后的返回界面
4. 过期策略
给每个站点生成的票据，其中可以包含过期策略信息
票据中包含用户最后一次输入密码登陆的时间戳，票据最后一次在Passport Server上刷新的时间戳。如果站点票据过期，站点重新向Passport Server提交认证请求，Passport Server验证登陆情况，刷新时间戳，重新生成票据发送给站点
对于Passport Server的票据信息，也可以定义过期策略（Time Window，时间窗），当Passport Server的票据过期时，会要求用户重新输入账号密码进行登录。考虑Passport Server的票据是否设计刷新机制等，否则一般的情况可能是在浏览器关闭时将Passport Server票据置为过期
5. 安全登录、自动登录
登录认证可以采用SSL方式，这将要求站点的返回地址也是基于SSL的，使用SSL时在Passport Server的cookie中记录MSPSec项
使用MSPSec中的信息可以进行自动登录，MSPSec的保存时间长
Widnows Live ID Service
Live ID Service在Passport的基础上进行了扩展，定义了Resource Provider、Application Provider等，不仅仅是登陆认证服务，而成为一个多方的资源、应用的整合平台
概念：
1. Application provider: 应用提供者
2. Consent token: 许可标记，内容包括delegation token、refresh token、可用资源和操作、过期时间等，他是用户通过Live ID Service，给Application Provider提供的授权许可文件，指示某个Application Provider可以使用该用户的哪些资源，可以进行哪些操作等。consent token有过期时间，过期之后使用refresh token重新从Live ID Service刷新
3. Delegation token: Live ID Service提供给Application Provider，作为Application Provider向Resource Provider请求服务时的认证信息，内容包括用户ID、Applicatio ID、用户许可的Offer详细信息、过期信息等。Application Provider无法解开delegation token，只有Resource Provider才可解开。delegation token同样包含过期信息，使用refresh token刷新
4. Refresh token: 可以说他是用户对某个Application Provider许可的一个唯一标记，在用户的整个授权期间都有效，可以用来刷新consent token、delegation token，他只能被Live ID Service的renewal service解开使用
5. Resource Provider: 资源提供者
6. Offer: 包括一系列资源，以及对每个资源可以进行的操作列表
整体过程分为颁发许可（Granting Consent）和使用许可（Using Consent）2个方面
Granting Consent需要用户交互，即由用户决定某个Application Provider可以对自己的哪些资源做什么操作，使用许可不需要用户交互，Application Provider根据Consent token在后台自动使用Resource Provider提供的offer（即资源服务）
参考：
Microsoft Passport 101
Introduction to Windows Live ID
统一的登录认证服务，MS维护用户的账号、密码，提供登录认证服务
认证机制：
1. 站点加入Passport Network时，得到公钥。站点与Passport Server之间的通讯可以使用数字签名、加密方式，数字签名和加密参考http://www.cnblogs.com/RicCC/archive/2007/03/11/WSE-Security.html
2. 站点将登陆认证委托给Passport Server
3. Passport Server对用户登录认证成功之后，将PUID（Passport Unique ID）、认证时间等信息打包生成ticket（票据），发送给站点（签名、加密）
4. 站点解开票据得到认证结果
需要处理的方面：
1. 站点不能每次都向Passport Server验证登陆信息，因此将ticket存在cookie中缓存。Passport Server无法访问站点的cookie，所以存cookie的动作必须由站点操作
2. ticket需要有有效期的管理。例如30分钟的有效时间，ticket过期需要重新到Passport Server请求新的ticket
3. 多站点登录问题。比如用户已经通过站点A进行了Passport认证，Passport Server会在客户端记录自己的cookie信息，使用户在访问加入了Passport Network的站点B而又需要登录认证时，可以实现后台自动登录
4. 退出登录。在cookie中存储各个已登录站点，退出时对每个站点调用登出处理页面
Passport Server的cookie信息：
MSPAuth: MS Passport Authentication，存储加密的ticket，其中包括：最后刷新时间、最后手动登录时间（与自动登录区别）、密码标记以及其他标记
MSPSec: MS Passport Security，支持SSL的浏览器会存储该cookie值，使用HTTPS协议，内容包括用SSL编码的PUID和密码，用于自动登录
MSPVis: MS Passport Visited Sites，存储当前登录之后访问过的，退出登录时需要回call的站点列表，存放的是站点ID列表，不加密
详细处理流程：
1. 第一次登录
a). 用户在站点1请求需要登录认证的页面，站点1检查cookie发现没有登录，给用户显示一个登陆提示信息
b). 用户点击登录按钮，登录认证请求直接委托给Passport Server
c). 因为是第一次登录，Passport Server向用户显示登录页面（Passport Server读取自己的cookie可以判断用户在Passport Server上的登录认证情况）
d). 用户向Passport Server提交账号、密码等认证信息
e). Passport Server进行登录验证，验证成功后生成2份票据（票据包含用户的PUID、时间戳等信息），1份以QueryString方式传给站点1（这份使用站点的密钥加密），1份保存在Passport Server域名的cookie中（MSPAuth，这份使用Passport Server的密钥加密）。另外也在Passport Server域名的cookie中生成MSPSec、MSPVis项。最后将用户界面重定向到站点1
f). 站点1将票据记录到cookie，正常显示用户请求的页面
说明：
设计Passport时，在步骤a的时候，站点1有2种处理方式
一是直接显示一个站点1自己的登录界面，让用户提供账号、密码，由站点1自动向Passport的登录认证页面提交，这种方式存在一个问题，即用户将账号、密码暴露给了站点1
另外一个是上面描述的流程，站点1仅显示一个登陆提示信息的界面，用户点击登录按钮后重定向到Passport的登录认证页面去，这样用户的账号、密码仅提供给Passport Server
关于Passport Server将票据返回给站点1，也可以有2种处理方式。一是每个站点定义一个登录成功后的处理页面，接受票据写入cookie，然后再重定向到最初请求的页面；另一种是直接由最初请求的页面进行登录成功后的处理操作，可以采用公共处理方法实现，Passport认证成功后就直接将票据传给最初请求的页面
后续的认证验证，站点1直接读取cookie可以判断出来，如果有票据过期策略，则站点需要处理票据过期，重新请求票据
2. 单点登录
结合1中第一次登录，单点登录的处理是比较好理解的。不同之处在于Passport Server接收到登陆认证请求之后，从Passport Server的cookie中读取信息，知道用户已经登录，因此不需要再向用户显示Passport的登录界面，直接使用cookie中Passport Server的票据，为站点2生成票据并发送给他
说明：
设计Passport实现SSO，单点登录站点2时，站点2不可避免需要向Passport Server进行一次认证请求的交互处理，因为Passport Server和站点2之间都无法互访问cookie，而站点2的cookie中没有票据信息
只是类似1.第一次登录中的说明，在界面流程设计上可以有些变化，例如站点2可以不用向用户显示登录信息界面，直接将登陆请求委托给Passport Server，因为对于站点2来说，其处理方式就是一个第一次登录的处理流程
3. 退出登录
详细处理流程：
a). 用户在某个站点，例如站点2点击退出按钮，退出登录的操作直接委托给Passport Server
b). Passport Server从cookie读取已登录站点列表，逐个站点执行退出登录操作（包括清除站点自己的cookie票据信息等），另外Passport Server也需清除自己的cookie（与本次登录相关的）
c). 重定向到站点2退出登录后的返回界面
4. 过期策略
给每个站点生成的票据，其中可以包含过期策略信息
票据中包含用户最后一次输入密码登陆的时间戳，票据最后一次在Passport Server上刷新的时间戳。如果站点票据过期，站点重新向Passport Server提交认证请求，Passport Server验证登陆情况，刷新时间戳，重新生成票据发送给站点
对于Passport Server的票据信息，也可以定义过期策略（Time Window，时间窗），当Passport Server的票据过期时，会要求用户重新输入账号密码进行登录。考虑Passport Server的票据是否设计刷新机制等，否则一般的情况可能是在浏览器关闭时将Passport Server票据置为过期
5. 安全登录、自动登录
登录认证可以采用SSL方式，这将要求站点的返回地址也是基于SSL的，使用SSL时在Passport Server的cookie中记录MSPSec项
使用MSPSec中的信息可以进行自动登录，MSPSec的保存时间长
Widnows Live ID Service
Live ID Service在Passport的基础上进行了扩展，定义了Resource Provider、Application Provider等，不仅仅是登陆认证服务，而成为一个多方的资源、应用的整合平台
概念：
1. Application provider: 应用提供者
2. Consent token: 许可标记，内容包括delegation token、refresh token、可用资源和操作、过期时间等，他是用户通过Live ID Service，给Application Provider提供的授权许可文件，指示某个Application Provider可以使用该用户的哪些资源，可以进行哪些操作等。consent token有过期时间，过期之后使用refresh token重新从Live ID Service刷新
3. Delegation token: Live ID Service提供给Application Provider，作为Application Provider向Resource Provider请求服务时的认证信息，内容包括用户ID、Applicatio ID、用户许可的Offer详细信息、过期信息等。Application Provider无法解开delegation token，只有Resource Provider才可解开。delegation token同样包含过期信息，使用refresh token刷新
4. Refresh token: 可以说他是用户对某个Application Provider许可的一个唯一标记，在用户的整个授权期间都有效，可以用来刷新consent token、delegation token，他只能被Live ID Service的renewal service解开使用
5. Resource Provider: 资源提供者
6. Offer: 包括一系列资源，以及对每个资源可以进行的操作列表
整体过程分为颁发许可（Granting Consent）和使用许可（Using Consent）2个方面
Granting Consent需要用户交互，即由用户决定某个Application Provider可以对自己的哪些资源做什么操作，使用许可不需要用户交互，Application Provider根据Consent token在后台自动使用Resource Provider提供的offer（即资源服务）
参考：
Microsoft Passport 101
Introduction to Windows Live ID
