Protect what matters – even after you're gone. Make a plan for your digital legacy today.
feature request
66 Topics1Password Environments Beta is awesome
Just wanted to drop some feedback after playing around with the new Environments Beta in 1Password. Honestly, I’m loving it so far. The local .env file mounting is just brilliant. Secrets are easy to access without having to run extra commands, but still secure – exactly what I want. Makes switching between machines seamless, too. A couple of things I’d really like to see next: 1. CLI Integration - being able to create/edit/list environments and variables from the terminal would make this so much more useful, right now, having to click around in the desktop app is a bit of a pain for dev workflows. 2. More integrations: AWS Secrets Manager is a great start, but would love to see GCP and other major providers such as GitHub, etc. A plugin system for integrations would be awesome also to help cover more niche players like Modal.com Overall, this is a huge step in the right direction for 1Password. Can’t wait to see where this goes next!435Views4likes3Comments.env files should support more file formats
Hey, I was incredibly excited to see the 1Password beta supporting .env files. After testing it out in the latest beta, I understand that this is incredibly useful for environments that support traditional .env files. However, as someone working with building mobile apps, specifically for iOS, I was hoping that the new feature was a tad more flexible, enabling me to use it in .swift files. Specifically, I was hoping that the new feature would replace references to secrets in existing files rather than creating a new (temporary) file. If it were replacing references in existing files, we could use the .env support in 1Password's Environment with any file template. I understand the downsides to this, but in the mobile landscape it's not uncommon to hardcode select secrets in the binary and even when doing so, we'd like to keep those secrets out of version control. Therefore, we have .swift template files that look like this: enum Secrets { enum SomeService { static var apiKey: String { "{{ op://Acme GitHub Actions/Some Service API Key/API Key }}" } } } These files are named Secrets.tpl.swift and are stored in version control. We use `op inject` to inject the secrets into these files and output them as Secrets.swift, so they're referenced at compile time. Secrets.swift is not checked into version control, of course. I was hoping that we could mount Secrets.tpl.swift or similar in 1Password Environments to have it handle the secrets for us, as .env files aren't really a thing in iOS development. I'm excited to use 1Password Environments with the new .env files in backend development, but I hope you'll consider making it more flexible, so it can accommodate more platforms too. Best regards, Simon B. Støvring332Views3likes10CommentsEnvironments feature request: Add notes to variables & insert them as comments in the final .env
Hey folks! I'm really liking the Environments Beta, but one thing I'm missing is the ability to keep the comments I had in my old manual `.env` file. For example I have an API key that has no indication of which actual account it's for, so it would be really nice to be able to add this as a note in 1Password and have it end up in the resulting .env file. So in this example, the "API_KEY" variable would have a note attached in 1Password that said "Associated account is frobulator@example.com" and the resulting .env file would look like this: $ cat .env # This file was generated by 1Password. Any manual edits will be lost. # For more information, visit: https://developer.1password.com/docs/environments/local-env-file BASE_URL=https://prod.example.com # Associated account is frobulator@example.com API_KEY=uophfpanfphbofsgfoibCVHDFBahpis73Views2likes2CommentsFeature Request: API Endpoints for 1Password Usage Reports
Today, it doesn't look possible to pull the usage reports via API. We have clients who request these reports, and having to login to each customer and manually pull the report from within the Admin portal can be very time consuming. Having the ability to pull these reports via API would speed up this process, and even allow us to schedule these reports.95Views2likes2CommentsAutomated Connect server token rotation
I've been evaluating whether I can use 1Password Connect for configuration/secrets management for my company's services. 1Password Connect looks very appealing for several reasons: No rate limits. No usage limits. As a 1Password customer, we have unlimited access to this offering. Uniform UI. We already use 1Password for managing passwords and various secrets used during local development. It would be very nice to use the same interface to manage lifecycle of configurations and secrets that are used by production services. Pretty straightforward REST API and SDKs in languages that we use allows getting the latest config/secret values at runtime. I am not very interested in using 1Password Connect Operator (or using k8s Secrets in general) since this provides secrets to the service at deploy time. I appreciate the ability to automatically redeploy the service when the underlying 1Password item changes but this works well only for stateless services. I prefer getting configurations/secrets at runtime over an API. I started experimenting with this offering and working out how to integrate it into our systems. The docs recommend creating a Connect server token for every service which makes a lot of sense. And the docs strongly suggest setting an expiration on this token which also makes sense. After all, it's a static credential not tied to the identity of the service that uses it; so frequent rotation should reduce the risk of a leaked token causing damage. But the issue is that I don't see a way to automate this rotation given the permission model that is in use today. Is it possible for either a Service Account or a Connect client to manage connect tokens (create/delete tokens)? I was thinking of integrating 1Password connect as follows: Our deployment pipeline is high trust. It would use either Service Account or Connect client credentials that expire infrequently. It's OK for a human to ensure this credential doesn't expire and rotate it when necessary. When a service deployment is kicked off, the deployment pipeline creates a new Connect token. The pipeline ensures that the newly created Connect token is accessible to the service as an environment variable. Once the service is deployed and is considered healthy, the old Connect token (used by the previous deployment of the service) is deleted. In this setup, the deployment pipeline can create the new Connect token with a relatively short expiry and we can assume that every service gets redeployed more often than this expiration period. I think this setup is pretty reasonable but I don't see a way of giving the deployment pipeline access to create/delete Connect tokens. I tried using a Service Account to create a Connect token via the CLI and got 403. I see that it's possible to give a group access to manage Secrets Automation, but I don't think it's possible to make a Service Account a member of some group. Correct me if I am wrong. I also tried using a Connect client to create a new Connect token and this didn't work: "op connect token create" doesn't work with Connect. https://developer.1password.com/docs/connect/manage-connect of your docs mentions: "You can use 1Password.com or the https://developer.1password.com/docs/connect/api-reference/ to: ... https://developer.1password.com/docs/connect/manage-connect#create-a-token and https://developer.1password.com/docs/connect/manage-connect#revoke-a-token Connect server tokens." but I think it's a typo. As things stand today, Connect server token rotation can only be done by a human user which doesn't scale beyond a handful of services. If I were to go down that path, I would have to set expiration to a longer period which affects security. This makes 1Password Connect a lot less appealing. Please let me know if I am missing something and if there is a way to automate token rotation.282Views2likes0CommentsEdit items (json) without losing passkeys
Just came across this fun notice in the docs: "JSON item templates do not support passkeys. If you use a JSON template to update an item that contains a passkey, the passkey will be overwritten. To fix this, you can restore a previous version of the item." Which mean this method of editing an item is out the window for any items which contain passkeys :( Want to bump this issue, and also say that perhaps a different kind of programmatic update without needing to pass in the entire json blob could be useful.32Views1like1CommentFeature Request: Linking Address to Multiple Logins
Hello 1Pass Developers, I'm currently in grad school, so my address has been changing a lot lately, and it's been a real pain to track all the accounts that I need to update my address in. I have started a spreadsheet that tells me all the accounts that I regularly use that have a certain address associated so that next time I move, I remember to update the important accounts (bank, medical, etc.) - But I figure it would be way easier to do that if you could link certain addresses (from a profile) to accounts that use it. That way, I could go into the profile with my old address and see all the accounts I need to change (similar to hyperlinking (Wikipedia) or back-linking (Obsidian). Just a suggestion that I would really love to see, but maybe there's already something similar - please let me know if so!25Views1like2CommentsCustom aliases and OpenSSH fields for SSH Bookmarks
SSH bookmarks is a great feature - one I was intending on building myself until I found 1Password's docs for it. However, it is missing a couple important features for me to be truly happy with it. I setup aliases for my common SSH hosts, and would like to be able to add these into 1Password. In particular, I want to be able to set custom names for each bookmark. For instance, I SSH to my university's servers typically with `ssh unsw`, not the far longer `ssh zXXXXXXX@loginX.cse.unsw.edu.au`, which is what the bookmark matches on. In addition, some of these bookmarks are for trusted hosts, where I want to enable `ForwardAgent yes` or similar additional OpenSSH options, and being able to use bookmarks to set these across my devices would be extremely helpful. Currently, I have a config file local to each computer that contains something like the following for each host: Host unsw User zXXXXXXX HostName loginX.cse.unsw.edu.au ForwardAgent yes CanonicalizeHostname yes This converts `unsw` to the long form user and host that is matched by the bookmark config. Ideally, these could all be configured via 1Password. A generic syntax for custom OpenSSH options would also solve other missing properties mentioned by others on this forum (e.g. ports).95Views1like3CommentsAPI key storage
In the new "Developer" tools, I'd love to see proper API key storage. Honestly a lot of this can be accomplished with standard 1Password tools but I want to keep passwords separate from API keys whether by category or just plain feature separation into developer tools. It would be great if the browser extension could differentiate between an API key / token and a password. Even if it can't it would be great to have an option to specify API vs password. One key difference between passwords and API keys is that on one site you generally have a single login/password but with API keys you have one site and many keys usually with key/value pairs. -- Example -- Type: API Site: Anthropic URL: console.anthropic.com Key name: Project A Key value: [32bit key value] Key name: Project B Key value: [32bit key value] Key name: Project C Key value: [32bit key value] --- \ Example --- Again, I understand you can make this work with existing passwords but API keys should be treated differently and have their own feature space. This is a good feature for developers, and when evaluating a 1password for Business feature space an IT admin has to deal with a lot of API keys and it would be good to store them securely and easily be able to identify which API keys they may need to rotate. API keys could also be worked into Watchtower as API keys that have been leaked or exposed in data breaches. API keys are not just used within .env files, it could be website and even AI desktop tools like MCP server settings.167Views1like0CommentsPassword generator when exporting ssh keys
It would be nice to integrate the password generator when exporting ssh keys to create a random passphrase saved in the key entry in 1Password. The workflow for this is clunky currently as I create a new password field in the entry with a randomly generated password and then use that as the passphrase when exporting the key. Now, when the key is exported 1 password saves an entry of the passphrase used to export the key. Now I’ve got two entries for the same phrase. it would be a much simpler flow if the passphrase could be randomly generated inside the export key dialogue instead.35Views1like1Comment