JWT Authentication proposal
JSON Web Tokens (JWT) are a standard that allows us to represent claims as JSON data and to sign said claims so that we know that we created the token when the user successfully authenticated. To learn more, this website is very useful: https://jwt.io/
The biggest advantage to JWT is the fact that they can be entirely stateless. This means that the only part of the application that needs to talk to an auth server is the parent app - plugins can just trust that the token is valid (this is checked by the parent app all routes), extract the relevant claims from the JWT e.g. ICAT session ID, fed ID, etc. and pass these to any services they need to interact with.
An example workflow is shown below:
However, this provides one major downside. Because the main advantage of using JWTs is that they are stateless and we don't need to contact an authorisation server in the plugins, this means that we lose the ability to revoke tokens. We could have a revocation list, but then we lose the advantage of plugins not needing to contact a server. The main way to protect against this is to make JWT short lived. You could either make the tokens themselves only last a short period of time that won't impact the user (e.g. a few hours, a day etc.) or you could have an access token/refresh token mechanism where the access token is very short lived (e.g. 5 mins) and the refresh token is alive for longer (e.g. a month) and the client can use the refresh token to generate new access tokens without needing to reauthenticate. You could then also introduce a blacklist for refresh tokens, which would mean a user would be required to re-authenticated once their shortlived access token runs out, which would emulate the revocation behaviour with a short delay.