Agilebits <> Developers

hugom

Hello,

We open a thread here for discuss with you about how we can integrate smoothly 1password in desktop applications.

Before the last release, we had some apps like sudolikeaboss, hyperterm-1password ... were are using 1Password via websocket and that can't work now.

At Station, we are building a revamped browser as smart workstation who embed our user's webviews. We are currently working on removing the authentication's pain process with a better experience using password managers.

We see 3 ways to work 1Password:

• The chrome extension using the native messaging API (POC here => https://github.com/hugomano/native-messaging-client)
• The internal API used for 1Password Web client (seen via network traces)
• 1Password CLI

The first way, with the native messaging API, is not available for everyone, only for apps who are whitelisted via code signing in the distributed client. What are you thoughts about opening submitted apps for approval à la App Store. Some apps have like Brave and Vivaldi have asked you to allow them and you do it. What are the prerequisites ?

The internal API used in the web client is not documented. Do you have a plan for open it ?

The last method, through the command line client, is the only one to work in our case. We execute the binary in a subprocess and we retrieve values from it. From the user perspective, we are the ones who manage the informations between 1Password and our fields to fill in.

What do you think about the subject? What are your plan for the subject?

Cheers!
Your friends at Station

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

rickfillion

Hi @hugom,

I love that you're wanting to do this. :) You've done your homework, and the list you provide does seem pretty comprehensive.

The first way, with the native messaging API, is not available for everyone, only for apps who are whitelisted via code signing in the distributed client. What are you thoughts about opening submitted apps for approval à la App Store.

This is something we've discussed internally and so far it seems unlikely that we'd open it up that way. I think a better approach would be to pair down our list of accepted code signatures, and instead let the user whitelist specific others they'd like to authorize. I don't know if that's planned, but being the central authority for all of those signatures has caused us some pain. Once a signature is added to the list, it's difficult to remove it as it may mean removing functionality for some users. It requires that we put trust in other organizations and their ability to protect their certificates.

On the Mac there are other concerns like how we'd make this work with sandboxed apps distributed via the Mac App Store? It'd require that they have temporary entitlements granted to them in order to get access to the native messaging host.

The internal API used in the web client is not documented. Do you have a plan for open it ?

We'd like to open up our documentation for it, but not for this purpose. We believe it's important to be open about how things work, and making this documentation available would help with it. But we think that even if we made the documentation available, it'd be very difficult for any other app to make use of it. While the API is mostly REST-ful, what's passed around are mostly just blobs, and requires a ton of client-side encryption. Getting all of the details right is quite laborious.

Instead what we'd like to do is to make using the APIs easy for developers with tools like the CLI.

The last method, through the command line client, is the only one to work in our case.

I assume that to make this happen you're asking the user to give you their Master Password. If so, I'd say that I cannot support this approach. I can't see us recommending to a user that they put their Master Password into any app that isn't 1Password.

I'm sympathetic to what you're trying to accomplish here though, and I've been trying to think of an alternative. What I'm about to describe is only an idea, but I'd love to hear your thoughts on it.

What if instead of asking the user for their Master Password, your app asked the user to allow it access to 1Password. You would invoke some kind of command on op that would cause a prompt to come up for the user and ask them to confirm that they're allowing your app to have access to 1Password. It (the CLI tool) would ask the user for their Master Password, create a session with the server and get everything configured. As a result, it would generate a token that the user could give to your app. This token would allow you to invoke op and have it work without having to ask for the Master Password. The user would then be able to see a list of allowed apps, and revoke their access whenever they want.

There's some pretty big up sides there, like putting the user in control of what has access, and never requiring that the user enter their Master Password into an app that isn't 1Password. We could even build it such that you wouldn't need to worry about sessions expiring (something you'd currently need to worry about).

I can think of some downsides though, but there may be some good mitigation strategies. You're still responsible for that token. If you've got that token, you've got the keys to the kingdom, and so there's still a LOT of trust that has to go on. Where are you persisting that so that it works across launches? On OS X using the Keychain would be an option as you could limit it to only be readable from an app with your codesignature. But how would we make sure that all developers are responsible with it? There's also the concern that this token would allow you to have access to vaults regardless of any kind of lock state. I'm not sure that a user could be expected to understand this.

It's difficult for us to find the right balance of how to enable super cool things like what you're trying to do, and doing so in a way that doesn't put the user or their data at risk.

Rick

ref: NGC-12387-625

hugom

Hi @rickfillion

Thanks for the details.

We are very eager to work hand in hand with you, step by step, to come up with a solution for the whole community of desktop application developers, even if it takes time.

For the general direction, according to your plans at AgileBits, what the preferred/official method to integrate 1PA in desktop applications will be based on:

• native messaging or similar methods
• the CLI tool op or similar methods
• (API is not the preferred method from you previous answer)
• others?

If we go towards native messaging: to start, do you think we can get a development version of 1Password that does not verify the code signature. We'll use it to develop our native messaging based solution, while you work on the user whitelist feature.

If we go towards the solution you described with op, we agree that it's best we don't manipulate the master password. So we'd really like to test it with you!
How do you see that working? Would that mean that UI prompt (native Cocoa / windows UI element) will come up from op ? or will it be q terminal window asking the master password?

Regarding the token, for sure we won't store it in backends and we'll use OS keychain if it's necessary to persist it on disk.

My teammates and I imagine a solution where the app trigger a 1Password gateway binary that popup the 1Password Desktop app for user approval and return an access token a la oauth protocol. What do you think about it ?

Hugo

rickfillion

Hi @hugom,

I need to be clear here: as it stands, today, there is no AgileBits-blessed way to accomplish what you're looking to do.

I'd love it if we made this kind of thing possible, but right now it's not possible. I was sharing thoughts on how I'd personally like to see different projects go, we aren't currently making any of those changes I mentioned.

The best that I can do right now is to get your contact information, and try to remember to reach out to you should this kind of thing ever becomes possible.

Rick

alexstrat

Here's Alexandre, Hugo's coworker

@rickfillion ok understood, that's too bad! :'(

Do you have visibility on when the user whitelist feature will be prioritized? Can we get in touch with a person that could give us this visibility? We would like to make sure we are high on your list of partners and beta testers for this project, and develop this relation with you!

rickfillion

@alexstrat : we have a policy of not discussing roadmaps like that. The feature is in idea stage at this point and there's no guarantee it'll ever get built.

We would like to make sure we are high on your list of partners and beta testers for this project, and develop this relation with you!

Once we have something to share with you, we'll try to reach out. I think it's awesome that you're wanting to do this. :)

Rick

srwatts

Love that Station and 1Password are working on this.

As a 1Password user who can't access a 1Password account and a secret key so it's frustrating at the moment that I can't use my 1Password with Station.
As much as I'd love to use Station I find copying and pasting passwords tedious and kills my flow.
Would love it to work like Chrome/Safari extension within Station.

AGAlumB

Thanks for the feedback! It's not something that's possible now, but the CLI app is coming along nicely. It will only become more powerful over time, and could help with a lot of different use cases. However, that will only work with 1Password.com accounts, as that's the only place for it to get data in most of the environments it needs to work. There are plenty of great browsers out there though that have robust extension frameworks for the native apps — or 1Password X — to integrate with. So perhaps we'll have more to say about this in the future. Cheers! :)