Hello again 🙂
I´ve had a look at your app but I have some trouble understanding the use case. When you call an external API from r3, you would usually authenticate against that API first (username+password) and then get a token back for further calls. With this token, the external system can authorize the calls. If you want to make sure that the calls come from a specific r3 system, you could use credentials for the REST call that only this r3 system has.
What I am unsure about: If the external API can already confirm that the call comes from an authorized r3 system, why is the token, which your app confirms, relevant? It makes sense to me, if the confirmation is not about the r3 system (which is already authorized), but about something inside the system (maybe to confirm that calls come from specific users inside the r3 system?).
Regarding your question:
OAuth2.0 is a big standard with many implementations. We are currently implementing the option to register OAuth 2.0 clients in r3 (variant: client credential grant flow). These clients could be used for many purposes, but for 3.7 we plan to offer them only as option for mail authentication (via XOAUTH2 for SMTP/IMAP access).
For your purpose, if we add an option to use OAuth2 clients in REST calls, the OAuth2 authentication (via the grant flow that we plan to implement), would authenticate the r3 system against your identity provider. But the authentication itself would only tell you that a specific r3 system is executing the call - basically the same as a regular REST call with user/password + bearer token would do (if your r3 system is using unique credentials). So not really very useful, unless I misunderstand the problem you are trying to solve.