ui: [BUGFIX] Properly encode non-URL safe characters in OIDC responses

[johncowen]

This PR fixes 2 problems with our OIDC flow in the UI, the first is straightforwards, the second is relatively more in depth:

1: A typo (1.10.1 only)

During #10503 we injected our settings service into the our oidc-provider service, there are some comments in the PR as to the whys and wherefores for this change (https://github.com/hashicorp/consul/pull/10503/files#diff-aa2ffda6d0a966ba631c079fa3a5f60a2a1bdc7eed5b3a98ee7b5b682f1cb4c3R28)

During development, this manifests itself as a javascript error:

Whereas during production, it simply breaks with no clear reason as to what the problem is.

Fixing the typo so it was no longer looking for an unknown service (repository/settings > settings)
fixed this part of the issue which was added as part of the above PR here

2: URL encoding (1.9.x, 1.10.x)

TL;DR: /oidc/authorize/provider/with/slashes/code/with/slashes/status/with/slashes should be /oidc/authorize/provider%2Fwith%2Fslashes/code%2Fwith%2Fslashes/status%2Fwith%2Fslashes

When we receive our authorization response back from the OIDC 3rd party, we POST the code and status data from that response back to consul via acallback as part of the OIDC flow. From what I remember back when this feature was originally added, the method is a POST request to avoid folks putting secret-like things into API requests/URLs/query params that are more likely to be visible to the human eye, and POSTing is expected behaviour.

Additionally, in the UI we identify all external resources using unique resource identifiers. Our OIDC flow uses these resources and their identifiers to perform the OIDC flow using a declarative state machine. If any information in these identifiers uses non-URL-safe characters then these characters require URL encoding and we added a helper a while back to specifically help us to do this once we started using this for things that required URL encoding.

In the majority of the examples you see for OIDC auth flow use examples like:

https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

// and

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

...etc

In all the examples in the OIDC spec it 'seems' like code should be alpha-numeric, but if you dig a little deeper code is specified as:

 code       = 1*VSCHAR

which therefore means it can contain non-URL-safe characters 💥

The final fix here make sure that we URL encode code and status before using them with one of our unique resource identifiers, just like we do with the majority of other places where we use these identifiers.

Both fixes here are required for the 1.10.x branch (the typo was added in 1.10.1), our 1.9.x branch doesn't require the first fix for the typo and requires a slightly different way of writing the second fix. Therefore I'll be backporting it here only for changelog reasons, but then manually fixing the backport when it fails.

[kaxcode]

LGTM - lmk how you want to do the changelogs.

[hc-github-team-consul-core]

🍒 If backport labels were added before merging, cherry-picking will start automatically.

To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/432487.

[hc-github-team-consul-core]

🍒✅ Cherry pick of commit 05a28c3 onto release/1.10.x succeeded!

[hc-github-team-consul-core]

🍒❌ Cherry pick of commit 05a28c3 onto release/1.9.x failed! Build Log