Ken, To clarify, the TGT is not sent to the client. TGC is all that is needed. If all your apps are on same domain, does CORS apply?
You could invalidate your app session when JWT expires. App would then follow normal authentication behaviour and redirect to CAS. This of course would not work if you stored data in the app session. I suppose it is possible to have a field in the session to indication authentication (php probably works like this). I have not used JWT nor CAS ajax so take my suggestion as a wild idea. Ray On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b240c4091372f26d3af98a65fdd6c21c431d9d9c.camel%40uvic.ca.
