Implement secure OIDC integration while gradually deprecating and removing the implicit flow

[VinodAnandan]

Current Behavior

We are currently offering the Implicit grant/flow, which is considered insecure and has even been omitted from OAuth 2.1 (https://oauth.net/2.1/).

Proposed Behavior

The Implicit flow was a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step.

It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.

Public clients such as native apps and JavaScript apps should now use the authorization code flow with the PKCE extension or DPoP instead.

I think we should provide support for both the authorization code flow with the PKCE extension and DPoP as additional methods while still supporting implicit flow as a deprecated integration. We can then communicate with DT users to migrate to secure OIDC integration options. If someone is using Google, we could recommend alternative solutions like Keycloak as an IdP broker and intgreate with upstream Google via Keycloak. I will also reach out to Google to see if they can provide secure integrations.

Related links:
#215
https://github.com/authts/oidc-client-ts/blob/main/docs/migration.md
https://github.com/AxaFrance/oidc-client
https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/dpop
https://keycloak.discourse.group/t/securing-the-tokens-with-demonstration-of-proof-of-possession-at-the-application-layer-dpop/3174

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested