Consider supporting form-based authentication schemes

[mmccool]

In many web sites authentication information is gathered using a form and delivered by a POST rather than using the basic and digest methods built into HTTP. Despite being questionable from a security point of view this is widely used in practice. See https://en.m.wikipedia.org/wiki/HTTP%2BHTML_form-based_authentication

An actual implementation using this in practice would likely use a secondary form of authentication, such as a session key or token stored in a cookie. A Thing using this authentication mechanism would therefore return the “login page” if no session is available and the content otherwise.

Questions: (a) is this important for IoT devices (b) do we need an additional security scheme, or can the existing security metadata proposals be used to model it correctly? Note: in an ordinary web site all URLs may return the login page if an unauthenticated access attempt is made. In modelling a Thing we can use a specific login URL and all others can return an “unauthorized” response code and/or ignore unauthorized requests.

[mkovatsc]

I am aware of some devices that have a similar login step for machines to get authorized. Usually there is not really a form, or rather the form information would be in the TD security section, so that a device can submit the corresponding login request.

The problem is that it is basically a protocol similar to an OAuth flow to dynamically get a kind of API key. Maybe this is something that behaves like the Proxy scheme as it needs to be combined with Cookie or ApiKey scheme.

@wiresio We should revisit the login flow of that device you had.

[mmccool]

Probably need URI templates for this to work in general. Then we probably need to add a "form" security 'scheme that takes an "authorizationUrl" that is a URI template. Adding URI templates to "forms" is useful but will not directly address the security issue... UNLESS "schemes" can refer to actions that have forms with URI templates. There could be an "authorizationAction" that refers to an action by name:

{
    "scheme": "form",
    "authorizationAction": "login"
}
....
"actions": {
     ...
     "login": {
          "forms": [...]
     }
}

to really make this work, though, would have to mark certain parameters as being username, etc: so would need some semantic markup and a "Login Capability". But this then requires semantics to work.

[mmccool]

@mkovatsc , the way I see it, there are two kinds of "security schemes": those where you provide a credential to get access, and those where you exchange one credential for another one (typically part of an overall authentication/authorization flow). Basic and digest authentication are an example of the first. Typically you have to provide the information on every access, but the browser caches them for you so you don't have to provide them every time. However, alternatively, the system could provide you with a token on your first login, which the client stores (eg in a cookie) and has to present it for other accesses. In practice, since the browser doesn't "know" that it is doing authentication when using a form to submit credentials, the second approach has to be used. So in order to use the proposed "form" scheme, you would have to have some other scheme that uses stored credentials (eg apikey + in cookie). Probably the "form" scheme should also indicate what kind of credential will be returned and where it should be stored.

The OAuth scheme is an exception to this since its "flows" basically identify a whole set of schemes to be used together. But not everything uses OAuth (although technically, we could use "custom" OAuth flows, although I need to look into that more).

There are several reasons to do multistep authentication flows: privacy, decoupling of software systems, division of roles, etc. Basically it's indirection.

[mmccool]

PS regarding "requiring semantics to work", one way to avoid that is to use parameters with fixed names that the system "knows" mean certain things. But then you run into the problem of what to do it those names don't match what is needed in the query parameter (eg if the "special name" in the TD is "password" but the API needs the query parameter "pw"... I have to look to see if there are URI templates that let you separately specify the name and the value, as I mentioned in the meeting. This was one of the use cases I was thinking about...)

[mmccool]

URI templates are coming, schemes already can use "in" to specify parameters are in the query parameters, so.... this should just "work". We may have to add some extra parameters to say what the parameters are named, though... to be determined.

[mmccool]

Will close this, since once we have URI templates we can use "in = query" to represent authentication information in query parameters, like a form would do, for various schemes. But we should definitely use this as a test case for combining URI templates with security.