Perform auth flow in the terminal

[monde]

The device authorization and subsequent user authentication for Okta takes place in a traditional web browser. Implement the same flow with ncurses forms in the terminal. Something like this:

Step 1 - Device Auth

Web:

Terminal:

|------------------------------|
| Okta                         |
| Activate your device         |
| Activation Code : █          |
|______________________________|

Step 2 - User name

Web:

Terminal:

|------------------------------|
| Okta                         |
| Sign in                      |
| Username: █                  |
| [Next]                       |
|______________________________|

... And so on - continue rendering the rest of the MFA flows

[cvchavez2]

This would be really good to have :)

[roca]

This would be a more elegant solution.

[tarfeef101]

It would be even better to have this tool accept arguments to provide credentials for those using password managers for a more seamless workflow. This is possible with saml2aws and is a major draw of that, for me.

[tarfeef101]

so... been a hot minute... does okta have any desire to support terminal users? (e.g. I run chromeos and run commands from the linux environment, totally headless/without a GUI installed. I imagine there are many other users who do the same, or perhaps run WSL on windows, or run on remote instances via ssh, etc.

this is a pretty basic feature, be it done by:

• what OP suggested (seems unnecessarily interactive to me)
• CLI args

[monde]

We won't be spending any effort on a TUI browser to do OIE browser flows. I'm not even sure there is any TUI browser package good enough that OIE device auth flow would even work wtih it.

[tarfeef101]

We won't be spending any effort on a TUI browser to do OIE browser flows. Even sure there is any TUI browser package good enough that OIE device auth flow would even work wtih.

would you accept "just having CLI args to accept the values" instead? that should be way simpler (and is preferable for many who automate their workflows)

[monde]

@tarfeef101 username / password authentication is a no-op at Okta in OIE orgs. That will never change.

For the true machine to machine use case we've exposed a pure OIDC solution using a private key https://github.com/okta/okta-aws-cli?tab=readme-ov-file#m2m-command .

For the human use case we have device authorization which requires the human to interact with a web browser. It starts with a device authorization request from where ever the command is run. Then the human is prompted to go through their authorization flow in a browser at Okta. Between the various MFA policies a user has to go through in the browser, Okta's inspection of the browser session itself (a browser that has javascript enabled), and the original device authorization is how Okta has a high degree of confidence the access request is valid before going to AWS to gather temporary IAM credentials.

[monde]

TUI lynx doesn't support javascript and TUI browsh doesn't appear to work either.

[tarfeef101]

Not all human machines have browsers but 🤷‍♀️ that's not the battle I'm here to fight

MFA policies could still be enforced via cli. You have full control over your own application to provide whatever guarantees you wish to ensure the request is genuine.

In the end, when I have to exit my terminal and open a link in my browser instead, I'm still inputting a username, password, and totp just like I would if I did that in the terminal. It just takes longer and requires more software to be present on the system.

[monde]

That's good feedback @tarfeef101 , I completely understand the issue here and how it doesn't benefit the work flow you experienced on an Okta classic org. I encourage you to open a support ticket with Okta for this use case. okta-aws-cli doesn't control any of this, it is just a down stream tool from the Okta Management API where OIE device authorization flow is enforced.

In the semi-headless use case - if you do have access to the terminal where the okta-aws-cli is running you can try out the --qr-code feature which will print out a text QR code you can open on a handset that has a camera that can read QR codes and do your Okta login on your handset.

[tarfeef101]

I just looked up device authorization

It seems like it isn't a policy to be enforced, but a feature okta created to support login on devices without traditional input methods? I feel like okta-aws-cli could just not use that feature entirely and that would be fine. For example, saml2aws works well (though i think a change my org made recently broke compatibility, this is not a fundamental limitation of the tool to work with any OIE org), and allows users to submit credentials since they DO have functioning input methods on the cli. Not sure what makes such workflows impossible here except a desire to not do that.

Yeah thankfully my workflow isn't so constrained I have to use a QR code every day i log in, that would be terrible. I run my dev env in containers in VMs, usually, but the host can still open browser links. It's just "not as efficient" as aliasing a command to pipe in credentials from password managers, hardware 2fa devices, etc and auth-ing in one go. And won't work if your host system is headless as well.

[monde]

The web subcommand, the original feature of okta-aws-cli (not m2m which is pure OIDC) is under pinned by an Okta AWS Federation app. The AWS Fed app is the part of the Okta core that does the API calls to AWS to set up an Assume Role With SAML. Within the AWS Fed App is the "web sso" feature that enforces the device authorization. Device authorization is fundamental to the AWS Fed app in an OIE org, the AWS Fed app will not generate a SAML assertion for AWS without device authorization, there is no way to side step this. okta-aws-cli is down stream of the Okta Management API, it has no control over how device authorization is enforced within the Okta core, okta-aws-cli just abides by what is available to it via API calls.

[tarfeef101]

The web subcommand, the original feature of okta-aws-cli (not m2m which is pure OIDC) is under pinned by an Okta AWS Federation app. The AWS Fed app is the part of the Okta core that does the API calls to AWS to set up an Assume Role With SAML. Within the AWS Fed App is the "web sso" feature that enforces the device authorization. Device authorization is fundamental to the AWS Fed app in an OIE org, the AWS Fed app will not generate a SAML assertion for AWS without device authorization, there is no way to side step this. okta-aws-cli is down stream of the Okta Management API, it has no control over how device authorization is enforced within the Okta core, okta-aws-cli just abides by what is available to it via API calls.

you definitely CAN get AWS SAML sessions without device authorization, though. That's the "primary workflow", signing in to okta in your browser and using an okta tile to get into the console. This works perfectly well (and uses a username+password+some 2fa, usually), and is not device authorization (there is no secondary device needed, as one's PC is generally not input constrained)

Using device authorization here was a conscious choice, not a requirement for cli auth to function. One could submit credentials the same way a browser session does (or that saml2aws does, for that matter), and there's nothing preventing that other than design choices.