Recommended OAuth2 flows

[mmccool]

Since "implicit" and "password" are deprecated in OAuth2, we should add a recommendation that only "code" and "client" should be used, and also "device" (assuming it gets added in TD1.1).

See w3c/wot-security#194

[mmccool]

Generally we need to better integrate OAuth2 into the rest of the document. Right now it just pops up in a subsection... a HUGE subsection which is longer than the rest of the document. Perhaps we can move some of the material to an appendix and focus in the main text just on the recommendations (use only "code" and "client", and "device").

[mmccool]

Let's do the following:

• Move the current OAuth2 review into an appendix
• Pull out the pseudo-RFC2119 recommendations into the main body and reword as necessary...

[mmccool]

See also #11, which is about fixing the conformance section. Both these issues should be resolved together.

[mmccool]

See PR to update OAuth2 examples in TD spec and my review:. After some thought, I think we should recommend use of the "client" flow for most usages, since it enables M2M interactions, needed for orchestration. Code and device both require user interaction. AFAIK even usage of an interaction directly from a browser can still use the client flow, so... (Edit: wrong. See below. Client cannot be used with browsers...)

I think we should:

1. Recommend use of "client" for most interactions, and require it when automation is to be supported.
2. One exception might be where user confirmation is required, e.g. for some safety-critical, drastic, and irreversible action (e.g. "self-destruct", or "factory reset") where user confirmation is required and automation is NOT to be supported. In this case "device" or "code" can be recommended, with "device" used when the device has limited I/O capabilities.
3. Only have a "client" example in the TD spec, have the TD spec reference the security best practices for discussion of the other flows.

I was originally thinking we could use "device" and "code" for onboarding but since they don't support delegation I'm not sure they are completely appropriate. Maybe as part of a bootstrapping process to establish other credentials? At any rate I'm not sure we want to recommend them for "normal" interactions.

[relu91]

I would support having client as the recommended flow, but we don't have to forget that it has its use-cases and therefore it may not be used everywhere. In particular, per RFC6749:

Client credentials are used as an authorization grant
typically when the client is acting on its own behalf (the client is
also the resource owner)

In our context, this translates to interactions between a set of web things that belongs to the same "product family" (for example a companion application for orchestrating devices of a particular brand). It may have other applications but this is the one that I wrote a while ago in the oAuth 2.0 use cases (now adapted in the new WoT security best practices).

On the other hand, I don't think client flow should be used on browsers. In such cases, you can't guarantee client confidentiality which means the client's secret can be stolen easily. Different OAuth specialized websites encourage to use of the code flow plus PKCE for such use-cases.

[mmccool]

• Use case for "code" and "device" is when a browser talks to an IoT device; might also be used for onboarding with a hub
• Use case for "client" is automation, such as orchestration rules in a hub
• TDs actually allow "OR" combinations, using "combo" and "oneOf"
• Recommendation should be based on the above usecases, and use of "combo" when either use case may be required; also, probably in most cases always want at least "client" otherwise the device can't be integrated into any automation
• Kinda complicated, so there probably should be an example; see discussion about OAuth examples, where we decided to just do one example, for client. We should stick to that for now. But maybe showing use of two OAuth2 flows should be considered a good example to justify combo. We could also just put the example in the best practices doc.

[mmccool]

@mmccool to create a PR for the above consensus, in the wot-security-best-practices document

[mmccool]

Review also w3c/wot-scripting-api#214