Skip to content

persist auth state when used in a cli command #230

Description

@jordanorelli

Current Behavior

If you use op it can remain logged in for multiple command invocations, but if you write a CLI tool with the onepassword-sdk-python you have to re-authenticate every time. If your cli tool has a configuration file where you put onepassword reference strings into it, having the CLI tool subshell to op lets the user stay logged in for a few minutes and not have to re-auth every time they run your command, but with onepassword-sdk-python you have to re-auth on every command.

Desired Behavior

Some sort of auth persistence similar to how op works. My use-case is that every employee has a onepassword account and I want to use their individual onepassword accounts so that I can provision secrets in onepassword and use onepasswords user and group permission management structure, but employees should be able to run a cli command that uses these secrets if they have permission for those secrets.

Benefits & Value

If I subshell to op, then users stay logged in and they can run my command repeatedly, but the performance of looking up, say, 8 secrets is not as fast as using the sdk. If I use the sdk, resolving the secrets is faster, but the users have to re-auth every time. I'd like to combine the auth persistence of op with the lookup performance of the sdk.

Additional information

Compare this program:

import asyncio
import sys

from onepassword.client import Client, DesktopAuth


async def main() -> None:
    reference = sys.argv[1]
    client = await Client.authenticate(
        auth=DesktopAuth(account_name="whatever"),
        integration_name="op-read",
        integration_version="v1.0.0",
    )
    print(await client.secrets.resolve(reference))


if __name__ == "__main__":
    asyncio.run(main())

to the behavior of op read. If you do op read op://Private/etc/you-get-it twice in a row, you only have to auth once. If you do python op_read.py op://Private/etc/you-get-it twice in a row, you have to auth both times.

What I don't want to do is give people (ok, let's be honest, me) a reason to say "ok I'm going to speed this up" by exfiltrating the secrets into something like a redis docker container.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions