DEV Community: 1Password

Join the 1Password Hackathon hosted by Hashnode and compete for $10,000 in prizes

Jason Harris — Thu, 01 Jun 2023 22:13:07 +0000

We love hackathons. In fact, that’s where the idea for 1Password came from – with all-night coding sessions that demanded credentials throughout the process.

Hackathons are high-energy, creative marathons that serve as a playground for innovation and collaboration, and often result in exciting projects that are a joy to deliver. That’s why we’re excited to announce the first virtual 1Password Hackathon hosted by Hashnode.

Taking place June 1st through June 30th, participants will compete for a chance to win $10,000 in cash prizes by building with 1Password Developer Tools and Passage by 1Password.

As much fun as in-person hackathons are, we’re also big fans of virtual ones that are global in scope and inclusive of all skill levels. If you’re a developer looking to sharpen your skills, network with like-minded individuals, and craft something extraordinary, the Hashnode Hackathon should be on your list. There are 10,000 reasons why – and utilizing 1Password Developer Tools and Passage can make your experience even better.

Your mission – and the tools in your toolbelt

1Password Developer Tools brings the speed and security of biometrics to your dev workflows. Passage unlocks passwordless sign-in – powered by passkeys – for your users. Hackathon participants will receive two free months of 1Password and 1Password Developer Tools, including Shell Plugins and 1Password CLI for new customers. For Passage, the free tier will suffice for hackathon purposes.

Let’s talk details. For the hackathon event, we’re challenging you to build with or on top of these tools:

Passage by 1Password: The easiest way to implement passkey authentication in your app or website.
1Password Shell Plugins: Eliminate API access keys stored on disc and securely authenticate any CLI with your fingerprint, Apple Watch, or other biometrics.
1Password CLI: Automate administrative tasks, securely provision secrets across development environments, and use biometrics to authenticate in the terminal.

What are 1Password Developer Tools?

1Password is a password management platform used extensively in the developer community, in part because of features designed specifically for developers.

With 1Password Developer Tools, you can securely store passwords, API keys, and other secrets, then access them in your code or easily share with your team members. This not only makes your project more secure but also simplifies collaboration.

What is Passage by 1Password?

Passage allows you to implement seamless passwordless authentication in your app or website with just a few lines of code. Eliminate passwords for good with Passkey Complete, a standalone solution that defaults to passkeys with fallbacks to other passwordless methods. Or use Passkey Flex to add support for passkeys alongside your existing password-based auth flow. Passage takes care of authentication so you can focus on the core logic of your hackathon project.

During the June Hackathon, we invite you to show off your skills and submit a project that expands Passage by integrating it with other platforms, like Supabase. Or, you could build one that shows a creative way Passage can be used to streamline sign-in for your application or service.

Want to really impress the judges? Make your project multi-platform and show how Passage works across systems and devices.

Examples from the community

1Password wouldn’t be 1Password without the developer community. In fact, more than half of our published Shell Plugins have been written by the community!

We’ve seen some amazing projects and integrations built on the 1Password CLI, including the VS Code integration and a community-written JetBrains integration. And we can’t wait to see what Hackathon participants build to extend Passage to new frameworks and platforms. If you’re looking for inspiration, we’d love to see more integrations like the newly published Supabase package.

And for even more projects contributed by the community, see the 1Password Community Showcase.

To get started, register to participate with Hashnode. You’ll receive an email containing a coupon code and instructions to redeem your two free months of 1Password for new customers.

Get support from the 1Password community

Need some guidance to help you get started – or to stay on track? We’re here to help.

Chat with other devs in our Developer Slack community and on the Hashnode Discord.
Set up a pair programming session with our engineers. To request a session, see the instructions in the Discord channel.
We’ll have two live events in June including the Hashnode Workshop with demos and Q&A on June 7th and a Community Office Hour on June 23rd.

Good luck to all participants!

This hackathon is an exciting community project and we look forward to meeting and learning from you! We’ll be watching all the action on Discord, our Developer Slack, and GitHub. Please be sure to use #Buildwith1Password so we can help spread the word and profile your work!

Let’s get hacking!

Please note, this hackathon is a Hashnode contest and terms and conditions apply. You can find all applicable details on the contest website.

Unlock any CLI using biometrics with 1Password Shell Plugins

Jason Harris — Wed, 07 Dec 2022 17:49:08 +0000

I love Touch ID. When I use it to log in to a site or authorize a purchase, authentication just kind of happens. It doesn’t feel futuristic anymore, but it does feel like the present. It’s the modern computing experience.

Then I open my terminal, and I'm transported right back to the past. Why can't devs have that modern experience?

I know I'm not alone. When we introduced Touch ID support for 1Password CLI 2.0, one of the most frequent pieces of feedback we heard was: Can we have touch ID for all CLIs?

So, about that.

Introducing 1Password Shell Plugins

We use CLIs to perform quick actions from the comfort of our terminals and automate recurring tasks. You might use the GitLab CLI to submit your code in a merge request, so the team can review it and include it in the next release, for example. Many other developer platforms like AWS, Stripe, Sentry, and CircleCI offer CLIs as well.

Connecting a CLI to your online account often involves generating API access keys in a browser, then pasting those values into the terminal. Those credentials are usually saved in a plaintext config file that gives the CLI persistent access to your account, even after reboots. But if an attacker or process gains access to your system, they have the same level of access to your account that you do.

We built 1Password Shell Plugins so you can securely store all of your access keys in encrypted 1Password vaults, rather than on disk. When you use a Shell Plugin for a particular service, access to the associated API keys is restricted to your specific terminal session.

Because they're saved in 1Password, you can securely sign in to any CLI with your fingerprint or another form of biometrics. If the service supports it, MFA codes can be filled automatically – so there’s no need to pull out your phone multiple times every day.

In fact, there’s no need to type anything. No plaintext, no typing passwords, no hassle – you can stay in the zone and focus on the task at hand.

Extensibility built in

We’ve already built Shell Plugins for many popular CLIs, including:

GitLab
CircleCI
Amazon Web Services
Sentry (Get $240 in Sentry credits with code “1Password”)
Stripe
Twilio
GitHub

There are many more pre-built integrations, but you’re not limited to the ones we built. You can build your own, for any CLI.

Shell Plugins are fully extensible and aren’t restricted to specific services. If you don't see an integration you need, you can join the open source project (currently in beta) and contribute your own.

Want to add MFA support to an existing Shell Plugin? You can do that too.

Many of our users rely on GitLab to shorten code review cycles, increase their developer productivity and strengthen overall security at every step. 1Password’s latest rollout is an important development in that last bucket. Launching Shell Plugins will help ensure developers can access our tools in their terminals as quickly and securely as possible. – Kai Armstrong, senior product manager, GitLab

Your keys, but portable

Storing your keys in 1Password means you can use them everywhere. If you switch to a different machine, system, or environment, the process is exactly the same.

Just install and configure Shell Plugins on your machine, then use biometrics to grant access to your key in 1Password. If the plugin supports MFA, you can use 1Password to autofill the codes.

This all makes setup, developer onboarding, and collaboration simpler. If new teammates are in the relevant group in 1Password, they already have the permissions they need to access the shared credentials and contribute immediately. All they have to do is install the 1Password CLI and the appropriate Shell Plugins.

How Shell Plugins work

Once you've set up 1Password CLI, you can install a supported Shell Plugin with a single command. For example, to install the plugin for GitLab, you would run:

op plugin init glab

During the configuration process, you can import existing credentials from your config file or create new credentials in 1Password.

At this point, your credentials are safely stored in 1Password, so you can remove them from your disk.

Check out the developer docs to learn more about Shell Plugins.

Introducing CI/CD integrations

One more thing. When you’re setting up a CI/CD workflow, you often need to manually enter secrets by visiting the settings page of the tool you’re using. But now you can store those secrets in 1Password, too.

You can access them directly within your CI/CD tools – and reference their location in 1Password directly within the job that requires them – via new integrations for:

Again, feel free to jump into the documentation to get started.

Securing the software development life cycle

Our goal is to bring this same level of security and ease of use to the entire software development life cycle. My colleague, Marc Mackenbach, has written about how far the developer user experience has to go before it catches up with the consumer experience in terms of both security and UX.

We're working on that. Check out 1Password.com/developers for a quick overview of everything we’re building to secure developer workflows. In the meantime, feel free to start exploring the Shell Plugins documentation.

And maybe keep your phone in your pocket. You won’t need it nearly as often anymore. 😉

Brick by brick: why Docusaurus is a powerful documentation framework

Jody Heavener — Wed, 06 Jul 2022 15:33:34 +0000

At 2022’s AGConf (1Password’s annual employee conference), every employee received a goodie box to celebrate the event and the company’s successes over the past year. Our theme this year was “space”, so the goodie box included a kit for a Lego rocket ship (very appropriate considering our own CEO is a Lego aficionado).

Building the spaceship brought me back to when I was younger and played endlessly with those little bricks.

For me, though, it wasn’t so much about building the specific items in a kit. Sure, I absolutely loved putting together the houses and planes and cars, but what I was most fascinated by was how I could use tiny bricks to expand my creation and build anything I could dream up. The possibilities were endless, my imagination ran wild, and sometimes – usually through through dumb luck – I built something way cooler than what the kit offered in the first place.

Late last year, I started exploring the React-based documentation framework Docusaurus, and spent a good chunk of time going through the documentation. (Surprise! They use their own product!) I got pretty familiar with how it works under the hood, and the ways in which it can be expanded on. It's also got a bustling community, which is unsurprising since it’s entirely open source.

When I joined 1Password earlier this year, where I would be driving the effort to stand up a developer portal for our new developer offerings, I was excited to learn that we’d chosen Docusaurus v2 as the framework to power it all. I’ve had a chance to really dig in since then, learning as much as I could about this powerful little static site generator.

And it occurred to me recently that, with the way they’ve set it up, I’m reminded of those Lego creations: at its core it’s really just a bunch of individual pieces cleverly interlocked to create something far greater. It’s also built on a foundation designed to be entirely extensible.

So I’d like to look at how Docusaurus is put together, and why it’s so great for the 1Password developer portal.

Plugins all the way down

Plugins are the building blocks of features in a Docusaurus 2 site. Each plugin handles its own individual feature.

Docusaurus has handy plugin lifecycle APIs. When you start up the development server or generate a static bundle, each plugin kicks in and traverses through every stage of the lifecycle. With it, you can pull in data across all plugins simultaneously, register routes, validate configuration, and inject HTML tags, among many other things. Docusaurus leverages these same APIs to build up the overall user-facing functionality of the framework through their own collection of plugins.

Consider the primary use case for Docusaurus: documentation. The @docusaurus/plugin-content-docs plugin powers this central feature for the framework. Its more immediate functionality comes from using the loadContent method to look for potentially localized and versioned sets of documentation on the filesystem, and contentLoaded to provide the structured route data for the core to register and produce HTML files. It also extends Docusaurus’ CLI to allow for tagging a new docs version, and even tells the dev server which files to watch, and in turn run the lifecycles again.

The documentation plugin is obviously a huge part of Docusaurus, but they don’t stop there. Everything from the docs, to blogging and individual pages, all the way down to setting up Google Analytics and generating sitemaps are all powered by plugins.

So, why is this important?

If you’ll allow me to borrow my Lego analogy again: Docusaurus’ plugin APIs mean that, while they provide you with a kit you can set up and build something really cool with, they’ve also provided you with the ability to extend the framework in any direction to build something to suit your exact needs (at least as far as static sites go).

Great examples of this can be found on their community plugins page, where others have built plugins for offline/local search (we even use this today), adding SASS styles loading, and consuming OpenAPI specs to generate full API documentation pages. And it couldn’t be easier to roll your own.

