Implement secure OIDC integration while gradually deprecating and removing the implicit flow #1061
Open
2 tasks done
Labels
enhancement
New feature or request
help wanted
Extra attention is needed
p2
Non-critical bugs, and features that help organizations to identify and reduce risk
technical debt
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
The text was updated successfully, but these errors were encountered: