Use OAuth2 Implicit Grant Flow Instead of Authorization Code Grant to Handle Load Balancers
Use OAuth2 Implicit Grant Flow Instead of Authorization Code Grant to Handle Load Balancers

See the reported Issue #197, Connect-Safeguard with 2FA errors with "Code was already redeemed".

When the client requests are made from in front of a load balancer, there is a chance that individual requests may be directed at different nodes by the load balancer.  When using the OAuth2 Authorization Code Grant flow, it requires the client to make multiple requests in order to get, then exchange the authorization code.  Those requests may go to different nodes behind the load balancer, but we do not have a shared cache between the nodes for the authorization code.  (The problem is exacerbated here in the PowerShell script due to the web browser control effectively making one of the web requests, and then the PowerShell script itself making the second request.  An HTTP connection would not be reused between those two.

By changing to use the OAuth2 Implicit Grant flow, we will instead immediately get back an access_token from the web browser login.  Therefore, we shouldn't have any problems in a load balanced environment.

Also, see Issue #173, Enhancement Requests: Connect-Safeguard.  The point number one, "When using GUI Switch still pass through Username field" has also been included in these changes.  (Note that the embedded web browser has a display issue with the placeholder text, but that will be fixed with a later release of Safeguard itself.)

So, for example, you can enter a command like:
`Connect-Safeguard -insecure -gui -verbose 10.5.33.109 local superadmin` and all you will have to enter into the web browser is the password.

OneIdentity/safeguard-ps