Clarify OAuth schemes - consider requiring Bearer tokens only

[mlagally]

There are significant implementation efforts required to address the code and client flows for OAuth. Bearer Tokens are the underlying mechanism - consider lowering the bar on that authentication requirement.

[benfrancis]

Where would a Consumer get a Bearer token from if not via OAuth?

That would assume that a Consumer already has prior knowledge of a Thing, which is unlikely in a plug-and-play interoperability situation.

Also, what happens if and when the token expires?

I'm not necessarily opposed to the idea that Consumers would only have to support Bearer tokens but Things could fully implement OAuth2 if they wanted to, I'm just wondering how that would work when discovering a new Thing.

Use case: A Consumer is provided with the URL of a new Thing Description (via some introduction mechanism). The affordances of the Thing in the Thing Description (or the Thing Description itself) requires a Bearer token for authentication. How does the Consumer acquire a token?

Use case: A Consumer has been successfully communicating with a Thing using a Bearer token, but then the token expires. How does it get a new one?

[benfrancis]

@benfrancis wrote:

How does the Consumer acquire a token?

I've recently been implementing this on the Consumer side and was able to solve this part by simply prompting the user for a token in the user interface.

That doesn't answer the second part of what to do if and when the token expires. If there is a user interface then you could just prompt the user for a new token the next time they access the user interface (though the Thing would be inaccessible until they did, which would prevent any automations from working).

My understanding is that best practice with token based authentication is to make tokens expire very quickly (e.g. every 10 minutes) and require clients to request a new token via refresh token on regular intervals. In that situation it would be impractical to prompt the user every time.

@mlagally wrote:

There are significant implementation efforts required to address the code and client flows for OAuth.

Putting the above issue aside for a moment (since not all Bearer tokens will expire quickly, or at all), I do agree with this. If the only options are the BasicSecurityScheme (which isn't particularly secure) and the OAuth2SecurityScheme (which has a significant implementation burden) then it may limit adoption of the profile, particularly on the Producer side where Things are likely to have more constraints.

Bearer Tokens are the underlying mechanism - consider lowering the bar on that authentication requirement.

If we assume that Consumers are generally less constrained than Things, one option might be to make the BearerSecurityScheme mandatory for Consumers as well, so that Things have middle ground option between BasicSecurityScheme and OAuth2SecurityScheme (but only have to implement one of them).

Alternatively, if that's too much of an implementation burden for Consumers and if the Bearer scheme really is a subset of the OAuth2 scheme, could it be possible to only make the BearerSecurityScheme scheme mandatory for Consumers, but suggest they treat the OAuth2SecurityScheme scheme as the Bearer scheme if they don't support the whole of OAuth2? That would be messier, but could potentially guarantee at least a baseline of interoperability. I don't know how well it would work in practice.