2

I'm developing a CLI based application. It has a "login" command to perform authentication:

$ myapp login 
$ Type username: hector
$ Type password: *****
$ Login success!

Internally, myapp login makes a request against a HTTP API and a authentication token (JWT) is returned, so I need to keep it in the client somehow, in order to send it in subsequent requests.

Should I store this token in disk? Or maybe keeping it in memory and make the session 'volatile'? Is there any pattern or well-known practice for this?

2 Answers 2

1

I found an answer here: https://stackoverflow.com/questions/9146217/how-does-heroku-store-its-authentication-on-its-command-line-app

It has a Heroku's site link and explains very well how they face this. Basically, they store authentication token in ~/.netrc file.

3
  • 1
    Key word is token. The value in password should be a one-way hash, preferably salted, etc. Bottom line is that if two people have the same password it shouldn't look like it in the .netrc file. Hopefully the ruby gem the Heroku team created will handle that detail for you. If not, be aware. Jun 26, 2018 at 17:41
  • 3
    Storing contexts and sessions in hiden files and folders is quite common. In my recently experience with CLIs for cloud platform such as OpenShift, Azure and Bluemix I have realised that they, in essence, do the very same. Storing tokens in files is fairly common. One important thing to be aware of is the token expiracy. The use to be short-living tokens with no refresh tokens. Remember also the concurrency. Several processes reading-writing the same file might lead you to unexpected security issues.
    – Laiv
    Jun 27, 2018 at 21:41
  • 1
    And this is essentially the same as what happens when you log in to a website - the browser stores a cookie on disk, which acts as a token for access to your logged in session.
    – bdsl
    Aug 26, 2018 at 8:46
0

You should store the refresh token on the client if you have secure storage for it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.