Sí. El uso del lado del cliente del flujo de código de autorización tendrá casi el mismo efecto que el uso del flujo de concesión implícito.
Habrá algunas solicitudes adicionales, pero el resultado final será el mismo con algunas advertencias:
- La especificación de flujo implícita dice que el token debe estar en el fragmento de la URL para que no salga del agente de usuario. No tendrás esto con el flujo de código
- No debe habilitar
refresh_tokens para el cliente.
También se aplican las mismas preocupaciones de seguridad que para el flujo implícito. Consulte RFC6748 sección 10.16 :
La autenticación de los propietarios de recursos a los clientes está fuera del alcance de esto
especificación. Cualquier especificación que utilice el proceso de autorización.
como una forma de autenticación de usuario final delegada al cliente (por ejemplo,
servicio de inicio de sesión de terceros) NO DEBE utilizar el flujo implícito sin
mecanismos de seguridad adicionales que permitirían al cliente
determinar si el token de acceso se emitió para su uso (por ejemplo, audiencia)
restringiendo el token de acceso).
Y en el frente de credenciales del cliente ya estaba cubierto:
Las aplicaciones nativas que usan el código de autorización otorgan el tipo DEBERÍAN
hacerlo sin usar credenciales de cliente, debido a la nativa
la incapacidad de la aplicación para mantener confidenciales las credenciales del cliente.
Nota al pie : asegúrese de leer RFC6819 sección 4.4.2 para evitar otras dificultades comunes de flujo implícito.