虽然OAuth的基本有理早就知道。但是具体实现的一些方案细节是什么并没有研究过，现在就跟踪一下Maestro的实现。
Maestro授权的restapi是/authorize，参数
response_type: code--指定返回类型，code表示，返回的一串code代表当前请求者认证后的身份
user_oauth_approval: true--具体还不知什么作用
client_id: OnePortal_key--有很多第三方应用都会注册到Maestro表明自己需要Maestro授权，此参数是认证请求者指定对特定第三方应用认证授权。
redirect_uri: http://thirdapp/app/j_spring_oauth_security_check?oauth_provider_type=ClopsOAuth2Provider--认证授权后跳转到第三方的入口，不是必选。Maestro服务端授权，也就是生成一个code为key，UserProfile对象为value的抽象，等待第三方应用来通过code获取UserProfile对象。
===
Maestro怎么知道请求者是谁，所以Maestro先让请求者用Maestro账号登录，登录后以cookie方式下发sessionid给请求者——用于下次请求Maestro授权。
===
Maestro授权后，使用redirect_uri参数值拼接刚刚生成的code，返回请求者使浏览器带code自动跳转到第三方应用。
第三方拿到code后，向Maestro请求该code代表的UserProfile数据【第三方应用根据Maestro提供的文档配置请求地址和格式，第三方应用也会被Maestro认证后才能接收UserProfile数据】，成功后把UserProfile数据与之前已经下发到请求者cookie的sessionid关联保存，sessionid作为cookie下发给请求者——用于下次访问该第三方应用。第三方服务端只向Maestro请求一次，如果Maetro有UserProfile更新，需要第三方决定何时请求最新的UserProfile，最简单就是等到用户主动logout再次请求login。
如此看来，Maetro可以看做是存储UserProfile的DB，用户先去Maestro打开开关表明第三方即将来请求UserProfile；
用户把Maestro返回的信物交给第三方，让第三方带着信物向Maestro请求UserProfile数据；
第三方用信物code取回UserProfile，绑定自己管理的sessionid。
用户使用第三方的sessionid与之交互。
===
--------------------------------
如何logout。用户logout时不涉及Maestro，因为只要第三方清除自己管理的session即可。spring提供配置的方式，执行delete cookie的标准操作。
CMP delete cookie后友好地跳转到了特定页面logout.jsp进而跳转到Maetro.logout.do，这个把当前用户从Maestro logout：如果不删除，当用户在第三方logout或者timeout之后访问，仍然会跳转到Maestro授权url，此时Maestro的session可能仍然没有过期，那么就会再次进入授权流程，从而使得此时第三方的logout和timeout等价于无效。这个应该是必选项。
---------------------------------
多说一句，所谓登录的本质就是用户拿着的sessionid是否在server端被认可。
login就是server端把sessionid绑定User信息，User信息可以来自查db或者查Maestro（抽象成一个db）。
logout就是在server端delete sessionid。