How can I set variable for 1Password CLI session expiration?

scottrbaxter

I really appreciate the time taken to make the 1Password cli tool. It's been hugely helpful! One thing that I feel would be a really helpful addition, would be to have a way to check the expiration time. If the cli tool reported the expiration time (currently that would be (GNU: date -d '+30 min' or Mac: date -v+30M) upon successful signin, users could check current time against that variable to confirm the session is still active. I do a similar thing with the awscli, when using the aws iam assume-role... one of the returned values is an Expiration time (in UTC).

I have a working function i call with a bash script, but it's a bit excessive just to determine if auth was successful:

e.g. (snipit from a script):

OP_EXPIRATION_TIME=$(date -v +30M -u +%s)
try_session(){
    op signin "$OP_CLOUD_ACCOUNT" | grep export | awk -F\" '{print $2}'
    export OP_SESSION_[account_name]="$result" && \
    export OP_EXPIRATION="$OP_EXPIRATION_TIME"
}

result=$(try_session)

[ -n "$result" ] && \
    export OP_SESSION_[account_name]="$result" && \
    export OP_EXPIRATION="$OP_EXPIRATION_TIME"

This will export the current UTC time + 30 minutes, as an epoch value, so I can easily count the number of seconds against it. I execute this with source /path/to/start_op_script

If the output would provide a nice data structure (e.g. json), I could use that to wrap a script around the op signin ... command, and export a variable, like I do with the aws sts assume-role.

Thoughts?

---

1Password Version: 6.8.8
Extension Version: Not Provided
OS Version: MacOS 10.12.6
Sync Type: 1password.com
Referrer: forum-search:cli expiration

rickfillion

Hi @scottrbaxter,

I'm glad that you've found the command line tool helpful. :)

