前后端与 Cas 集成，以及后端的做法。

一、做法

问题：浏览器将cas server 签发的ticket 传给webapp后端，webapp后端向cas server 验证通过后，是webapp后端自己用 session 管理用户缓存就行，然后后续不需要经过 cas server。还是说每次都需要重新向 cas server 验证？

回答：
在使用 CAS (Central Authentication Service) 进行单点登录 (SSO) 时，通常的流程如下：

1. 用户通过浏览器访问 Web 应用： 用户首次访问 Web 应用时，如果用户没有登录，Web 应用会将用户重定向到 CAS Server 进行身份验证。

2. CAS Server 进行身份验证： 用户在 CAS Server 上输入凭据（如用户名和密码）进行身份验证。

3. CAS Server 签发 TGT 和 Service Ticket (ST)： 验证通过后，CAS Server 会签发一个 Ticket Granting Ticket (TGT) 给用户，并且为 Web 应用生成一个 Service Ticket (ST)。

4. Web 应用验证 Service Ticket： 浏览器携带 ST 返回 Web 应用，Web 应用将这个 ST 发送给 CAS Server 进行验证。

5. CAS Server 验证 ST 并返回用户信息： CAS Server 验证 ST 并返回用户的身份信息给 Web 应用。

6. Web 应用创建会话 (Session)： Web 应用使用接收到的用户信息创建一个本地会话（session），然后将会话标识（如 Cookie）返回给用户的浏览器。

在这个流程中，Web 应用后端自己用 session 管理用户缓存是常见且推荐的做法。具体步骤如下：

• 一旦 Web 应用从 CAS Server 成功验证了 ST，并获取到用户信息后，Web 应用通常会在其自己的服务器上创建一个 session 来管理用户的登录状态。
• 这个 session ID 会通过 Cookie 等机制返回给用户的浏览器。
• 在用户后续的请求中，浏览器会携带这个 session ID，Web 应用可以通过 session ID 来验证用户的登录状态，而不需要每次都重新向 CAS Server 验证。

这样做的好处是减少了对 CAS Server 的依赖和网络开销，同时也提高了系统的性能。

总结：

• Web 应用在首次接收到并验证通过 CAS Server 签发的 Service Ticket 后，会创建一个本地 session 来管理用户的登录状态。
• 在用户的后续请求中，Web 应用可以通过 session 来验证用户，无需每次都重新向 CAS Server 进行验证。

这种机制确保了用户在登录后的访问效率，同时保持了一定的安全性。