Let’s say you wanted to load in some Google Fonts. Here’s what a plugin that does this by using the injectHtmlTags method might look like:

module.exports = function pluginGoogleFonts(context, options) {
  return {
    name: "plugin-google-fonts",

    injectHtmlTags: () => ({
    // Tell the browser we're going to be loading resources from these origins
      headTags: [
        {
          tagName: "link",
          attributes: {
            rel: "preconnect",
            href: "https://fonts.googleapis.com",
          },
        },
        {
          tagName: "link",
          attributes: {
            rel: "preconnect",
            href: "https://fonts.gstatic.com",
            crossorigin: "anonymous",
          },
        },
        // Load the Lobster font
        {
          tagName: "link",
          attributes: {
            rel: "stylesheet",
            href: "https://fonts.googleapis.com/css2?family=Lobster&display=swap",
          },
        },
      ],
    })
  }
};

With this plugin in place, you can now freely use the Lobster font in your CSS. If you wanted to take it a step further and package this plugin up for distribution, you could even allow it to take an array of font names and weights as options to make it truly dynamic.

In the future, as we expand our developer portal, you’re likely to see us build plugins for things like importing and rendering developer blog posts, highlighting integrations built by our developer community, and a whole lot more.

Need to customize it? Swizzle away.

Plugins aren’t limited to just extending functionality, either. They’re what also delivers the look of the framework. Using the getThemePath method your plugin can tell Docusaurus where to find the React components that make up a theme, selectively overriding components from an existing theme or building your own theme from the ground up.

One of the neatest features of Docusaurus is the ability to Swizzle a component.

[Swizzling] comes from Objective-C and Swift-UI: method swizzling is the process of changing the implementation of an existing selector (method). For Docusaurus, component swizzling means providing an alternative component that takes precedence over the component provided by the theme.

What does this mean in practice? Well, our developer portal currently uses the default Classic theme, but if you check out our footer you’ll notice that it looks nothing like the footer in that theme. We wanted ours to share a consistent look with the one on 1Password.com, so we swizzled the existing Footer component by running the following command:

npm run swizzle @docusaurus/theme-classic Footer -- --eject

This cloned the component out of the Docusaurus package and into our workspace. Now we've got full agency over the look and feel of the site’s footer, while still being able to rely on the rest of the theme’s components, which also includes future updates. We’re going to be swizzling a fair bit this year as the developer portal evolves.

The framework ships with the Classic theme, and out of the box it does a fantastic job. As of April 2022 the theme selection is fairly limited for v2 of Docusaurus, with only the Classic theme and some extensions to it available. More are coming, though. One that I’m particularly looking forward to, a Tailwind-powered theme, is also a great example of why I appreciate that they’re an open source project: it started as a community request, grew in popularity, and over time evolved into part of the roadmap.

Markup or Markdown - how about both?

As with every static site generator, it’s expected that Docusaurus would support Markdown - and they took it a step further, using MDX to parse content. MDX allows you to write JSX (React components) alongside your Markdown, allowing seamless native integration with the rest of the React app, which eventually gets all compiled down to HTML. This concept of static site generators interlacing Markdown with another syntax to extend the capabilities of its documentation is not new, but what gets me excited is the power that JSX affords us. You’re not limited to static HTML or shortcodes. Instead you get the full power of JSX components, meaning it’s possible to build fully styled, rich components that you can embed right in your content.

MDX also supports Remark and Rehype plugins, allowing you to augment the syntax and replace content on the fly. What can we do with this? Docusaurus demonstrates this well by creating its own plugins for admonitions, table of contents generation, and creating heading links.

There’s already a huge collection of plugins available for both Remark and Rehype, but if you need something a little more tailored to your specific use case creating these types of plugins is really straightforward, too. Consider this 13-liner that defaults Markdown code blocks to using Shell highlighting:

const visit = require("unist-util-visit");

module.exports = function pluginRemarkShellCode(context, options) {
  return (tree) => {
    visit(tree, (node) => {
      // If the node is a code block, but the language is not set
      if (node.type === "code" && !node.lang) {
        // Set it to Shell
        node.lang = "shell";
      }
    });
  };
};

Using unist-util-visit we can iterate across all nodes and their children to selectively modify the properties or contents of any node that matches our criteria. Now our Markdown files only need to specify language for those code blocks that aren't using Shell.

Fully Open Source

I’ve been heads down in Docusaurus for quite some time now, and it’s proven to be incredibly robust. But beyond the framework itself, I’ve also really appreciated the community behind it. From contributing my own PRs to the core, to getting help from team members themselves and other eager developers in their Discord server, it’s been a pleasure creating with this extraordinary tool.

Go check out the 1Password developer portal, built with Docusaurus. I’m looking forward to showing off the cool things we’ve got planned for it down the road as we use these building blocks to create something really, really cool.

Introducing 1Password for Visual Studio Code

Jody Heavener — Thu, 23 Jun 2022 15:22:22 +0000

In writing software, we’re used to embedding secrets and other configurable values right in the codebase. They might be Stripe keys to power your online shop, webhooks for a custom Slack bot, a Docker username and password for a CI config, AWS credentials, or an API token and host to set up 1Password Connect.

Secrets are used everywhere in our code. Sometimes, though, we forget when we’ve been using real secrets in our work. Maybe there’s a leftover token you dropped in to build that one feature, or maybe you didn’t delete the .env file you set up to test drive the app. Now you’ve got to rotate your secrets because you accidentally committed and pushed sensitive values for the whole world to see. Yikes.

We’ve all been there. That’s why I’m delighted that I get to announce the launch of the all-new 1Password for VS Code extension.

Go ahead, commit your secrets references

With 1Password Secrets Automation, the 1Password Developer Products team introduced the concept of secret references. It starts by storing a sensitive value, such as an API credential or client ID, in 1Password. That item and the field you’d like to get the value from can then be retrieved through a special op:// URL scheme that 1Password’s tooling knows how to parse. It’s made up of three parts: vault, item, and field. This is known as a “secret reference”.

Now, instead of using a real value in your configs, environment variable files, or anywhere else in the codebase, just drop in the secret reference in VS Code. When you do, you can rest easy knowing that the real value will never accidentally make its way into your codebase.

The best part? Through our suite of tools and integrations, you can work with references in both local and deployed environments.

To help make sure you’re not accidentally leaving secrets in your code, you can move them over to 1Password with just a couple clicks. The extension uses a series of secret detection techniques to look for values that might be sensitive. With these matches, it makes inline suggestions to store them in 1Password, automatically replacing them with secret references.

Secret reference integration doesn’t stop there. You can hover a reference to inspect the item and field details, click it to open the item in the desktop app, and even preview the real values of an entire file full of references.

Beyond secret detection suggestions, 1Password for VS Code makes it easy to retrieve items for use in your code, as well as store any bits of code you’d like in 1Password. If you’ve got multiple values you want stored in the same item – perhaps a username, password, and email – it supports that as well. Just select each value and run the “Save in 1Password” command.

Built using tools available to everyone

I’ll let you in on a little secret: we didn’t plan to build this extension. It wasn’t requested by our developer community, and wasn’t part of any roadmap. Instead this extension began as a side project for myself. I wanted to scratch my own itch and integrate 1Password more closely into my development workflow, and to generally learn more about developing with 1Password.

So you can imagine my excitement when, after a quick demo at an internal call, I was invited to polish it up and get it slated for release.

To my delight, after demoing the extension and then going on vacation, Dave posted a video of the presentation from his CLI launch blog post and it was met with some pretty wild enthusiasm from the developer community. There was even some love for it at our 1Password 8 for Mac Reddit AMA:

Although not a goal from the outset, an interesting aspect of this project is that it’s built using only tools available to the public – there’s nothing internal or proprietary powering the features of the extension. We’ve even open-sourced the whole project on our GitHub, so if you want to help iterate on it or report an issue, that’s a great place to start.