It'd be nice for us to do something better there. In an older thread (https://discussions.agilebits.com/discussion/87105/best-way-to-check-if-session-is-valid) I proposed a way to check if your session is valid using what's currently available. The session's availability isn't only based on time as the server is allowed to kill the session whenever it wants (in reality this is effectively never, but we've had a couple times where we needed to invalidate all sessions).

I hope that's helpful.

Rick

scottrbaxter

Actually, that's sort of less helpful (sorry :p). Perhaps your team should update the full documentation page to be more clear about the 30 minute inactive timeout?

Sessions automatically expire after 30 minutes of inactivity.

Here's a basic example that I already started using... I'd like to update my prompt with whether or not the session key is valid and how many minutes are left. If it's got a hard timeout period of 30 minutes (as stated in your docs), I can easily build a solution around that... and know that anything i have to kick off involving access to a vault entry is valid for that amount of time. Checking for an active session with a get account call (as you recommended), where not that slow, is just not an option. I'm sure you can understand that I have no interest in making a call to the 1password cli api each time i hit enter in a terminal.

Knowing that the amount of time a session is active can change by an unknown set of variables is fairly problematic for programmatic use... it means i can't rely on long running processes that could otherwise make use of the temporary session creds. I'd imagine things like changing networks (e.g. hopping on a VPN) would also kill the session... I believe that happened during a test today. It would be seriously helpful if your docs would better explain the scenario's around it permitting and restricting temporary session keys.

I did stumble upon this earlier today. Knowing that simply making a call to the api while signed in actually extends the current session another 30 minutes feels like a security concern more than a feature. I can easily create a loop to keep the session active, which I actually was testing a couple hours ago, since 30 minutes didn't seem to actually expire my creds.

tbh, I think you guys are trying to be too clever about this, and should just stick with defining an explicit timeout period. If some users want it to be longer than others, let them enable that per user... but don't make them guess or worry that their creds are still active long after your "after 30 minutes of inactivity". AWS just recently provided a similar solution to their IAM role cli access - I'd love to see the timeout go in this direction. Please reconsider how timeouts are being handled?

AGAlumB

Actually, that's sort of less helpful (sorry :p). Perhaps your team should update the full documentation page to be more clear about the 30 minute inactive timeout?

Sessions automatically expire after 30 minutes of inactivity.

@scottrbaxter: I'm not sure I understand. Didn't you copy that text from the documentation?

I'm sure you can understand that I have no interest in making a call to the 1password cli api each time i hit enter in a terminal.

I hear you. However...

I did stumble upon this earlier today. Knowing that simply making a call to the api while signed in actually extends the current session another 30 minutes feels like a security concern more than a feature. I can easily create a loop to keep the session active, which I actually was testing a couple hours ago, since 30 minutes didn't seem to actually expire my creds.

I guess I don't see how this is different than how 1Password works anywhere else: when you're actively using it, it doesn't "lock". I think that's reasonable, and, frankly, what most people expect. And, ultimately, it seems like the solution for both of your concerns — signing out and not signing out — is, at least for now, one in the same:

To manually sign out:
op signout

You can do this at any time to end the session if you don't want to worry about it continuing without you thinking about it, but also you can automate signing out and then back in with your scripts to ensure that you have a "fresh" session for whatever you're doing. Does that help at all?

Backtracking a bit...

Knowing that the amount of time a session is active can change by an unknown set of variables is fairly problematic for programmatic use... it means i can't rely on long running processes that could otherwise make use of the temporary session creds. I'd imagine things like changing networks (e.g. hopping on a VPN) would also kill the session... I believe that happened during a test today. It would be seriously helpful if your docs would better explain the scenario's around it permitting and restricting temporary session keys.

I'm not sure we can reasonably document all of the different interactions people might have with their workflows and setups with the 1Password CLI app, but perhaps there are some common ones which make sense, especially as we move closer to a 1.0 release. Thank you!

tbh, I think you guys are trying to be too clever about this, and should just stick with defining an explicit timeout period. If some users want it to be longer than others, let them enable that per user... but don't make them guess or worry that their creds are still active long after your "after 30 minutes of inactivity". AWS just recently provided a similar solution to their IAM role cli access - I'd love to see the timeout go in this direction. Please reconsider how timeouts are being handled?

I personally don't agree that's a good solution for the reasons I mentioned above, but I don't live in a bubble and we'll continue to listen to feedback from customers and also discuss it internally. I think AWS is a very different use case, but it's a good example and something we need to consider if others have similar expectations based on that. Thanks for the feedback on this! :)

rickfillion

tbh, I think you guys are trying to be too clever about this, and should just stick with defining an explicit timeout period.

Sessions are controlled by the server and not the client. That's just a reality and it's not useful to pretend otherwise. There's only 1 way to know for sure if your session is still alive: try to use it. That's how we recommend people treat it. If someone wants to build something that gives them a guestimate about whether the session is still alive, that's fine, but it's not something I plan on incorporating into our tool.

I believe that the solution to the problem that you're trying to accomplish isn't related to session expiration. Look at 1Password for Mac for example. There's an "unlock" mechanism which you do once in the morning and don't need to do for the rest of the day if you keep using your Mac. This is completely separate from sessions with the server. 1Password for Mac actually doesn't do anything to keep the session alive and it'll expire quite a few times during the day. This makes it a good citizen with the server because the server doesn't need to keep additional information in a fast cache for a client that wants to idle. But whenever the Mac app gets a push notification or it wants to do something with the server it'll try doing it, see that its session has expired, negotiate a new session, and then accomplish its task. This was all invisible to the user.

It would actually be technically possible for us to provide the same experience to users of the command line tool. We've actually built this same functionality into our SCIM bridge which is based on the same codebase as the command line tool. It's really nice. We just need to figure out the best way to translate that over to the command line tool from a usability and security perspective.

Rick

scottrbaxter

Thanks brenty and rickfillion, that does help. the point about being able to op signout of the session is not something i'd considered, so that's certainly valid regarding my session/security concerns. also, i've thought about it a bit, and i realized that one other thing I can do... write a test in my start_op script to see if the session is active (since i'm exporting the session key) and call it to both check and if not valid, perform the signin once again. should suffice for my needs at this point. good work folks! tbh, i didn't know this tool was still in beta - i hope you guys get lots of feedback and keep going with development... it definitely feels pretty mature already.

