Skip to content

feat: 1Password Desktop Application Integration#56

Merged
mbevc1 merged 3 commits intoByteNess:mainfrom
seiichi1101:feat/add-op-desktop
Jan 8, 2026
Merged

feat: 1Password Desktop Application Integration#56
mbevc1 merged 3 commits intoByteNess:mainfrom
seiichi1101:feat/add-op-desktop

Conversation

@seiichi1101
Copy link

This PR enables use of 1Password’s Desktop Application Integration introduced in onepassword-sdk-go@v0.4.0-beta.2 (release notes: https://github.com/1Password/onepassword-sdk-go/releases/tag/v0.4.0-beta.2).

I’m opening this PR to enable aws-vault to leverage this integration.

With my local environment, aws-vault is able to authenticate successfully via the 1Password desktop app. https://developer.1password.com/docs/sdks/desktop-app-integrations/

Key changes

  • opstandard.go was written with a service-account-only assumption. I kept the common logic there and moved the service-account-specific implementation into opsrvaccount.go.
  • Added opconnect.go to support the desktop app integration flow.
  • The fullClient field might look odd, but it’s intentional.
    • The current opstandard.go implementation only keeps an OPStandardClientAPI ( ItemsAPI in onepassword-sdk-go ) . As a result, the underlying Client object can be garbage-collected, which triggers its finalizer and causes the backend to invalidate that client ID at some point.
    • Personally, I think holding only a reference to client should be better. However, that would require touching more places (including tests), so I went with a minimal change for this PR.

Suggestions are welcome.

@mbevc1 mbevc1 changed the title 1Password Desktop Application Integration feat: 1Password Desktop Application Integration Jan 3, 2026
@mbevc1
Copy link

mbevc1 commented Jan 5, 2026

Thanks @seiichi1101 ! I didn't have time to properly look at this, but looks sane. Could I check it's backwards compatible (I assume thus the oddness?) Is choosing the integration based in ENV vars used or other mechanism?

@seiichi1101
Copy link
Author

@mbevc1

Could I check it's backwards compatible (I assume thus the oddness?)

Yes, please.
I haven’t had time to do a full compatibility pass yet, so I appreciate it.

I’ll also double-check backward compatibility on my side.

Is choosing the integration based in ENV vars used or other mechanism?

Yes - selection is via flags or environment variables.
I wrote the use case in aws-vault below.

Example in aws-vault

Usage

  • flag or env

aws-vault exec --backend=op-desktop --op-vault-id=xxxxx --op-desktop-account-name=myaccount

AWS_VAULT_BACKEND=op-desktop AWS_VAULT_OP_VAULT_ID=xxxxx AWS_VAULT_OP_DESKTOP_ACCOUNT_NAME=myaccount aws-vault exec

Config (Files changes)

var keyringConfigDefaults = keyring.Config{
...
+	OPDesktopAccountName:     "AWS_VAULT_OP_DESKTOP_ACCOUNT_NAME",
...
}
+	app.Flag("op-desktop-account-name", "1Password Desktop App Account Name").
+		Envar("AWS_VAULT_OP_DESKTOP_ACCOUNT_NAME").
+		StringVar(&a.KeyringConfig.OPDesktopAccountName)

@mbevc1
Copy link

mbevc1 commented Jan 6, 2026

Thanks, might be worth opening a PR after this is merged.

@manselmi might be worth you glancing over this if you have time, as you implemented first support of OP 😉

Copy link

@manselmi manselmi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seiichi1101 Thank you for implementing this! When I saw that desktop app integration was introduced into the SDK, I was curious if someone would get around to adding support to keyring and aws-vault before I would. I'm glad you did, as I currently don't have bandwidth for further work on keyring or aws-vault.

I've requested one minor change regarding renaming the value of the OPDesktopEnvAccountName constant, otherwise looks good to me (assuming your own backwards-compatibility testing looks good).

opdesktop.go Outdated
)

