Several OAuth2 ecosystems (the largest of which is likely the UK OpenBanking ecosystem) have recently started using a process known as 'app2app' to do OAuth2 authorization.
This allows a better user experience on mobile (iOS/Android devices) as user authorization/consent can be done in the user’s existing first party app and can leverage biometrics and other methods that may not be possible or as easy in a web based experience.
It is very similar to the ‘Claimed "https" Scheme URI Redirection’ mechanism applied to the client’s redirect uri in the IETF ‘OAuth 2.0 for Native Apps’ BCP (now colloquially known as ‘app2web’), but instead applied to the authorization server’s authorization endpoint.
One way of viewing this is that a first party native app becomes the ‘user-agent’ referred to in RFC6749.
Similar to the existing BCP, it gracefully degrades into ‘app2web’ and ‘web2app’ variants.
The expanded remit, and some related issues it brings (in particular there has been a trend of authorization servers publishing alternative authorizations endpoints via out-of-band mechanisms) are worthy of further examination.
It may need additional guidance for authorization server vendors on providing secure APIs to allow native apps to process authorization requests and creating the authorization endpoint response ready to return to the OAuth2 client. To some extent these APIs might look very similar to the existing authorization endpoints or endpoints that the AS exposes to the webapp it provides on the authorization endpoint.