@JesperSchulz I see an internal work item was added. Am I good to proceed on this then?

@mjmatthiesen, sorry, I was out for a while and am trying to catch up on everything here on GitHub 😊
I will approve this one. Sounds fair to me!

@JesperSchulz Not to worry. I just didn't want to spend time on it if it didn't have a chance of merging, because my solution was only theoretical.

Turns out the theory was not entirely sound. After doing some initial work, I realize that I misunderstood what the OAuth2 module is actually capable of. I had made the assumption that it is able to handle oauth for any standard compliant interface. As in the user has a login, authorizes our app on that service, and then gets a refresh and access token that BC stores and we can request for an API call. Adding the audience I can do the login process, but I cannot get the tokens. I understand now that it's out of scope of this codeunit.

I do believe I can leverage the login and callback process to get my auth code and then handle retrieval of tokens myself, but that will require some additional testing from me. Even just that part would greatly simplify it for us.

I did some research and see now that it is structured to always go to login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=$ where the auth endpoint is an edited version of my original auth endpoint. In my case specifically it goes from

https://BASEURL/authorize/
https://BASEURL/authorize/oauth2/v2.0/authorize

or without the trailing slash it becomes

https://BASEURL/authorize
https://BASEURL/common/oauth2/v2.0/authorize

I guess really the question is if it is out of scope to do something more generic, i.e. use the returned auth code to get the access and refresh token, but maybe that is something MS is already planning for.

Let's get some of our security experts on this case. I've pinged them in the linked PR.