side note, i think the only bug i've come across is being able to op get totp object when i have multiple totp entries in a list. perhaps there's a way to work that out which i've not yet seen, but i believe it'll require individual items to get each totp value.

rickfillion

tbh, i didn't know this tool was still in beta - i hope you guys get lots of feedback and keep going with development... it definitely feels pretty mature already.

Thank you, @scottrbaxter. It means a lot to hear that. The functionality that exists should be stable (though we broke op add in 0.4 and fixed it again in 0.4.1)... but the part that we consider less stable is the exact command structures. Both in terms of how the command is invoked (param list and flags), and how those are returned to you as a user. That stuff has changed a lot in the early releases and we're refining things as we go, as we see what works and what doesn't. We're slowly starting to get our patterns down. @khad has been instrumental in helping us there. I like calling him the designer of the tool cause he approaches each of those just like a visual designer would approach a GUI app.

side note, i think the only bug i've come across is being able to op get totp object when i have multiple totp entries in a list. perhaps there's a way to work that out which i've not yet seen, but i believe it'll require individual items to get each totp value.

You're right, currently it would require individual items for each field. I'd love to hear about why you've got more than one TOTP field in an item to understand the scenario more. It's not something we considered.

Rick

scottrbaxter

Not going to get into too many details about it, but this day in age it's pretty easy to have/require a ton of totp keys. Never can be too secure ;)

That said, here's a hypothetical:
I use AWS a lot, and IAM access... a lot. In this example, I have an IAM user and various roles that delegate me specific access to various resources in various regions, and also across various accounts (hence me linking the STS assume-role above). So, say i'm signed in to my IAM user in the web console, using 1password mini (or the browser extension). I pull up the aws login page, hit my 1P hotkey and i can enter creds for my user. That works great... totp copies, excellent! so I make this a 1Password favorite, (which has a name starting with a number so it's at the top of my fav list [feature request: better way to sort favs]). Now... say I'm in a terminal, and need to assume a new aws role. That api call requires a totp key, so i hit my 1Password mini hotkey, and choose my top fav (as the rest are hidden behind a Show # more items option :rage:, cause it's faster to simply hit right right down enter to open favorites, then my first fav, then go into the 2fa category, and i can then choose whichever user/totp i need. I can delegate the aws user via api call, so i just need a specific totp entry from the list. Since then, I stumbled upon the cli tool and started using op get totp item... which is fantastic! my only issue now is if i have multiple totp entries in this login item, so it only spits out the first totp key. Basically, what i need is to replace op get totp item with op get totp item_name section_name totp_name

(side note, i also had some funny business while migrating between vaults, it'd tell me the same entry was in 2 vaults, and would require me to use some really long string instead of the item name... which i had to trial/error to determine which 6 digit token was which... this was totally confusing, cause i listed the item in both vaults, and couldn't match up either string with any output. /shrug)

tbh, if your mini/favorites had a few more features, i bet i wouldn't need to worry about this... but hey, muscle memory :tongue: There are other reasons i could site, but i hope this helps.

rickfillion

Thanks for elaborating on that. We'll see what we can do to make that better.

Rick

scottrbaxter

For anyone interested, I've created a bash script that wraps around the op binary. It'll attempt to authenticate if no active session exists, and also stores a 30 minute countdown variable (in UTC epoch time) so you can test against it.

Works great for a visual (including minutes since last command) when active, in my zsh prompt, and updates each time a new op command (that hits the server) has been run. I made a shortcut alias for quick access, in my .zshrc (.bashrc):
alias 1p='source ~/scripts/op_session.sh'

AGAlumB

That's really cool! Thank you for sharing it! :chuffed: