oauth-2.0 - redirect_uri_mismatch - oauth2 token

Autenticación del cliente en público cliente

Question

Estudiando OAuth2.0 finalmente encontré estos 2 refs:

http://tools.ietf.org/html/rfc6749#section-2.3

http://tools.ietf.org/html/rfc6749#section-10.1

Corrígeme si me equivoco:

Es posible utilizar clientes no registrados, pero usted debe administrarlos usted mismo con riesgos de seguridad.

• ¿Cómo debo gestionarlos?

Algunas preguntas más específicas:

1. Una aplicación nativa (un cliente público de hecho) no puede, por definición, almacenar sus credenciales (client_id + secret). ¿Es un cliente no registrado ? Si no puedo verificar / autenticarlo usando un secreto, ¿qué más debo hacer?
2. registro del cliente = / = registro de punto final: el primero es sobre el registro de las credenciales del cliente ( client_id + secret ); el segundo sobre el registro de puntos finales de redirección de clientes . ¿Es el registro del punto final de redirección suficiente para otorgar la autenticidad del cliente?
3. ¿ La concesión de credenciales del cliente utiliza las mismas credenciales ( client_id + secret ) para el registro del cliente?

Creo que podría responderme simplemente explicando el wat correcto en este párrafo http://tools.ietf.org/html/rfc6749#section-10.1

Por favor reporte referencias y ejemplos prácticos sobre cómo implementar:

[...] está más allá del alcance de esta especificación.

Gracias

Answer 1

tl; dr:

1. Los clientes nativos no se pueden autenticar con client_id y client_secret . Si necesita autenticar al cliente, deberá implementar un esquema de autenticación que no confíe el secreto compartido al cliente (o que involucre al usuario final en la discusión sobre la autenticación del cliente). Dependiendo del modelo de seguridad de su aplicación, es posible que no necesite autenticar al cliente.
2. El punto final de la redirección generalmente no es suficiente para autenticar al cliente (aunque existen excepciones ).
3. El tipo de concesión "credencial de cliente" puede usar cualquier mecanismo de autenticación de cliente admitido por el servidor de autorización, incluidas las credenciales entregadas en el registro del cliente.

Lo esencial, según lo leí, es que puede confiar en el client_id un cliente confidencial (lea: "nombre de usuario") y client_secret (lea: "contraseña") para autenticarlos con su servicio. No hay ninguna posibilidad de que una aplicación de terceros se represente a sí misma con las credenciales de ese cliente, porque se supone razonablemente que están almacenados de forma segura lejos de miradas indiscretas.

Sin embargo, un cliente público no puede ofrecer dicha garantía, ya sea que una aplicación basada en navegador o una aplicación de escritorio nativa, la identificación y el secreto del cliente se distribuyan al mundo en general. Es bastante razonable suponer que tales aplicaciones terminarán en manos de desarrolladores y piratas informáticos capacitados que pueden profundizar en el cliente y extraer el ID y el secreto. Por esta razón, la Sección 10.1 establece explícitamente que:

The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication.

Bueno. Así que los clientes públicos no pueden ser autenticados por contraseña. Sin embargo…

The authorization server MAY issue a client password or other
credentials for a specific installation of a native application
client on a specific device.

Esta excepción funciona porque vincula la autenticación del cliente a un dispositivo específico, lo que significa que incluso si alguien se alejó con el secreto del cliente, no podría reutilizarlo. Sin embargo, está implícito en esta excepción que la "instalación específica ... en un dispositivo específico" debe ser identificable de manera única, difícil de falsificar e integral al proceso de autenticación para ese cliente.

No todas las aplicaciones nativas pueden cumplir con esos criterios, y una aplicación basada en navegador ciertamente no puede, ya que no hay nada singularmente identificable o difícil de falsificar en el entorno en el que se ejecuta. Esto lleva a un par de opciones: puede tratar al cliente como no autenticado, o puede crear un mecanismo de autenticación más apropiado.

