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
Is there a reason device code is the only supported flow to get an access token? It should be fairly simple to support other options, either manually through Invoke-OktaApiClient or trivially by using MSAL with WithOidcAuthority($Configuration.BaseUrl).
Would you entertain a PR for this functionality?
The text was updated successfully, but these errors were encountered:
Hey @aseigler Thanks for submitting the PR and we really appreciate that but its just that our criteria for adding support for PKCE and other methods is mainly around maintaining a high level security and just to be transparent, we feel that the Device Code Flow offers the right level of transparency and security for all the use cases.
The reason we only support Device Code is because Device Code is more secure for Remote Access cause you can trust the device of the user and the machine in case of Remote access.
For example - If you are accessing the CLI in your same local machine - PKCE should also be okay (device that you are authenticating from and the device that you are authenticating to) is the same.
But If its Remote - it might be a risk and if the device is compromised, you are bypassing the device assurance and that's the challenge.
Hopefully I am missing something here or misunderstanding what you're trying to describe. The authorization code flow with PKCE is the flow of choice, for example here:
Okta recommends that you use the Authorization Code flow with PKCE for your OAuth client, if possible.
Device code flow has nothing to do with device assurance. In the scenario I think you are trying to describe, where the (safe) client is connecting into a (compromised) remote host via SSH or something, using device code flow would result in the access token being created and available on the compromised host, and that is definitely not something you would want, especially when the access token probably has pretty high elevated permissions given the kind of stuff done with a PowerShell module like this.
Is there a reason device code is the only supported flow to get an access token? It should be fairly simple to support other options, either manually through
Invoke-OktaApiClient
or trivially by using MSAL withWithOidcAuthority($Configuration.BaseUrl)
.Would you entertain a PR for this functionality?
The text was updated successfully, but these errors were encountered: