-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify OAuth schemes - consider requiring Bearer tokens only #347
Comments
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: Use case: |
@benfrancis wrote:
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:
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
If we assume that Consumers are generally less constrained than Things, one option might be to make the 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 |
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.
The text was updated successfully, but these errors were encountered: