Reintroduce token cache for MSC3861 OIDC auth

[erikjohnston]

This was added in #16117 and #16125 (note this needed the fix in #16216).

Reverted in #16258 due it being broken.

We should reintroduce these PRs (with fixes) once we have some CI for OIDC.

cc @hughns @sandhose

[erikjohnston]

I think this is blocked on us getting some basic CI for OIDC, to make sure we don't break it again?

[meson800]

Is there plans to reintroduce this and/or is there something that I could contribute to to help? I couldn't find an issue in this repo regarding CI, if that is the problem. I have messed around before with a mock OIDC server (in Go, so it's just a single binary you can setup) for CI testing purposes in the context of Headscale,.

I ask because I have an existing OIDC auth system that is not on the same server as my homeserver, and without a token cache I don't want to enable OIDC and incur the extra network call on every request.

[clokep]

I ask because I have an existing OIDC auth system that is not on the same server as my homeserver, and without a token cache I don't want to enable OIDC and incur the extra network call on every request.

Note that this ticket is only in regards to MSC3861 delegated auth. If you're using the standard oidc_providers` setting then this is unrelated.

[meson800]

Note that this ticket is only in regards to MSC3861 delegated auth. If you're using the standard oidc_providers` setting then this is unrelated.

Yes, I should have been more specific. I am running with oidc_providers right now and it works great, but I and some of the iOS users on my homeserver want to try out Element X, which only supports native OIDC. If there's something I can do to help, e.g. try to write some relevant OIDC CI I can help.

[clokep]

@sandhose Would be the one who knows if there's a plan here, I think. We'll see what they say.