Make token duration configurable

[dborovcanin]

FEATURE REQUEST

2. Describe the feature you are requesting, as well as the possible use case(s) for it.
   Make duration configurable for different types of API keys. Currently, login and recovery key durations are hardcoded constants.

3. Indicate the importance of this feature to you (must-have, should-have, nice-to-have).
   This is a should-have feature.

Can we use this as default values and provide env variables? IMHO 5min is to short for recovery token, I would set at least 15+ min

Originally posted by @nmarcetic in https://github.com/mainflux/mainflux/pull/1007

[lcbm]

+1 on this issue 🎊

I'm part of a Open-source IoT meta platform project and we are building an orchestrator service on top of Mainflux. For reasons mentioned in issue #778, we've attempted using API Keys (issue #932), but after talking with @drasko and @dusanb94, through Gitter, we realized that (at least for now) we actually rely on the user token for provisioning and that the solution would be to make its TTL configurable 😬

Our motive is that we need our orchestrator service to be able to make operations that require the user token, at any moment (listing devices, updating things' values, etc). Considering the user token expires every 10h (and it's not configurable), it's quite hard to achieve our goal safely (and without workarounds) 😥

Let us know if there is any way we can work to collaboratively address this issue 🎊

[drasko]

@lcbm best would be that @dusanb94 and/or @nmarcetic leave you the instructions here or on Gitter, and you try to implement this and send PR. It should not be so difficult.

[dborovcanin]

This is possible using API keys for this purpose. There are 2 types of keys issued for the user: user key and API key. User key you get on login and it lasts default 10h. An API key is similar to the user key (it's also a JWT), but you can specify duration for it or, if you leave duration empty, the API key will last indefinitely. Unlike user keys, API keys can be revoked, thus indefinitely duration is not the problem.

[nmarcetic]

Just to add ^ Currently with API keys you can do provisioning ( device, channels CRUD) but not messaging (you can't send messages as device or user). We will add messaging in future

[lcbm]

@drasko awesome! We'd be more than glad to do it 😄

@dusanb94 @nmarcetic thanks for taking some time to help us! Just to try to make our point clearer, tho: we did try using API Keys and from what was discussed on Gitter, we concluded that we must, for now, rely on User Key (or User Access Token). We were able to create an API Key but it seems to not be associated with a user (we also had some weird behavior)... 👇

What we were able to do, following authn's swagger.yaml specifications:
Create an API Key
$ curl -k -X POST -H "Content-Type: application/json" -H "Authorization: $TOKEN" https://authn/keys -d '{"id":"<uuid>","type":2,"issuer":"knot@knot.com","secret":"$TOKEN","issued_at":"<yyyy-mm-dd hh:mm:ss>","expires_at":"<yyyy-mm-dd hh:mm:ss>"}'

We tried with a variety of values in each of these parameters, as well as with type alone (which is specified as the only required one). Also, we were able to create a API Key event when type was not specified.

Get an API Key
$ curl -k -i -H "Content-Type: application/json" -H "Authorization: $TOKEN" https://authn/keys -d '{"id":"$API_KEY"}'

This request actually issued a key to us (it seems) -- returning a different API Key value everytime. When tried using no Authorization Header and sending the user token inside id... this yielded us a single API Key value, everytime but the 'issue at' field was the same as the moment of request.

What we were unable to do, following authn's swagger.yaml specifications:
Create Things w API Key
$ curl -k -X POST -H "Content-Type: application/json" -H "Authorization: $API_KEY_ID | API_KEY_VALUE" https://things/things -d '{"name":"leleco"}'

Get Things w API Key
$ curl -k -H "Content-Type: application/json" -H "Authorization: $API_KEY_ID | API_KEY_VALUE https://things/things

From both of the above, we got three different errors from the users log service: use of expired key (using api key id), unauthorized (api key id), entity not found (api key value). The things service yielded us 'missing or invalid credentials provided'

If you have any further guidance, instructions, or anything that could help us use API Keys properly, that would be awesome. We'll be glad to help in any other way, to open issues or anything necessary to give further details. From our experience and previous discussions, we were only abe to use User Keys 😢

note: about the messaging part, we don't use Mainflux's messaging system -- we use our own.

[nmarcetic]

We have this covered by unit tests and everything works as expected ^ This must be some problem in usage (wrong documentation or similar). @dusanb94 Can you pls take a look at this ^

[mteodor]

We should also add some token refresh mechanism

[rodneyosodo]

Working on this