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.

[ssandler-cat]

@zeroimpl, I also had a similar issue. The following is a workaround to enable the redirect with Docker Desktop for Windows docker run --net=host --rm -it --expose=2000-5000 -P [yourImage] bash providing Docker Desktop -> Resources -> Network -> Enable host networking is on (to facilitate --net=host).

[mwilkinson01]

@miki725 I have a similar use case where I'm initiating the command from the remote machine. When I paste the URL into my browser and when it gets to the call back step, which fails, I change the IP from 127.0.0.1 to the IP of my machine which I ran the command from to complete the signing process. I've been having to do that since the change. It would be a great update to allow to set the redirect in the generated URL.

Alternatively you can use the --use-device-code argument to go back to using the Device Code authorization like it was doing before this change occurred. It's at least a fallback till hopefully they add a way to configure the redirect for the current authorization flow.

[jrupp]

I'm having this problem when running in a GitHub Codespace. The redirect url has 127.0.01, but it needs to have the URL of the codespace's forwarded port. This used to work too.

[drottsgard]

I also use a ssh remote machine that I trust & I agree that it would be nice with a flow similar to what the proposed solution suggests.

Another thought is to have a static PORT that could be overridden by e.g. --port flag. Then use port-forwarding over SSH. Is this a idea option due to security?

[LaurinHerbsthofer]

Alternatively you can use the --use-device-code argument to go back to using the Device Code authorization like it was doing before this change occurred. It's at least a fallback till hopefully they add a way to configure the redirect for the current authorization flow.

Thanks , --use-device-code did the trick for me.