VS Code extensions run in a Node environment, and we wanted to interact with the new CLI. So we built and open-sourced an entirely new package for doing exactly this: op-js. It wraps the CLI with a simple-to-use JavaScript interface and ships with TypeScript declarations, making 60+ commands, including those that support biometrics unlock, available to your Node-based application.

Ultimately my hope is that this extension demonstrates some of the neat ways you can extend the power of 1Password by building your own integrations, whether it be for yourself or others. And you should have fun doing it. We’re in early days here, with plenty more developer offerings coming down the line.

I’d love to hear what you think, and we’ll be iterating on the extension as feedback rolls in. Learn more about 1Password for VS Code and our other developer tools by checking out our developer portal. While you’re there, consider joining our Developer Slack workspace, where you’ll find myself and others on the Developer Products team who are eager to hear how you’re incorporating 1Password into your development workflow. And if you’re building something cool, be sure to tag it #BuildWith1Password!

Finally, we owe a tremendous debt of gratitude to Mike Selander, Chris Dunn-Birch, Floris van der Grinten, the incredibly helpful folks over in the VS Code Extension community, and so many more for providing endless help and guidance while working on this project. Thank you!

1Password for SSH changed the way I work

Jason Harris — Mon, 09 May 2022 17:12:06 +0000

1Password for SSH was shared with the world last month. I have been using it since it was available for internal beta. I knew it would improve my endpoint security. I didn’t expect it to change ~~the way I generated, stored and used SSH keys~~ the way I work.

Let me take a step back.

The first time I used SSH, I connected my college’s global lab linux server with PuTTY. I used a username and password to authenticate and never really appreciated the magic that made it all work. It was a step away from the familiar world of FTP and RDP.

SSH later became an integral part of my developer experience when my job switched from Subversion to Git. I was a Jr. Developer at the time and struggled to generate an SSH key. Another developer on the team generated an RSA key pair for me and shared it on a thumb drive. It was some years later before I realized this was less than ideal.

Eventually, I fell into a routine. I would get a new laptop, generate a private key – sometimes I would even use a passphrase – and upload the new key to all the services I used (GitHub, VPS, etc.). I used the one-key-per-device pattern and repeated the process for my phone and other devices. Occasionally, I’d pull a device from cold storage for something I forgot about.

The problem was that each SSH key represented one of my devices; it had no purpose attached to it. I used the same keys for work, open source contributions, file servers and a lot more. When I unlocked a key for one use, I unlocked it for all uses.

1Password for SSH has entered the chat

The 1Password SSH Agent has a stricter authorization model than the OpenSSH Agent[1] defaults[2]. Instead of a key either being available or unavailable, a key has an authorized session. An authorized session consists of the key pair and either a terminal session or application. I wanted to be able to deliberately authorize a set of actions for my current context (e.g., work or open source).

Thus, a new way of working.

I generated a new key pair for each of my use cases. 1Password in the browser made this really easy by autofilling the new key in the GitHub and Gitlab public key forms. Now, when it’s time to get to work, I open my terminal and run a git fetch. 1Password prompts for my fingerprint and I approve the usage of my Work SSH key.

I’m not prompted again while actively using my laptop. When it’s time to switch to an open source project, I’m seamlessly prompted for my GitHub key.

A little later, when I need to update my blog, I pop open a new terminal tab and start an SSH session. I forward my SSH Agent with ssh -A so that I can perform a git pull while I’m there[3]. When I’m done, I exit the terminal session, deauthorizing it from the 1Password SSH Agent.

Now, generating SSH keys is no longer part of my new device flow! All of my SSH keys are saved in 1Password and synchronized across my devices.

I’m really excited for Git’s recent addition of commit signing with SSH keys. It already works with 1Password SSH and I can’t wait for GitHub and Gitlab to support verification!

[1] SSH agent restriction looks really cool! ↩︎

[2] Similar functionality is available with ssh-add -c. ↩︎

[3] Eventually I’ll get around setting up a GitHub Action. At least, that’s what I tell myself. ↩︎

This post originally written by K.J. Valincik, Senior Staff Developer at 1Password.