CAS SSO

Posted 2021-02-04 lawrenceseattle

https://wiki.bytedance.net/pages/viewpage.action?pageId=250287686
https://wiki.bytedance.net/pages/viewpage.action?pageId=235613955
https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html

效果
在 sso.bytedance.com登陆后 xxx.bytedance.net会自动登陆，并获得用户信息。
实现
1、申请授权，https://sysworkflow.bytedance.net/entry/ssoauth
授权完成后，前端需要（一般是后端判断未登录301）向sso.bytedance.com发起请求（sso.bytedance.com已登录的 ），会得到sso.bytedance.com对https://xxx.bytedance.net/ 的授权ticket，示例代码：

var xhr=new XMLHttpRequest
var authUrl=‘https://sso.bytedance.com/cas/login?service=https://xxx.bytedance.net/&renew=false‘
xhr.open(‘GET‘,authUrl)
xhr.send()
sso.bytedance.com通过301方式返回ticket：https://xxx.bytedance.net/?ticket=ST-1539486694-65DVVgDrPIrvSmxsyrPCldtFsUsSeWMl

2、xxx.bytedance.net收到https://xxx.bytedance.net/?ticket=ST-1539486694-65DVVgDrPIrvSmxsyrPCldtFsUsSeWMl请求后，
需要向sso.bytedance.com发起请求，拿 ticket 换用户信息，接口为
https://sso.bytedance.com/cas/serviceValidate?ticket=${TICKET}&service=https://xxx.bytedance.net/，ticket用后过期
返回参数为 xml 格式，解析获得用户数据。

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
<cas:authenticationSuccess>
<cas:user>mapeng</cas:user>
<cas:attributes>
<cas:email>[email protected]</cas:email>
<cas:full_name>马鹏 8959027</cas:full_name>
</cas:attributes>
</cas:authenticationSuccess>
</cas:serviceResponse>

3、将用户数据存入 session，下次请求来，如果 session 有用户数据则自动登陆，没有则跳转到authUrl。

流程

1. 进入系统，前端发请求，后台api返回401，后端或前端redirect

   const loginCas = () => {
   const currentUrl = window.location.href;
   const retUrl = ‘http://developer.bytedance.net/api/v1/accounts/login‘;
   const encodeUrl = encodeURIComponent(${retUrl}?next=${currentUrl});
   const casUrl = //sso.bytedance.com/cas/login?service=${encodeUrl};
   window.location.href = casUrl;
   };
2. cas server校验域名是白名单，生成ticket并携带到query string，重定向至1中service的url。
3. 自身的server拿到ticket，去cas server验证合法性并获取用户信息。

4. 拿到用户信息，存下session，redirect到1中前端的next地址，种cookie。

OAuth 与 CAS区别

实现思路：
CAS的单点登录时保障客户端的用户资源的安全。CAS客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS客户端）的资源。
OAuth2则是保障服务端的用户资源的安全。OAuth2获取的最终信息是，我（OAuth2服务提供方）的用户的资源到底能不能让你（OAuth2的客户端）访问

过程解释：
CAS的单点登录，资源都在客户端这边，不在CAS的服务器那一方。用户在给CAS服务端提供了用户名密码后，作为CAS客户端并不知道这件事。随便给客户端个ST，那么客户端是不能确定这个ST是用户伪造还是真的有效，所以要拿着这个ST去服务端再问一下，这个用户给我的是有效的ST还是无效的ST，是有效的我才能让这个用户访问。
oauth2认证，资源都在oauth2服务提供者那一方，客户端是想索取用户的资源。
所以在最安全的模式下，用户授权之后，服务端并不能直接返回token，通过重定向送给客户端，因为这个token有可能被黑客截获，如果黑客截获了这个token，那用户的资源也就暴露在这个黑客之下了。
于是聪明的服务端发送了一个认证code给客户端（通过重定向），客户端在后台，通过https的方式，用这个code，以及另一串客户端和服务端预先商量好的密码，才能获取到token和刷新token，这个过程是非常安全的。
如果黑客截获了code，他没有那串预先商量好的密码，他也是无法获取token的。这样oauth2就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了。

总结：
CAS登录和OAuth2在流程上的最大区别就是，通过ST或者code去认证的时候，需不需要预先商量好的密码。