Getting OAuth code challenge on loopback server

I’m implementing the authorization code grant flow for my CLI app with PKCE https://datatracker.ietf.org/doc/html/rfc8252#section-8.1

I started a loop back server from the CLI to wait for the authorization code from my auth server:

$ mytool login
$ please visit: mysitethattalkstomyauthserver.com?local_port=65200
$ … awaiting auth code …

It’s working fine but I’ve a question about the code verifier. I want to have my user just click the above url and have my website handle the initial request for auth code. BUT I need the code verifier hash in the initial request. I should generate that from the client cli tool and not my website.

So do I need to stick that hash in the original url I have the user click?

$ please visit site.com?port=65200&challenge=<hash>

Right now I have an implementation that just has the site call

localhost:65200/code_challenge

And the cli provides the code hash it generated. Is that secure though? To have this extra step of calling my local loop back server to get the code challenge?

Purpose here was to keep the url for user to click on as simple and readable as possible

A CLI client must run its own HTTP server and operate like this.

• Create a code verifier and store it in memory
• Run a local HTTP server, eg at http:/127.0.0.1:3000
• Open the system browser at the authorization request URL, including the code challenge
• Receive an authorization response URL in the local HTTP server containing the authorization code
• Send the authorization code grant request, with the code verifier, to the authorization server's token endpoint

You should not try to involve a web server since your CLI will not be able to receive the response URL. The local HTTP server is spun up in your CLI's technology atack, eg Node.js can use its built in HTTP server.

Note also (from your comment) that you cannot use PAR for a CLI client, which is a public client that cannot safely supply the client credential that PAR requires.