Requirements from oAuth 2.0 code flow

[relu91]

While I was working on eclipse-thingweb/node-wot#201 I found that the oAuth2.0 code flow might require some structural changes to Scripts and Scripting API.
In particular, the flow expects that the client should redirect the user using a user-agent to a login/consent page and later obtain the access token with redirection. Consequently, a binding implementation that supports this flow should stop the current script, redirect the user, wait for the answer, and resume. Those operations could happen every time a Property/Action/Event with that security schema is used.

This means that:

• A Script may be stopped/put in the background until the user consent giving the access to his resources. Therefore, it might be another use-case for the specification of script management.

• A developer might want to trigger the security initialization at will using API so that it can provide a linear UX (i.e. create a login button and do not prompt the user only when it uses some underline property/action/event)

Further, details can be found on the PR page liked above.

[egekorkan]

I have found this sequence diagram to facilitate the discussion: https://github.com/owncloud/oauth2/wiki/OAuth-code-Flow-Sequence-Diagram

@relu91 is this aligned with how you did the implementation?

[zolkis]

might require some structural changes to Scripts and Scripting API

Yes, that is the question.
AFAICT there is no need to change the API, since we use Promises for WoT interactions.
Before the promises are resolved, the UA may pop up dialogs, or more commonly, implementations can resolve multiple challenge/response cycles (IoT/headless devices should be provisioned for operation).

[relu91]

I have found this sequence diagram to facilitate the discussion: https://github.com/owncloud/oauth2/wiki/OAuth-code-Flow-Sequence-Diagram
@relu91 is this aligned with how you did the implementation?

Thank you Ege, I modified it a little bit using WoT actors. You can find the modified version here. A comment about the digram: powerful servients could also play the role of oAuthProviders and Identity providers, but I think that the best option for node-wot is to use existing services. Finally, I have not implemented code flow YET, just because I had those doubts presented in the issue body.

AFAICT there is no need to change the API, since we use Promises for WoT interactions.

My point is that in this particular case, developers might want to start the oAuth flow ahead of time. For example, a simple UI with a login button. I see two solutions to this use case both of the twos require some changes to spec:

1. Gives the ability to pass authorization token in the interactionOptions. In this case, the node-wot client would not implement the whole flow but it limits to pass the token. If no token is provided, the default behavior is to do the standard code flow.
2. Provide an API to initialize the security.

About point 1 (in case the token is passed) we also need a way to communicate the fact the token is expired. So this is another use case to have standardized node-wot errors. See #200

Before the promises are resolved, the UA may pop up dialogs, or more commonly, implementations can resolve multiple challenge/response cycles

I agree, in fact the other flows of auth implemented relays on the asynchrony of WoT interactions. However, in this case, I was afraid to stress too much the concept of asynchronous, since, as shown in the diagram above, the whole application goes out of focus (new tab in the browser) and the user could answer hours later.

(IoT/headless devices should be provisioned for operation).

Just a note; as I explained w3c/wot-security#165 and eclipse-thingweb/node-wot#201 I don't think the code flow is applicable for IoT/headless device clients.

p.s. if the invitation to the weekly calls is still open, I'd be happy to participate and talk about this topic. I have more time now and I committed to working more on WoT.

[zolkis]

Adding support for tokens in InteractionOptions is possible.
Human interaction can be managed by the app, but part of it can be managed by the UA.
In many web APIs, human interactions are done by the UA and not directly through the API (app).

Check out for instance how the Presentation API and Remote playback API manages user selections/choices by the UA. Of course, id's and tokens can be passed when needed, but if possible, should be done by the implementation, rather than trusting the application script to handle them.

So I'd prefer a separate way to set up security and expect the Scripting API work transparently wrt security flows. That would also work better with headless WoT servients.

[relu91]

From the last scripting and security api call:

• There was a consensus about not giving control over tokens to the application level.
• @mmccool asked to be tagged in an issue for discussing oAuth2.0 code flow. I guess this could be the right one, but maybe we could move to Re-introduce OAuth2 Security Scheme to TD wot-security#165
• We need to study what other groups are doing about this flow. Starting from Presentation API and Remote playback API mentioned above.
• @mmccool suggested solving this issue completely at the protocol level. In fact, in this diagram, Alice could be also a remote service that acts on behalf of the resource owner. This would allow using code flow also in device-to-device communication. I've never seen such implementation of the code flow, but if the remote service is trusted it might work.

I did my best to summarize what we discuss; if anything is missing or is not clear please feel free to comment.

[mmccool]

Thanks for bringing this up, we need to look at the OAuth2 spec in more detail to better understand the situations in which various flows may and may not be useful for IoT devices. I'll put this on the agenda for today's Security call.

[mmccool]

Comments from Security call May 25:

• I think we probably should go through each OAuth2 flow and try to write down a concrete use case suitable for IoT devices. If we cannot, then we probably should not support that flow.
• We should be careful not to re-interpret flows so they map onto other flows
• Removing flows that are already in the spec (eg the "code" flow) is probably not a good idea
• "User agent" may not be a browser, but a display + input device on the Thing; should understand when a "web dashboard" (Thing acting as a web server) is usable.
• We should think of which "role" the IoT device takes in the OAuth protocol (resource server vs. caller).
• We should look carefully at the OAuth2 spec, eg if it says that a human user MUST be consulted as part of the flow, that complicates things for IoT devices (although we might be able to document an "interpretation")
• Another issue is when credentials need to be provided, and how long they can be "cached", i.e. is this only upon first use, when provisioned, when onboarded, etc. However, provider of tokens may set them to expire... we could suggest best practices

[mmccool]

Let's capture some detailed use cases here: https://github.com/w3c/wot-architecture/blob/master/USE-CASES/oauth.md

[relu91]

I am commenting to bring this issue up again. Even if OAuth 2.0 is now officially supported by the TD (see w3c/wot-thing-description#927), the original issue is not solved yet. Now that we have defined some concrete use cases for the code flow I think we should discuss again how scripts could start the flow at will. I am referring to this point described above:

A developer might want to trigger the security initialization at will using API so that it can provide a linear UX (i.e. create a login button and do not prompt the user only when it uses some underline property/action/event)

I see this as a pretty common use case in WoT scripts. In general, this goes under the category "how to provision security dynamically from scripts". For example, another related use case would be:

Hypothesis

• TD with a basic security scheme
• Unknown user and password

Use case

Write a simple application that asks the user&password and accesses a TD property.

Currently, this cannot be done from a WoT Script. In node-wot, we work around this limitation by embedding the servient inside a normal application. I guess we could really improve the developer experience if we also take this use case into consideration.

Following the previous statement:

There was a consensus about not giving control over tokens to the application level.

I think that the only way to fulfill the requirements from that use-case is to design an API that demands the servient runtime to ask for user input. Anyhow, let's discuss this after the Note publication.