Reputation: 1550
Is there a consensus on how to send tokens as part of CoAP requests?
HTTP clients share their identity/credentials through the Authorization header (or eventually the Cookie header) or less often as part of the URL (e.g. a JSON Web Token encoded in base64url). In the CoAP RFC, there is not equivalent option to Authorization.
Draft profiles for authentication and authorization for constrained environments (e.g. OSCORE or DTLS) rely on the underlying security protocol to maintain a stateful connection and the token is uploaded to /authz-info
once:
C RS AS
| [-- Resource Request --->] | |
| | |
| [<---- AS Request ------] | |
| Creation Hints | |
| | |
| ----- POST /token ----------------------------> |
| | |
| <---------------------------- Access Token ----- |
| + Access Information |
| ---- POST /authz-info ---> | |
| (access_token, N1) | |
| | |
| <--- 2.01 Created (N2) --- | |
However, this is not suitable for unprotected environment (e.g. for development or in a private network). Since CoAP is typically on top of UDP, it is not possible to have "sessions" so we cannot track which client uploaded which token. I'd like to avoid to discuss about usefulness of token in unprotected context.
Should the token be part of the URI (i.e. as a Uri-Query
option or in the Uri-Path
)? ThingsBoard is an example of service having the the token as part of the Uri-Path
but I'm not sure if this is the best option. Also, would sending a binary CBOR Web Token in Uri-Query
be possible without base64url encoding?
Upvotes: 1
Views: 625
Reputation: 928
In CoAP, no attempt is made to provide user authentication without a security layer in place, nor are there provisions for sessions in the CoAP layer (which would violate the REST design).
As I understand, that was a conscious decision to guide implementers towards a RESTful design, and to avoid the transfer of security tokens over unsecured transports.
For the two use case of "during development", it is possible to introduce an own CoAP option in the experimental-use range, for example "65003 = Simulated-OSCORE-Key-ID" (where 65003 is chosen to be critical and not safe to forward). While the OSCORE stack is not operational, an ad-hoc made-up OSCORE key ID could be inserted there and then have a token POSTed using it in the ACE steps. Obviously, those constructs should neither make their way out of a test setup, and not into specifications.
Private networks are considered as untrusted ("NoSec mode") as the rest of the network in CoAP. That assumption can probably be understood better in the context of the principle of least authority, which makes setups where all devices (and processes) on a network share the same set of permissions highly unlikely.
Upvotes: 2