# Granted turns AWS role assumption into a browser flow you can run in parallel

> Granted is a Go command-line tool that finds and assumes AWS IAM roles and opens each one in a browser tab, caching credentials encrypted through the OS keyring rather than as plaintext SSO tokens on disk. It suits an engineer with many AWS accounts who is tired of pasting account IDs, and it does not suit anyone outside AWS, since the README states only AWS roles are supported.

**fwdcloudsec/granted** — The easiest way to access AWS.

- Repository: https://github.com/fwdcloudsec/granted
- Website: https://granted.dev
- Stars: 1,807 · Forks: 155
- Language: Go
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/fwdcloudsec-granted

## What Granted actually changes about AWS access

Granted is a command line interface application that simplifies access to cloud roles and allows multiple cloud accounts to be opened in your web browser simultaneously.

The problem it attacks is specific rather than general. The normal AWS role assumption flow is a chain: you know the account number, you open a console URL, you choose the role, you log in through your identity provider, and you confirm. Repeat that across many accounts and you are doing the same clicking repeatedly. Granted's stated goals are a fast experience around finding and assuming roles, using native browser functionality to allow multiple accounts to be accessed at once, and encrypting cached credentials so plaintext SSO tokens are never saved to disk.

The middle goal is the actual product. Opening several browser tabs at once means each tab runs its own SSO round trip in parallel, so the wall-clock cost of switching becomes one authentication latency rather than fifteen. The word "native browser" matters: the browser you already log into, with the SSO state it already has, rather than a headless flow that would need a separate device-authorisation grant.

The third goal is a security property rather than a convenience. Cached credentials go through the operating system's credential store, so a laptop disk image does not contain readable AWS tokens. That is a different posture from the many tools that write a JSON credentials file to `~/.aws/`.

Note what Granted is not. It is not an AWS client, not a credential rotation tool and not a policy engine. It changes how you authenticate and which session you land in; it does not change what you are allowed to do once there.

## The dependency list is the architecture

The `go.mod` file is more informative about Granted's design than the README, so it is worth reading as a specification. The module is `github.com/fwdcloudsec/granted` and declares `go 1.25.7`.

The AWS side is the modern SDK v2, and the specific service packages tell you exactly which flows are implemented: `service/sso` for IAM Identity Center, `service/ssooidc` for device-authorisation, and `service/sts` for the assume-role call itself, alongside `config` for profile loading. There is no `service/iam` package, which is consistent with Granted focusing on SSO-based access rather than long-lived IAM user keys.

Credential storage is `github.com/99designs/keyring` at v1.2.2. The repository includes `github.com/99designs/keyring`, but it does not document which platform backends are used or what happens when no keyring is available.

The browser side includes `github.com/pkg/browser`, although the repository does not explain how it opens or handles URLs. Combined with the parallel-tabs goal, that is the design in one line: Granted does not drive the browser, it points your browser at several URLs and lets your existing session do the work.

The supporting dependencies are ordinary CLI plumbing: `urfave/cli/v2` for argument parsing, `AlecAivazis/survey/v2` for the interactive selection prompts, `schollz/progressbar/v3` for download progress, `segmentio/ksuid` for sortable IDs, `go.uber.org/zap` for logging, `fatih/color` for terminal output, `gopkg.in/yaml.v3` for configuration, and `common-fate/grab` plus `common-fate/clio` from the same organisation, which appear to handle installation and framework setup. `alessio/shellescape` handles quoting for the shell integration, which is a security-relevant detail given what Granted injects into a shell.

## One binary, two names, and shell-specific wrappers

The Makefile reveals something the README does not: Granted installs under two names, and generates shell wrappers for three shells.

The `go-binary` target builds `./bin/dgranted` from `cmd/granted/main.go`. The `cli` target moves it to `${PREFIX}/bin/` with `PREFIX?=/usr/local` by default, then creates a symlink: `ln -sf dgranted ${PREFIX}/bin/dassumego`. The inline comment explains why the symlink is named differently from the real binary: replace references to "assumego", the production symlink, with "dassumego".

So the installed layout is a real binary plus a symlink, and the symlink's invocation selects a different mode. That is a command-dispatch trick, and it is worth understanding before you write scripts around it, because `dassumego` and `dgranted` are not interchangeable names for the same program.

The shell wrappers follow the same substitution pattern. The target reads `scripts/assume`, `scripts/assume.fish` and `scripts/assume.tcsh`, rewrites `assumego` to `dassumego` with `sed`, writes them out as `dassume`, `dassume.fish` and `dassume.tcsh`, and marks them executable. The `clean` target removes all four.

Covering bash, fish and tcsh means the credential export is a shell function rather than an environment variable you set by hand, which is what makes the flow feel like `assume` rather than a wrapper you have to remember to source.

The `aws-credentials` target is the one that deserves attention from a security standpoint. It echoes `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN` and `AWS_REGION` into a printable form. That is a debugging convenience, and it writes secrets to standard output, so it belongs in a terminal you trust and nowhere near a CI log.

The rest of the Makefile is cross-compilation plumbing. `test-browser-binary` and `test-creds-binary` build small programs from `cmd/testing/browser/main.go` and `cmd/testing/creds/main.go` for linux, darwin and windows, and `ci-cli-all-platforms` does the same for the main binary plus the symlink steps.

## Platform support, with Windows flagged as less tested

The README states Granted supports macOS, Linux and Windows, and immediately adds a caveat that is worth reading as a design constraint rather than a footnote: Windows support is less extensively tested than other platforms, with an invitation to report problems.

