¿Cómo evitar mostrar la pantalla de consentimiento en nuestras propias aplicaciones nativas cuando la autenticación externa?

Fondo

Hemos desarrollado una aplicación web con un repos-api utilizando oauth2 / oidc y soporte para aplicaciones de terceros
Hemos desarrollado nuestras propias aplicaciones nativas para android y ios. Actualmente recuperan un token de larga vida del flujo de credenciales del usuario (no se necesita una pantalla de consentimiento).
Actualmente estamos ampliando nuestro flujo de autenticación para aceptar también login externo por google / office365. Esto también se admite especificando el valor de acr en el código de autorización / flujo de oauth implícito.

Problema / problema

Por supuesto, queremos ser capaces de confiar plenamente en nuestra aplicación nativa y no mostrar una pantalla de consentimiento para la mejor experiencia de usuario. Al usar el código de autorización / flujo implícito aunque nada puede ser considerado un secreto y un hacker malintencionado podría potencialmente explotar (sin el conocimiento del usuario) al usuario si no se muestra la pantalla de consentimiento.
¿Cómo podemos evitar tener que mostrar la pantalla de consentimiento para nuestra propia aplicación nativa mientras se sigue seguro de que el usuario es lo más seguro posible?

¿Cómo resolver?

Haciendo una oficina separada365 / google login para recuperar el token de actualización de este idp y luego implementar una forma de autenticarse públicamente usando este token para recuperar un token de larga duración de nuestra aplicación web.
Simplemente ignore la falla de seguridad y nunca pida el consentimiento del usuario dada la combinación no secreta de `clientId / clientSecret / redirectUrl` con la excusa" es muy difícil hackear esto ".
Ignorando la falla de seguridad si el inicio de sesión externo con la excusa "google / office365 debe mostrar una pantalla de consentimiento de todos modos cuando se solicita un token de actualización".
Una forma desconocida de asegurarse de que no es una aplicación / usuario malintencionado

La razón por la que no me gusta (1) es que tanto abre un flujo de autenticación algo nuevo en nuestra aplicación web y fuerza la aplicación nativa para implementar un flujo de autenticación más complejo.

¿Hay algo que me falta aquí, lo que se consideraría la mejor práctica?

El punto es que Google necesita autenticar al usuario fuera de su aplicación para asegurarse de que su aplicación no ve las credenciales del usuario y, por lo tanto, anular el propósito de OAuth.

El usuario también debe permitir que la aplicación evite explícitamente las aplicaciones aleatorias que obtienen fichas del usuario: cualquier persona con una cuenta de Google puede crear un combo client_id / client_secret / redirect_uri . Tu / tu aplicación no es de confianza de Google con tokens para usuarios arbitrarios sin preguntar a esos usuarios primero. Como usted menciona en (1) el usuario sólo tiene que pasar por esto una vez. La aplicación puede recuperar un token de actualización de larga duración y seguir utilizando para actualizar tokens de acceso.

Por lo tanto, la mejor práctica es generar un navegador / webview y manejar el flujo de autenticación / consentimiento allí. No hay manera de evitarlo. Si hubiera una manera sería una vulnerabilidad porque el sistema fue diseñado para evitarlo.

Yo diría algo como nr 2:

Tener una manera de marcar un cliente (identificado por clientId y clientSecret) como de confianza (por ejemplo, con una interfaz de superusuario), y por lo tanto automáticamente dar su consentimiento.

El secreto del cliente debe ser seguro; Si no lo es, tiene otros problemas de seguridad.