Add support for automatically refreshing the auth-token before expiration

[Kami]

We should provide a "high level" client class to which the user passes API information (URL, etc.) and credentials. This client should automatically handle authenticating and refreshing the token before it expires.

This is important and needed for long living processes which use the client (e.g. StackStorm hubot adapter).

In addition to that, we should still provide "low level" client and authenticate method in case user just wants to authenticate and retrieve an auth token.

We currently do that in the CLI, but in the future when we are refactoring the Python client, we will implement this there as well.

[Kami]

@enykeev Any ideas when you will have time to work on this?

We need the same thing in hubot plugin and I don't want to reinvent the wheel - the plugin should utilize st2client.js anyway.

[enykeev]

I'm keeping this task on deck since you've filed it initially and reviewing it like once a week =)

Frankly, I don't feel comfortable knowing someone can prolong the auth token indefinitely after intercepting it once.

Should not we use API keys for integrations instead?

[Kami]

Well, that's similar to how tokens work in a lot of places (you can use them to retrieve a new token, or in some cases such as Google / oAuth you use refresh token (long lived) to retrieve a new access token (short lived) - refresh token is similar to username + password combo in our case).

As far as API keys goes - yes, ideally in the long term, but API keys are far from feature complete yet (needs docs, need CLI commands, needs to be hooked up in the UI, needs to be correctly hooked up with RBAC, etc.).

[st2stanley]

As a very imperfect monkey-patch you can just reset Hubot with a StackStorm timer rule. That's what I ended up doing.

On Mon, Oct 12, 2015 at 9:48 PM, Tomaz Muraus [email protected]
wrote:

Well, that's similar to how tokens work in a lot of places (you can use them to retrieve a new token, or in some cases such as Google / oAuth you use refresh token (long lived) to retrieve a new access token (short lived) - refresh token is similar to username + password combo in our case).

As far as API keys goes - yes, ideally in the long term, but API keys are far from feature complete yet (needs docs, need CLI commands, needs to be hooked up in the UI, needs to be correctly hooked up with RBAC, etc.).

Reply to this email directly or view it on GitHub:
#25 (comment)

[Kami]

Yes, I documented this as a workaround in the hubot-stackstorm repo.

As far as AIO deployment goes - if we don't do this yet we should also do it there. Or even better, we should update hubot-stackstorm so it exists / crashes on 401 exception and process manager should restart it.

[enykeev]

or in some cases such as Google / oAuth you use refresh token (long lived) to retrieve a new access token (short lived) - refresh token is similar to username + password combo in our case

Yeah, but in our case auth token is short lived and auth key is long lived, but you can just use the key directly instead of retrieving a token with it. Still doesn't feel right to me to prolong short lived token with another short lived token even if you're saying someone's actually doing it.

So, if token refresh is temporary solution, I would rather prefer not to make workaround a part of client lib, especially since it is conceptually questionable approach and would be replaced with API keys in a near future anyway. The whole process of adding new features in the client is hard due to semver and publishing. Stripping the feature away after a month would be even harder.

On my part, I have a few space cycles so I can take a look how we can speed up transition to API keys...

[Kami]

Alright, I will talk with @manasdk and others and make sure we are all on the same page and also that we document and make it clear to the users the difference between authentication tokens and API keys (where to use which one, etc.), etc.

Still doesn't feel right to me to prolong short lived token with another short lived token even if you're saying someone's actually doing it.

The idea behind this is that refresh token (or credentials which you use to obtain the short lived token) don't live on the same server as the short lived token meaning that if someone breaches the server where the short lived token is used or intercepts the connection, the token will only be valid for a limited time period and this limits the exposure.

So in short - if implemented correctly it tends to be better and more secure than pure long lived API key approach (that's also why more APIs today are switching to this approach compared to the plain API keys / secrets which used to be popular in the past).

Because of that I also think tokens still have a place in StackStorm.