You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
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 aredirect_uri
which redirects back to127.0.0.1
after flow is successfully completed on the AWS side. For example: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 theredirect_uri
.Use Case
Running
aws sso login
on a remote machine where127.0.0.1
is not accessible for theredirect_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:Other Information
As a workaround currently its possible to switch to use the device auth flow:
although the new authorization flow is a lot more slick as it requires much fewer clicks on the browser.
Acknowledgements
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
The text was updated successfully, but these errors were encountered: