aws sso login: allow to customize ip address for redirect_uri

[miki725]

Describe the feature

Recently aws sso login started using Authorization Code flow vs previously default device auth flow. As part of that flow CLI shows a URL which embeds a redirect_uri which redirects back to 127.0.0.1 after flow is successfully completed on the AWS side. For example:

➜ aws sso login
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://oidc.us-east-1.amazonaws.com/authorize?response_type=code&client_id=SECRET&redirect_uri=http%3A%2F%2F127.0.0.1%3A34535%2Foauth%2Fcallback&state=TRUNCATED

This works great if you are running the command locally on the machine. However sometimes its useful to run it on a remote machine where 127.0.0.1 does not work for the redirect_uri.

Use Case

Running aws sso login on a remote machine where 127.0.0.1 is not accessible for the redirect_uri

Proposed Solution

The request is to allow to customize the host of the redirect_uri which will allow to use the Authorization Code flow from a remote connection:

➜ aws sso login --redirect-host=<remote-hostname>

Other Information

As a workaround currently its possible to switch to use the device auth flow:

➜ aws sso login --use-device-code

although the new authorization flow is a lot more slick as it requires much fewer clicks on the browser.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CLI version used

2.22.15

Environment details (OS name and version, etc.)

aws-cli/2.22.15 Python/3.12.6 Linux/6.10.8-arch1-1 exe/x86_64.arch

[ashovlin]

Double-checking, is the desired alternative hostname still the machine that you're originating the login from? If not, we'd need mechanism to get the authorization code that is returned by the redirect back to the machine that is logging in.

Currently AWS IAM Identity Center requires this to be 127.0.0.1, since we're relying on the implicit trust users have in software running on their own machine. I'll raise this with them internally, but you may need to rely on --use-device-code as you described for now.

[miki725]

In my specific use-case, I ssh into my home server where I do all dev work on. I implicitly trust that machine. Just the redirect back to 127.0.0.1 doesnt work for me as I open it the login URL in my local machine browser hence the redirect back to 127.0.0.1 doesnt work.

Ideal flow:

• ssh into server

  @local ➜ ssh server
  

• execute aws sso login on a remote server with hostname override

  @server ➜ aws sso login --redirect-host=server
  Attempting to automatically open the SSO authorization page in your default browser.
  If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
  
  https://oidc.us-east-1.amazonaws.com/authorize?response_type=code&client_id=SECRET&redirect_uri=http%3A%2F%2Fserver%3A34535%2Foauth%2Fcallback&state=TRUNCATED
  

  note the server in the redirect_uri. As server is resolvable for me, the redirect will then work as expected in local browser.

Alternatively if you want to restrict to just trust 127.0.0.1, if you can provide a param to use specific port for the auth flow, it will allow to ssh forward specific port hence 127.0.0.1 will work in the browser. Otherwise currently I think the port is random on each execution

@local ➜ ssh server -L 1234:localhost:1234
@server ➜ aws sso login --redirect-port=1234

[zeroimpl]

I had a similar issue. I use the AWS CLI within a Docker container on my machine. Since it picks a random port each time, I can't easily forward the port through my docker config. Allowing the user to specify a specific port to use in the ~/.aws/config file would work for me.

[maru-ava]

Interesting that a cloud infrastructure company wouldn't consider the possibility of authenticating in a desktop browser for a headless VM. Thankfully, versions with the previous behavior are still available.

[maru-ava]

2.15.24 has the previous behavior