Kerb validation #9
Description
Possible implementation that does not require reinventing the kerb authentication wheel:
- Check if the user is signed into Element, and get the access token from local storage
- Otherwise, act as a Matrix client and implement single-sign-on
- Issue a more restrictive token via https://playground.matrix.org/#post-/_matrix/client/v3/user/-userId-/openid/request_token. (not a full access token, just for verifying identity)
- If we did #\2, sign out immediately (our custom SSO destination would extract the token, get a new OpenID token, and then shortly sign out)
- Keep the OpenID token in local storage, and use it as an auth token when doing requests.
- The backend should validate this token via https://spec.matrix.org/v1.8/server-server-api/#get_matrixfederationv1openiduserinfo (perhaps in SvelteKit via variables) and deny unauthorized requests
- Corollary: once all backend requests are authenticated, we can safely assume that it is the user themselves requesting to do actions, so we can add additional features or backend endpoints such as "what class group chats am I already in?" (not something I would add at the moment since I don't want people being able to query other people's list)
Notes on OpenID:
Third-party services can exchange an access token previously generated by the Client-Server API for information about a user. This can help verify that a user is who they say they are without granting full access to the user’s account.
(https://spec.matrix.org/v1.8/server-server-api/#openid)
Note that Matrix doesn't use OIDC for authentication yet and uses its own custom-built auth: https://areweoidcyet.com/
Some considerations:
- Don't forget to namespace everything we store in local storage since we don't want to conflict with Element's.
- Be extra sure that our code won't sign you out of Element. The sign out logic should be in a different route that only gets triggered via SSO.