2012-08-28 20 views
11

Tengo una aplicación que ofrece una API. Esta aplicación es un proveedor de OAuth2.¿Cuál es el propósito del secreto del cliente en OAuth2?

Quiero acceder a esta API (leer & escribir) con una aplicación del lado del cliente. Estoy usando JSO para hacer esto más fácil.

Funciona muy bien.

Lo que pasa es que no tengo que ingresar el secreto de mi cliente (de la aplicación que registré en mi aplicación) en ningún lado. Y entiendo por qué, entonces estaría disponible para cualquiera.

Entonces, si puedo acceder a mi API sin el secreto del cliente, ¿podría explicarme cuál es su propósito?

+0

Ver también [¿Cuál es el punto del secreto del cliente en OAuth2 si no necesita ser utilizado?] (Https://security.stackexchange.com/questions/76351/whats-the-point-of -el-cliente-secreto-en-oauth2-si-no-necesita-ser-ser-usado) – user

Respuesta

6

Client Secret se usó en OAuth 1.0 para firmar la solicitud, por lo que era obligatorio. Algunos servidores OAuth2 (como Google Web Server API) requieren que se envíe el secreto del cliente para recibir el token de acceso (ya sea desde token de solicitud o token de actualización).

OAuth 2.0 ha reducido significativamente la función del secreto del cliente, pero aún se transfiere a los servidores que lo utilizan.

+0

Ok, ¿entonces no pasarlo no es un problema de seguridad? – Robin

+0

Mientras el servidor OAuth con el que está hablando no lo necesite, no se preocupe. –

+0

El caso es que el servidor de OAuth es mío, por lo que siempre hay la posibilidad de que haya cometido un error ^^. Pero dado que estoy usando el portero, que parece ser una buena joya, no me preocuparé por eso. Todavía me gustaría entender un poco mejor por qué ya no se usa, pero aún está presente ... – Robin

-3

Esto también me estaba volviendo loco hasta que vi un ejemplo que hacía la respuesta cegadoramente obvia.

Tengo que iniciar sesión en El servidor antes de que El servidor devuelva un token que otorgue acceso a Mis cosas.

En otras palabras, El Servidor me presentará, el ser humano, con una pantalla de inicio de sesión si aún no tengo una sesión de inicio de sesión válida con El Servidor. Esta es la razón por la cual las explicaciones siempre dicen algo como "depende del servidor autenticarse".

Claro, El servidor no tiene que requerir que esté conectado. ¿Es esto realista? ¿Dropbox realmente le otorgará acceso a Mis archivos a cualquier persona sin un inicio de sesión? Por supuesto no. La mayoría de las explicaciones que he leído tienen más brillo sobre este punto como si no importara, cuando es prácticamente lo único que importa.

+2

Creo que estás confundiendo el client_secret y un código de autenticación. El último se devuelve después de que el usuario otorga el permiso (sin embargo, eso se implementa). Luego se usa para solicitar un access_token. – AaronHS

8

This discussion proporciona una excelente explicación de por qué el secreto del cliente es mucho más importante para las aplicaciones del lado del servidor que para las aplicaciones del lado del cliente. Un extracto:

Las aplicaciones web [aplicaciones del lado del servidor] utilizan los secretos de los clientes porque representan enormes vectores de ataque. Digamos que alguien envenena una entrada de DNS y configura una aplicación deshonesta "similar", el yuxtaposición podría no ser notado por meses, con este intermediario absorbiendo toneladas de datos. Se supone que los secretos de los clientes mitigan este vector de ataque. Para clientes de usuario único, el compromiso debe venir de a un dispositivo a la vez, lo cual es terriblemente ineficiente en comparación.

Cuestiones relacionadas