That statement sits next to a build system that cross-compiles the main binary and both test binaries for all three platforms. Those two facts together describe the situation accurately. The code compiles for Windows in CI, and it is not exercised as thoroughly as the macOS and Linux paths.

Why Windows would differ is not explained in the README. The most likely candidates follow from the dependency choices: the keyring backend is the Windows Credential Manager rather than a keychain, `pkg/browser` must hand off to the default browser on Windows, and the shell wrappers cover bash, fish and tcsh but not PowerShell or cmd. The Makefile generates wrappers for bash, fish and tcsh, but it does not describe a PowerShell or cmd equivalent.

On scope, the README is equally direct: Granted currently supports accessing roles in AWS, and asks you to open an issue if you want another cloud provider. The repository topics list aws, cloud, cloud-security, credentials, iam, keychain and sso, all of which are consistent with an AWS-only tool.

That single-provider limit is the clearest boundary in the project. There is no abstraction layer, no provider interface, and no plugin point described in the README.

## Getting started, and what the repository does not tell you

The README's getting-started instruction is a link. It points to the documentation at docs.granted.dev/getting-started, and the security section points to `SECURITY.md` in the repository and to the security documentation on the granted.dev documentation site.

There is no install command in the README, no package manager recipe and no configuration file format documented in the repository's own text. What the repository does contain is the Makefile above, which builds and installs from source, and a `docs/` directory in the top-level entries that presumably backs the hosted documentation.

The rest of the layout follows a standard Go CLI arrangement: `cmd/` for entry points including `cmd/granted/main.go` and the two testing commands, `internal/` and `pkg/` for library code, `scripts/` for the shell templates the Makefile rewrites, `.github/` for workflows, and a `Makefile` for building.

There are also governance files that say something about how the project is run: `CONTRIBUTING.md`, `MAINTAINERS.md` for the list of project maintainers, `CODE_OF_CONDUCT.md`, and `SECURITY.md` which covers how to report a vulnerability. The presence of a dedicated maintainers file and a security policy is a reasonable baseline for a tool that handles cloud credentials.

A `.tool-versions` file is present at the root, alongside the `go 1.25.7` directive in `go.mod`.

## Release cadence, licence, and the judgement to make

The version history is uneven, and that is the first fact to weigh.

Releases are v0.37.0 and v0.38.0 both on 2025-02-28, roughly ten minutes apart, then v0.39.0 on 2026-03-28. The last push was on 2026-09-11. So there was a burst of releases in a single day in early 2025, then a gap of more than a year, then a release, then six months of commits with no tag.

The project is not archived, and commits are recent. But a credential-handling CLI whose recent release gap is that shape is a dependency you pin carefully rather than track on every push. There is no CHANGELOG file in the top-level entries to help you work out what changed between v0.38.0 and v0.39.0.

Licence is MIT, in a file named `LICENCE` rather than `LICENSE`.

The judgement is straightforward. If you carry several AWS accounts and the pain is the repeated browser flow, Granted removes real friction and does so with credentials in the OS keyring rather than on disk. If you carry one account, or you already have a working SSO wrapper, the tool is not buying you much.

And if you run it on Linux, check the keyring first. Granted's third stated goal depends on `99designs/keyring` finding a working Secret Service implementation, and a headless or minimal server image without one is where the security guarantee quietly disappears.

## Conclusion

Adopt Granted when you switch between many AWS accounts daily and the bottleneck is the browser authentication flow, since parallel tabs are the feature nothing else in the toolchain does. Do not adopt it for a single-account setup or for other clouds, because the README states access is currently to AWS roles only. Before rolling it out to a team, read `SECURITY.md` and the security documentation on the project site, and confirm which keyring backend `github.com/99designs/keyring` resolves to on your Linux distribution, since a headless machine without a desktop keyring is the most likely deployment failure.

## FAQ

### What problem does Granted solve?

Granted is a CLI that simplifies access to cloud roles and lets multiple cloud accounts be opened in your web browser at once, so several SSO round trips happen in parallel instead of one after another.

### Which cloud providers does Granted support?

The README states that Granted currently supports accessing roles in AWS, and asks you to open an issue if you want support for another cloud provider.

### How does Granted store cached credentials?

Cached credentials are encrypted to avoid plaintext SSO tokens being saved on disk. The dependency list shows `github.com/99designs/keyring`, which resolves to the operating system's native credential store.

### Which platforms does Granted support?

macOS, Linux and Windows. The README notes that Windows support is less extensively tested than the other platforms and invites reports of problems.

### Why are there two binaries called dgranted and dassumego?

The Makefile builds `dgranted` from `cmd/granted/main.go` and installs it, then creates `dassumego` as a symlink to it. The Makefile comment says references to "assumego", the production symlink, are replaced with "dassumego", so the invoked name selects a mode.

### What licence is Granted released under?

MIT, in a file named `LICENCE` at the repository root. The project also ships `SECURITY.md` describing how to report a vulnerability, plus `MAINTAINERS.md` and `CONTRIBUTING.md`.

## Sources

- [fwdcloudsec/granted on GitHub](https://github.com/fwdcloudsec/granted)
- [License: MIT](https://github.com/fwdcloudsec/granted/blob/main/LICENSE)
- [Project website](https://granted.dev)
- [README](https://github.com/fwdcloudsec/granted/blob/main/README.md)
- [Releases](https://github.com/fwdcloudsec/granted/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fwdcloudsec-granted