Allow authentication in deploy previews

[jasonaowen]

Keycloak does not currently support wildcards in redirect-uris. We accepted this lack of out-of-the-box support in Phase I, but here at the beginning of Phase II it is worth re-evaluating our options for a key workflow.

(Follow-up from a conversation on PR #327.)

[jasonaowen]

It's looking like the new OAuth 2.1 spec (still in development) is going to explicitly forbid wildcards in redirect-uris:

Redirect URIs must be compared using exact string matching

This is apparently already a recommended practice which is being promoted into the specification.

So, even if two years of no progress on the Keycloak side were not already a strong clue, this makes it even less likely.

However, all is not lost: we can automate the thing we've occasionally done by hand. Keycloak has an administrative API, and there is an API endpoint for updating a client; it should be possible to craft a GitHub Action that uses the KeyCloak API to update the client's redirect URI list.

That will involve trusting GitHub with some credentials to modify our KeyCloak instance. I believe we can somewhat restrict the scope of its authorization, but the restrictions might not be as fine-grained as I'd like - ideally, only modifying the redirect URIs of a particular client, but I think it'll be modifying any existing client.

So, it's possible, and probably worth doing, but not as smooth or secure as I'd like.

[reefdog]

@slifty Notes that one way to brute-force this, thanks to the predictable pattern of deploy domains, is just to add the next 1000 or so generated domains to Keycloak: https://deploy-preview-{n}--philanthropy-data-commons-viewer.netlify.app/