I’m just worried that by adding the redirect under web, it’s not actually going to use the Auth code flow like they suggest for SPAs. I’ll test it out both ways when I get the chance though.
Redirecting to the login server action script makes sense though.
Well at least we’re getting errors now… {"status":"500","message":"Http status code 404. ","stack":"Error: Http status code 404. \n at IncomingMessage.<anonymous> (/opt/node_app/lib/oauth/index.js:95:39)\n at IncomingMessage.emit (events.js:327:22)\n at endReadableNT (internal/streams/readable.js:1327:12)\n at processTicksAndRejections (internal/process/task_queues.js:80:21)"}
hmm, ok, but yes we are looking like we are getting somewhere, all the auths must be working or it would not be running the redirect part, so something else is strange there, will have to have a think about it, maybe that is a bug for @patrick, not sure, because now it all looks good to me.
How far do you get in the oauth flow, did it redirect you to the microsoft page or do you get the error directly on your own website? There are multiple redirects, so the url changes each time. When you open /api/oauth_login on your website it will redirect you to the microsoft website, there you login and then there are again some redirects and it should finally return back to your own website again.
If I see your error then it looks like the token endpoint is not correct.
It did the Microsoft part first, then when it began redirecting to the site the error came up.
Before this if you read above we have 100 posts of failures, eventually what got us to this point was changing the callback URL on Microsoft to SPA URI https://www.mydomain.com/api/the_script and also altering the redirect_uri in the params of the Authorise step to the same path as above.
Finally it got the code, and starting redirecting, instead of an instant error like we were getting before, and on redirect back to the site the error came up.
The document doesn’t say what the default for response_mode is, I would advice setting that to query.
You don’t have to set the redirect_uri parameter, our server action does that for you. The only extra parameters would be code_challenge and code_challenge_method.
I think that I found an issue with the flow that you probably will encounter. You use PKCE with the code_challenge and in the token request it requires code_verifier parameter which is missing in our code. Not sure if it would work if you pass that also as parameter to the autorize action step, otherwise you probably have to update our oauth code.
Thanks Patrick, sounds complicated, lol, when I play with Wappler internal code, bad things normally happen, but if it does not work i will attempt it, haha. Get ready to see some of your automated crash reports coming through after my edits.
Do you really need the code_challenge in your flow? I can help with the editing when it is needed to change our code, I know where it is doing the specific call.
@patrick, How do you suggest I set up my parameters in the Provider, Authorize step, and the graph api call? Also, do I need to have $_GET variables? And lastly, do I need to redirect to a page, or the server action?
I need the code challenge if I have the application registered in Azure as a single page application (which it is), or it will give me the following error: AADSTS9002325: Proof Key for Code Exchange is required for cross-origin authorization code redemption. If I have it registered under web, I do not need the code_challenge, but I’m not sure if it follows the auth code flow and if it compromises security in any way.