1password api to access passwords programatically

2

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni

    That's awesome! Thanks for sharing! :chuffed:

  • gerben
    gerben
    Community Member

    We are also very interested in a API for 1P Teams. At least to CRUD users. After that it would be create to also have access on passwords.

  • Thanks for the feedback, @gerben. :) We do hope to be able to do something like that in the future.

    Ben

  • granthbr
    granthbr
    Community Member

    I've been a 1Password customer for 5 years... and this is the main reason that I am now going to LastPass... SCIM API...

  • @granthbr,

    You may be interested in this announcement:

    AgileBits Blog | Announcing the 1Password command-line tool public beta

    It isn't exactly an API, but it may be helpful.

    Ben

  • rodrigorojas
    rodrigorojas
    Community Member
    edited December 2017

    Hi, we work as administrator of several web services that require a login and since it is quite frustrating log in and out every time to check some analitics, we are thinking to develop a dashboard that can take information from those account in a batch way, and for that we find useful to have the change to go through API. What should be the way to do this? Is there other method we an use to log in and out from several accounts from a same service and put them in a dashboard to compare data?

    Regards

  • AGAlumB
    AGAlumB
    1Password Alumni

    @rodrigorojas: Thanks for reaching out! Definitely check out the CLI beta. We're not going to build you a dashboard, but you may be able to use op to access data using scripts. We'd love to hear your feedback on your specific use case. Cheers! :)

  • dgc
    dgc
    Community Member

    I haven't really followed this thread since my last comment (2016). I'm glad you have a CLI, but API would still be better. Automating CLI tools is seriously not fun. APIs are vastly more stable.

    I think you're overassessing the difficulty. Yes there's basic authnz to be done, but I don't think that per-application scoping is a basic requirement. It's an awesome plus, but not necessary for a first release. Just mark stable, document, and release the API backing your CLI tool. That, plus REST-based administration of enterprise users and the ability to push passwords to users or folders, puts you ahead of the competition.

    We're (still) using LastPass because it offers the user administration. We've reverse-engineered enough of their crummy API to get done the other things we need. We use their CLI pretty heavily. Blanketing it in an API-to-shell wrapper is frustrating, unstable, and inflexible, but we do that too. If you could provide an API that does all that, without per-client release scopes, you'd have everything most people need.

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited April 2018

    @dgc: Well, even if we do an API, we'd need to add support for it to each of the apps. And in that regard, the CLI app could give all of us more bang for our buck, since that can run across many different platforms. And that could also be a stepping stone to an API. An API isn't necessarily more stable. It's all about the details. We've love to hear more about what your company is looking for though. Shoot us an email at business@1password.com if you'd like to explore this with us further. :)

  • @dgc : I'd love for us to provide documentation for our API endpoints, but just because something is technically possible doesn't necessarily mean it's a good idea to do. What I mean by that is that I don't think many people would want to code against our API. Any client that wants to talk to our server needs to implement SRP, it's not just a matter of getting an OAuth token and issuing a few HTTP requests. Once SRP is done then to do anything interesting you need a slew of encryption keys. It's a ton of work.

    The CLI tool is meant to be a wrapper around all of that work. I knows how to do all of the hard work, so that you don't need to.

    Rick

  • dgc
    dgc
    Community Member

    @brenty I don't know what you mean by "each of the apps", but I'll take your word for it.

    Sounds like you're happy with where you're at. I'll continue looking. Thanks for your time.

  • dgc
    dgc
    Community Member

    I guess I'll add:
    ... I don't know how to quote in your newsfroup, but where you say "And that could also be a stepping stone to an API. An API isn't necessarily more stable. It's all about the details." Well, that's strictly correct. If you had an API that used the CLI I would use it. But ultimately, to integrate with my own toolchain, I want an API endorsed and maintained by the company whose product I'm using. I don't want to write my own API to your CLI.

    That said, I've rarely used a command like tool so stable that I could depend on it like I depend on a versioned API. You'd have to do a really good job... or just write the API using your CLI tool.

  • Looks like I misunderstood you @dgc.

    If you had an API that used the CLI I would use it.

    I assumed you strictly meant an HTTP based API. That's what most people who request it want and I assumed that you were in the same boat.

    That said, I've rarely used a command like tool so stable that I could depend on it like I depend on a versioned API

    You're right. One of my goals is for us to open source our the Go package that our command-line tool uses, and this would make it possible to programmatically perform operations with a relatively stable API. I don't know when we'll get to that point though.

    Rick

  • dgc
    dgc
    Community Member

    Thanks, @rickfillion. I'm glad to see we were simply missing each other. I guess I'm old school. API doesn't really mean HTTP to me — that's more in the neighborhood of RPC in my mind. :)

    For pretty much any service I use, I want an interface I can program to. Most often those are implemented over HTTP these days, and I imagine your CLI program has a hidden HTTP interface behind it, too. But that's not important. What I care about is having a stable and consistent programmer's spec. As long as what's on the other side of it is something I don't have to maintain, and that I can count on, I'm good.

    Programmatic management is even more important when it comes to managing my N-hundred users as they come and go. That's #1 top critical for me, and is the main reason we're using LastPass. Beyond that we also store secrets (not passwords) on users' behalf, both in their own accounts and in special-purpose role accounts. We initiate this from internally-developed web applications and they receive the secrets across a variety of clients. And since we use our LP secret store for shared secrets, we also develop more straightforward client wrappers that retrieve secrets from it and call (or are called from) ssh, ansible, sudo, various ssh wrappers that use shared keys from lp, etc. It's pretty rich and not very single-user/single-password and it depends heavily on automatability. Whether that ultimately falls on RPC or CLI is not that big an issue. I just want the interface to be maintained by the service provider, not me.

  • dgc
    dgc
    Community Member

    Oh, and... absolutely agreed, there is a lot of work on the client side. I've done the PBKDF2 and the SHA and the HMAC and AES and the 5000 rounds, when reverse-engineering LastPass's API for the stuff I described above. I'm not exactly afraid of it, but I absolutely don't want that to be my obligation as a customer — thus the wish for a well-developed client interface library. :)

  • Great to see we're on the same page now, @dgc. Thanks for elaborating on what you're looking to replace. I hope that we can make this possible for you.

    Rick

  • lukash
    lukash
    Community Member

    So with 1Password7 my AppleScript (that I mentioned earlier) stopped working so I cooked up a 1Password command line bash script for the same purpose (ssh-add w/ passphrases from 1Password): https://github.com/lukaskuzmiak/SSHKeysVia1PasswordCloud

  • Thanks for the update @lukash!

    Ben

  • dgc
    dgc
    Community Member
    edited May 2019

    Can anyone point me to some words on the current status relating to... let's say remote user and password management?

    To summarize old posts: I use Lastpass, but it makes me sad. I use it because they have a limited-but-adequate API for enterprise user management, and a for password management they have a command line tool that I've wrapped with a programmatic interface so that I can glue other programs to it naturally instead of coding each one to know the command line tool syntax and behavior. It's a miserable life, so I'm waiting for and looking for someone to offer better than command line for people who need to integrate applications with the password store.

    I need a better solution than 4 or 5 different credential stores with bad command line clients that I script out of other software. I want... well, I want one password store. This comes up every few weeks or monthly for me. I'm trying to keep pestering you guys down to yearly. :)

    Oh, and to reiterate/preempt, anywhere I say "API" all I mean is an ability to call a stable, immutable, versioned interface. I don't necessarily mean HTTP, although that's fine.

  • Hi @dgc

    We've made a lot of progress on the CLI, but it is in beta at present. That is the closest we currently have to offer for what you're looking for.

    Ben

  • dgc
    dgc
    Community Member

    Thanks.

  • You're welcome. :)

    Ben

  • allenellis
    allenellis
    Community Member

    Hi,

    Just thought I'd add in another potential use-case. I was inspired by this discussion on Reddit and ended up here hoping 1Password supported this, sounds as though it does not.

    The use case is: you're configuring software that requires username & passwords to be stored in plaintext in a configuration file. What's a better approach that supports the password changing over time, or for the password to be quickly revoked?

    Use your password manager's API to pull the credentials during runtime. The secrets would not be sitting on the disk - only a (revocable) API key to the password manager.

    So, some kind of API (HTTPS REST) where your program can CURL an endpoint, providing a token representing the resource it wants to request, and a token representing its own app.

    From the UI in 1Password, I could find a login, click "share", and generate a URL that provides read-only access to that credential. Those tokens could be manually revoked at any time or set to automatically expire after a period of time. Bonus points if 1Password can report statistics on when/where the credential has been requested from.

    Just thinking out loud!

  • Lars
    Lars
    1Password Alumni

    @allenellis - thanks for adding your thoughts to this thread. If you have a 1password.com account, these are all things you can accomplish (if I read you correctly) with the 1Password Command Line Interface. If you have a membership, you might want to check that out. If you're still using 1Password in standalone mode, that won't be available to you, however. Hope that helps.

  • allenellis
    allenellis
    Community Member

    Cool, thanks! When I glossed over the 1Password CLI it didn't strike me as being easy to automate, but I'll take a closer look next time I'm looking into trying to do this. Thanks!

  • The CLI is probably easier to work with than an API would be, as the CLI handles the decryption of the data for you, whereas an API wouldn't be able to.

    Ben

  • cdhunt
    cdhunt
    Community Member

    With the release of https://github.com/PowerShell/Modules/tree/master/Modules/Microsoft.PowerShell.SecretsManagement, having some API to 1Password is even more valuable.

  • @cdhunt

    Could you please elaborate on what you're looking for in an API that the CLI is not currently able to provide for you?

    Ben

  • cdhunt
    cdhunt
    Community Member

    The CLI passes secrets in plain text through stdin/stdout. The above Powershell module would allow for secrets in memory to remain encrypted within the shell session and never go through stdin/stdout.

    It's also likely that this Powershell module, developed and published by Microsoft, will become the defacto standard for Windows Sys Admins interacting with secrets repositories, both 1st and 3rd party. Automation developers don't need to understand the individual implementations of the backing secret store and scripts can just use the common commands for saving and reading secrets.

    I don't use the CLI in automation because I found it difficult to not leak secrets onto the screen an into logs.

  • micmaher
    micmaher
    Community Member
    edited February 2020

    Hi Ben,

    I came here after looking for information on 1Password's roadmap for supporting PowerShell Secrets Management. The module is only in Alpha right now but there is an extension for KeePass already out there.

    We tried the 1Password CLI for account provisioning back in August 2019 and gave up on it. Please allow me to chime in on your question to cdhunt on where we found it limiting.

    My first problem was integrating it with our company user onboarding and termination. We have integrated 1Password with Duo. I can get the Duo MFA prompt at the command line but its not a workable solution for us. Our outsourced helpdesk will be doing user creation and deletion and running the CLI/script. Halting the script to prompt them for their master passwords and secret keys in what is meant to be an automated process would just be unworkable. Our onboarding and termination uses REST APIs for lots of different services. In my opinion CLI management is outdated. In fact we insist on REST API support for inclusion of any applications in our company's automated onboard/term procedure.

    In the end we had to take 1Password out of this automated process and take out an Azure subscription to get the SCIM bridge working. But even then I found the SCIM bridge set-up required a lot of effort, it needs a Kubernetes instance to run the 1Password VM.

    Another limitation I hit was in 1Password you must suspend a user before you can delete them.

    First I try delete . . .

    PS C:\>     Invoke-Command -Scriptblock {./op delete user $deleteEmail} | ConvertFrom-Json
    ./op : [LOG] 2019/08/26 16:33:47 (ERROR) User must be in suspended state to be deleted. Run `op suspend testuser@company.com` and try again 
    

    If I login to the 1Password portal and manually suspend a user I can then delete with the CLI call afterwards.

    However, if I use the CLI to try to suspend a user it fails.

    As you can see the user is still there and active . . .

    PS C:\> Invoke-Command -Scriptblock {./op get user $deleteEmail} | ConvertFrom-Json
    
    
    uuid             : L*****
    createdAt        : 2019-08-16T10:56:13Z
    updatedAt        : 2019-08-16T11:00:12Z
    lastAuthAt       : 2019-08-16T10:56:27Z
    email            : testuser@company.com
    firstName        : Test
    lastName         : User
    attrVersion      : 3
    keysetVersion    : 2
    state            : A
    type             : R
    avatar           : 
    language         : en
    accountKeyFormat : 
    accountKeyUuid   : 
    pubKey           : @{alg=; ext=False; e=; n=; key_ops=; kty=; kid=}
    

    So I try to suspend first but the user is not found

    PS C:\>     Invoke-Command -Scriptblock {./op suspend user $deleteEmail} | ConvertFrom-Json
    ./op : [LOG] 2019/08/26 16:25:53 (ERROR) User user not found.
    At line:1 char:34
    + ...   Invoke-Command -Scriptblock {./op suspend user $deleteEmail} | Conv ...
    +                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: ([LOG] 2019/08/2...user not found.:String) [], RemoteException
        + FullyQualifiedErrorId : NativeCommandError
    

    Given this was last August this may have been fixed by now but I wanted to add my voice for a RESTful service and support for Secrets Management.

    Thanks,

    Michael

This discussion has been closed.