Allow the Implicit Flow or Ban It

[jaxoncreed]

Background:

The OAuth Implicit Grant (https://auth0.com/docs/flows/concepts/implicit) is vulnerable to Cross Side Scripting attacks, but is still an OAuth standard. The Authorization Code Grant with PKCE (https://auth0.com/docs/flows/concepts/auth-code-pkce) is used for the same use case as the Implicit Grant but is not vulnerable to XSS

Pros/Cons of removing it:

• Pros:
  • Ensures that no Solid compliant client or server uses this grant
• Cons:
  • Some app developers may be used to using this grant and dislike its removal in the Solid spec
  • Keeping the implicit grant would make Solid’s OAuth more in line with traditional OAuth

[elf-pavlik]

As discussed during last call, it seems to affect implementations of OPs and clients / apps. We probably want to avoid need for both OPs and clients / apps to implement both flows. Given preference for PKCE, preferably all OPs and clients / apps in ecosystem will implement PKCE. If some client / app would only implement implicit flow it will not work with OPs which only implement PKCE. For wording in WebID-OIDC spec we could go with something like:

Due to vulnerability to Cross Side Scripting attacks, Implicit Grant flow is NOT RECOMMENDED. OPs and clients MUST implement Authorization Code Grant with PKCE.

IMO we shouldn't talk about 'solid server' since it doesn't affect RSs.

[elf-pavlik]

I'll make PR proposing short 'panel finding' on that, I will probably also use https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-9.8 as informative reference.

[acoburn]

The Solid-OIDC specification requires the Authorization Code flow. It does not take a position on the implicit flow per se, as that is orthogonal to what this specification requires.