I use Granted for per-terminal AWS credential assumptions — it’s great for switching between the multiple work accounts I juggle throughout the day. But I have SSO configured across more than one organization, and every morning I was logging into each one manually, one at a time, like a chump.
Turns out aws sso login has a --sso-session flag that targets a named session block from ~/.aws/config. So logging into multiple orgs is just two commands:
aws sso login --sso-session org-a
aws sso login --sso-session org-bEach command opens a browser tab, you approve it, done. Both sessions are authenticated and ready for Granted to assume roles from — whichever account you need next.
The named sessions come from [sso-session <name>] blocks in your config:
[sso-session org-a]
sso_start_url = https://org-a.awsapps.com/start
sso_region = us-east-1
[sso-session org-b]
sso_start_url = https://org-b.awsapps.com/start
sso_region = us-west-2Individual profiles then reference these with sso_session = org-a (or org-b), which is how Granted knows which upstream session to use when you switch profiles mid-day.
This doesn’t replace Granted at all — Granted still handles the per-tab assume step. This is just the upstream SSO login step, and knowing you can target named sessions directly makes the multi-org case a lot less tedious.
I’d been running aws sso login without the flag, which defaults to… something, and it wasn’t always obvious which org it was logging me into. The explicit --sso-session flag is strictly better.
via Perrotta.dev