¿Corregir el método de autenticación usando oAuth 2.0?

Question

¿Corregir el método de autenticación usando oAuth 2.0?

#1 de aviv (0 votos)

1

He intentado envolver mi cabeza en torno a OAuth 2.0, pero me cuesta descubrir la forma correcta de implementarlo para nuestro sistema, ya que hay muchos enfoques diferentes.

Nuestras especificaciones son:

Asegurar una API REST.
Las aplicaciones y sitios web propios se conectan a nuestra API.
Los usuarios acceden a nuestros servicios sin credenciales.
Actualmente, nuestra API es privada, pero posiblemente la haga pública en el futuro.

A partir de la investigación que he realizado, creo que debería estar usando la autenticación oAuth 2.0 (de dos patas) con el tipo de concesión "Credenciales del cliente".

Sin embargo, me preocupa que pueda estar malinterpretando el proceso, ya que parece que con este método todo lo que se requiere es enviarlo a través de ConsumerId y ConsumerSecret. Considerando que, el método OAuth 1.0 requiere un HashKey, ConsumerKey, Nonce, etc.

En resumen, mis preguntas son:

Es el oAuth 2.0 (Two-Legged) usando "Credenciales del cliente" el mejor enfoque que puedo tomar.
Es el flujo de autenticación tan simple como enviar su ClientId y ClientSecret y recuperar su token de portador.

Gracias de antemano

Fuentes que usé para oAuth 2.0 (Two-Legged)

OAuthBible - Explica todos los diferentes enfoques de oAuth

muestra cómo se implementa oAuth (Two-Legged) en 1.0 y 2.0

www.tomdupont.net/2011/03/oauth-1.html

authentication oauth cryptography .net

pregunta Kyle 20.01.2015 - 11:45

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth cryptography .net

¿Qué es el "DBGCMD_LQUERYLV elaborado" en CVE-2014-8904 Vulnerable XSS Test [cerrado]

score 0 · Accepted Answer

Si no está autentificando al usuario, IMHO, no tiene ningún sentido usar oAuth. oAuth es todo para autenticar al usuario y autorizar a una aplicación para hacer cosas en nombre de ese usuario. Si desea autenticar su aplicación con la API, puede usar SSL con la autenticación del cliente, que hará tres cosas: autenticar la API a la aplicación, autenticar la aplicación a la API y cifrar la comunicación entre ellas. SSL con autenticación de cliente requiere que, más allá del servidor que envía su certificado al cliente, también el servidor exija el certificado del cliente y pueda autenticar al cliente.

NOTA: esto es solo en el caso de una aplicación de fondo, como una aplicación web. Si pretende que una aplicación cliente acceda a su API, no tiene forma de mantener su API realmente privada. En ese caso, puede intentar ocultar su API del público mediante algún tipo de token, pero este token tendrá que estar incrustado en su código de cliente que cualquier persona con habilidades básicas de ingeniería inversa podrá extraer y usar.