La clave para el baile de autenticación es un secreto compartido, algo que solo conocen el servidor de autorización y el cliente de autenticación. Para los clientes públicos, nada en el propio cliente es secreto. Afortunadamente, hay opciones, y no solo estoy hablando de llaveros RFID y biométricos (aunque serían completamente aceptables).

Como un experimento mental, consideremos un cliente basado en navegador. Podemos asumir razonablemente algunas cosas al respecto: se ejecuta en un navegador, se sirve desde un dominio en particular y ese dominio está controlado por los autores del cliente. El servidor de autenticación ya debe tener un URI de redirección de clientes, por lo que tenemos algo allí, pero como lo especifica la especificación:

A valid redirection URI is not sufficient to verify the client''s
identity when asking for resource owner authorization but can be
used to prevent delivering credentials to a counterfeit client
after obtaining resource owner authorization.

Por lo tanto, la URI de redirección es algo que deberíamos verificar , pero no es algo en lo que podamos confiar , en gran parte porque el dominio podría ser falsificado. Pero el servidor en sí no puede ser, por lo que podríamos intentar pedirle al dominio algo que solo el servidor del dominio del cliente sabría. La forma más sencilla de hacer esto sería que el servidor de autenticación requiera un segundo URI ("privado"), en el mismo dominio que el cliente, donde se alojará el secreto del cliente. Cuando la aplicación del cliente realiza una solicitud de autorización, el servidor luego se "compara" con el segundo URI relacionado con el nombre de host informado del cliente , y busca el secreto compartido (que solo debe revelarse a la dirección IP del servidor de autorización) para autenticar la cliente.

Por supuesto, esta no es una solución perfecta. No funciona para todas las aplicaciones, es fácil equivocarse y es potencialmente mucho trabajo implementar. Muchos posibles mecanismos de autenticación (tanto altamente específicos como altamente generales) existen, y cualquiera que no confíe la aplicación del cliente con datos privados sería adecuado para este espacio problemático.

La otra opción que tenemos es implementar ninguna autenticación adicional y tratar al cliente como no autenticado. Esto no es lo mismo que un cliente no registrado, pero la diferencia es sutil. Un cliente no registrado es un cliente cuya identidad es desconocida . Un cliente no autenticado es un cliente cuya identidad es conocida, pero no confiable . La implicación de seguridad para ambos tipos de clientes es la misma: a ninguno se le deben confiar datos privados. Si el servidor de autorizaciones decide tratar estos dos casos de la misma manera, sin embargo, parece que queda en manos del implementador. Puede tener sentido, por ejemplo, que una API rechace todas las conexiones de un cliente no registrado y sirva contenido público de solo lectura a cualquier cliente registrado (incluso sin verificar la identidad del cliente).

Sin embargo, el pragmatismo aún puede ganar: un cliente no autenticado no es básicamente diferente de los "errores" de SSL que verá ocasionalmente cuando su navegador no puede verificar la autenticidad del certificado SSL del sitio. Los navegadores inmediatamente se negarán a seguir adelante e informarán exactamente por qué , pero los usuarios pueden aceptar el riesgo por sí mismos mediante la garantía de la identidad del servidor. Un flujo de trabajo similar puede tener sentido para muchas aplicaciones OAuth2.

¿Por qué es importante verificar la identidad del cliente, de todos modos? Sin hacerlo, la cadena de confianza se rompe. Los usuarios de su aplicación confían en su aplicación . El flujo de trabajo de autorización establece que sus usuarios también confían en el cliente , por lo que su aplicación debe confiar en el cliente. Sin validar la identidad del cliente, otro cliente puede venir y asumir la función del cliente de confianza, con todos los derechos de seguridad de los mismos. Todo lo relacionado con la autenticación del cliente sirve para evitar ese abuso de confianza.

Espero que esto haya ayudado!

[1]: Los compromisos del servidor, donde el código fuente de su aplicación cae en manos malintencionadas, son una excepción a esto, y existen otras garantías integradas para ese caso. Dicho esto, la especificación también señala específicamente que una combinación simple de nombre de usuario y contraseña no es la opción más segura:

The authorization server is encouraged to consider stronger
authentication means than a client password.