const (
OPDesktopEnvAccountName = "OP_DESKTOP_ACCOUNT_NAME"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to https://github.com/1Password/onepassword-sdk-go/blob/v0.4.0-beta.2/client_builder.go#L89:

Takes as input the account name as specified in the desktop application, or the account UUID.

Perhaps the value of the constant should be changed to OP_DESKTOP_ACCOUNT_ID to imply that either account identifier (name or UUID) is acceptable. aws-vault would have the AWS_VAULT_OP_DESKTOP_ACCOUNT_ID env var and --op-desktop-account-id option. What do you think?

This rationale is why I opted for OP_VAULT_ID here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.
I’ll follow your suggestion and rename it to OP_DESKTOP_ACCOUNT_ID.

Comment on lines +42 to +44
// fullClient stores the complete client to prevent premature garbage collection
// which would trigger the finalizer and release the client ID
fullClient *onepassword.Client
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this!

From what I can tell, in the 1Password Connect backend, we're already storing the complete client. So this finalizer issue shouldn't be present in that backend. Is that right?

(Adding the first two 1Password backends was some of my first ever Go code, and this sort of issue had never crossed my mind.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe so.

While this PR bumps the onepassword-sdk-go version, client creation in opconnect.go doesn’t use onepassword-sdk-go; it uses https://github.com/1Password/connect-sdk-go.

In addition, opconnect.go has little dependency on onepassword-sdk-go, so I don’t expect this change to affect the 1Password Connect backend.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the way you refactored opstandard.go across opstandard.go and opsrvaccount.go.

@seiichi1101 seiichi1101 requested a review from manselmi January 8, 2026 10:37
Copy link

@manselmi manselmi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seiichi1101 Looks good to me!

@mbevc1
Copy link

mbevc1 commented Jan 8, 2026

Thanks both! 🚀

@mbevc1 mbevc1 merged commit 4cd83c7 into ByteNess:main Jan 8, 2026
4 checks passed
@mbevc1
Copy link

mbevc1 commented Jan 8, 2026

hm, is beta still missing some bits? 🤔

Getting errors trying to build: https://github.com/ByteNess/aws-vault/actions/runs/20834085009/job/59855066619

@mbevc1
Copy link

mbevc1 commented Jan 9, 2026

Looks like there might be platform specific deps now so cross compilation is broken 🤔

@seiichi1101
Copy link
Author

seiichi1101 commented Jan 9, 2026

@mbevc1
I can reproduce this locally when CGO_ENABLED=0.

I'm not sure whether aws-vault is intended to require cgo or not. In the GitHub Actions workflow: https://github.com/ByteNess/aws-vault/blob/main/.github/workflows/release.yaml#L11

$ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w -X main.Version=v7.9.0" -trimpath -o aws-vault-linux-amd64 .
# github.com/1password/onepassword-sdk-go/internal
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:72:5: undefined: coreLib
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:77:3: undefined: coreLib
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:77:18: undefined: loadCore
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:81:3: undefined: coreLib
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:84:40: undefined: coreLib
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:90:12: undefined: SharedLibCore
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:111:12: undefined: SharedLibCore
../../.asdf/installs/golang/1.25.5/packages/pkg/mod/github.com/1password/onepassword-sdk-go@v0.4.0-beta.2/internal/shared_lib_core.go:133:12: undefined: SharedLibCore

@mbevc1
Copy link

mbevc1 commented Jan 9, 2026

IIRC it was only enabled for Darwin upstream and was causing some cross-compile build issues otherwise, I'd need to recheck.

@seiichi1101
Copy link
Author

FYI: I double-checked backward compatibility using a 1Password Service Account token on my side. I ran a couple of basic commands using aws-vault (e.g., aws-vault add and aws-vault exec), and it seems to be working as expected.

(Sorry for the late reply — I needed approval from our internal IT team before I could use a 1Password Service Account.)

@mbevc1
Copy link

mbevc1 commented Jan 21, 2026

No worries and thanks for checking, I'm still trying to get GHA pipelines to build using CGO with a mix of cross-compile libraries and native runners. I haven't merged this in to aws-vault yet. The CGO requirement is coming from beta 1P SDK now 🙄

@mbevc1
Copy link

mbevc1 commented Jan 23, 2026

Okay, got it cross compiled across all platforms, but I needed to exclude FreeBSD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants