1password api to access passwords programatically
Comments
-
That's awesome! Thanks for sharing! :chuffed:
0 -
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.
0 -
I've been a 1Password customer for 5 years... and this is the main reason that I am now going to LastPass... SCIM API...
0 -
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
0 -
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
0 -
@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
opto access data using scripts. We'd love to hear your feedback on your specific use case. Cheers! :)0 -
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.
0 -
@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. :)
0 -
@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
0 -
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.
0 -
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
0 -
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.
0 -
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. :)
0 -
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
0 -
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
0 -
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.
0 -
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
0 -
Thanks.
0 -
You're welcome. :)
Ben
0 -
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!
0 -
@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.
0 -
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!
0 -
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
0 -
With the release of https://github.com/PowerShell/Modules/tree/master/Modules/Microsoft.PowerShell.SecretsManagement, having some API to 1Password is even more valuable.
0 -
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.
0 -
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 againIf 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 : NativeCommandErrorGiven 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
0
