¿Por qué no se recomienda PKCE para las aplicaciones de una sola página?

13

Muchos servicios hoy en día aún recomiendan el flujo implícito para un intercambio de token OpenID Connect / Oauth2 al desarrollar aplicaciones de una sola página. (Consulte Okta , Google , Auth0 )

Algunas orientación más reciente apuntan hacia el uso del Flujo de código de autorización sin un client_secret in El paso de intercambio de tokens, que estoy de acuerdo, tiene sentido por los motivos citados en el artículo (por ejemplo, los tokens no se encuentran en el historial del navegador, registros web , etc.). ¿Por qué este concepto no va más allá con PKCE? En lugar de omitir completamente el client_secret, ¿por qué no utilizar uno dinámico como se recomienda para aplicaciones nativas? Las SPA y las aplicaciones nativas se consideran "clientes públicos" donde un secreto no se puede guardar de forma segura, pero solo las aplicaciones nativas obtienen la recomendación PKCE mientras que las SPA parecen mantenerse en el pasado.

Entiendo que las implicaciones de seguridad que PKCE está tratando de resolver no se relacionan directamente con el contexto de un solo navegador, pero ¿no podría ser visto como un mecanismo de defensa en profundidad y utilizado de todos modos? Sé por experiencia que Google no le permitirá generar una Credencial de Aplicación Web y tratar de usar otra cosa que no sea implícita para un SPA (vea este problema ), el flujo del Código de Autorización esperará un cliente_secret y el intercambio de PKCE solo funciona si elige un tipo de credencial de aplicación nativa pero no puede especificar https redirect_uri para su aplicación.

Otros proveedores permiten PKCE con flujo de código de autorización en un contexto web, pero no se recomienda de ellos. ¿Me equivoco al querer esto y utilizarlo? Parece bastante trivial agregar los pasos adicionales para generar y pasar los desafíos del código con API de criptografía web disponible ( segmentación nuevos navegadores y shimming según sea necesario).

    
pregunta someone1 03.04.2018 - 21:56
fuente

1 respuesta

2

Las SPA no se beneficiarían de PKCE. PKCE resuelve un problema diferente al que estás describiendo.

En primer lugar, para SPAs la mejor práctica actual es utilizar el flujo implícito , no el flujo del código de autorización. Con el En el flujo implícito, el token de acceso se incluye en el fragmento de hash (#) del URI de redireccionamiento en lugar de en un componente de consulta (?). Como el navegador nunca incluye la parte del fragmento de hash de un URI cuando realiza una solicitud, el token no aparece en historial del navegador , los registros web ...

Cuando se trata de aplicaciones nativas , rfc8252 sección 6 dice que siguiente:

  

Los clientes de aplicaciones nativas públicas DEBEN implementar la clave de prueba para el intercambio de código (PKCE RFC7636])

En una nota al margen, observe que el requisito de PKCE es para clientes nativos públicos . Quizás se esté preguntando cómo puede ser posible que una aplicación nativa no sea pública. La respuesta se encuentra en sección 8.4 :

  

Excepto cuando se utiliza un mecanismo como el Registro dinámico de clientes [RFC7591] para proporcionar secretos por instancia, las aplicaciones nativas se clasifican como clientes públicos

No estoy exactamente seguro de cómo referirme a estos clientes ya que nunca he visto a cliente nativo confidencial mencionado en ninguna parte. Tal vez cliente nativo no público funcione :)

Para responder a su pregunta: ¿por qué se requiere el flujo de código de autorización con PKCE para las aplicaciones públicas nativas y no para las SPA?

La lógica es la siguiente:

  1. Uno de los propósitos principales de OAuth2 es evitar la exposición de las credenciales de los usuarios a los clientes.
  2. Para que las aplicaciones nativas cumplan con este requisito, el usuario no debe ingresar credenciales en ningún lugar al que tenga acceso la aplicación nativa. Por lo tanto, se deben evitar las pantallas de inicio de sesión nativas y las vistas web.
  3. La solución es que las aplicaciones nativas inicien un agente de usuario externo (consulte rfc8252 apéndice B ) donde el usuario se autentificará con el servidor de autorización y autorizará la aplicación. Las aplicaciones nativas no tienen acceso al agente de usuario externo, por lo que las credenciales del usuario son seguras.
  4. Sin embargo, se ha introducido una nueva complicación que no existía con las SPA: ¿el agente de usuario externo ahora debe comunicar la respuesta del servidor de autorización a la aplicación nativa? La respuesta es la comunicación entre aplicaciones (consulte sección 5 y section 7 )
  5. Desafortunadamente, varios tipos de comunicación entre aplicaciones pueden ser interceptados por aplicaciones de terceros maliciosos. Con el flujo implícito, esto significa que el token de acceso podría ser robado por una aplicación maliciosa, lo que sería algo muy malo. Esta es una de las razones principales por las que el flujo implícito no se usa para aplicaciones nativas.
  6. Pero incluso si en su lugar se usa el flujo de código de autorización, la aplicación de terceros maliciosos todavía puede interceptar el código de autorización y usarlo para obtener un token de acceso, ya que no hay un secreto de cliente. Por lo tanto, parece inútil utilizar el flujo de código de autorización en lugar del flujo implícito para aplicaciones públicas nativas.
  7. Aquí es donde PKCE entra. PKCE hace que, incluso si una aplicación maliciosa intercepta un código de autorización, no podrá intercambiarlo por un token de acceso. Esto se logra al requerir que la entidad que solicita el token de acceso demuestre que es la misma entidad que solicitó el código de autorización en primer lugar.

Esperemos que ahora entiendas por qué:

  • Las SPA no se beneficiarían de PKCE ya que con las SPA todo ocurre dentro del navegador. PKCE solo es útil cuando hay comunicación entre aplicaciones.
  • Las aplicaciones nativas públicas no deben usar el flujo implícito porque la comunicación entre aplicaciones a veces puede ser insegura.
  • Las aplicaciones nativas públicas deben usar el flujo de código de autorización + PKCE

Aquí hay una buena publicación de blog que puede proporcionar más información: enlace

    
respondido por el catanman 09.06.2018 - 10:30
fuente

Lea otras preguntas en las etiquetas