api - implementar - oauth2 token
Asegurando mi API REST con OAuth mientras sigo permitiendo la autenticación a través de proveedores externos de OAuth(usando DotNetOpenAuth) (2)
Tengo un producto con una API REST sencilla para que los usuarios del producto puedan integrarse directamente con las características del producto sin utilizar la interfaz de usuario web.
Recientemente, he recibido interés de varios terceros sobre la integración de sus clientes de escritorio con la API para permitir que los usuarios de mi producto accedan a sus datos utilizando esa aplicación de terceros.
He visto que las aplicaciones que desean usar Twitter se autentican usando una página de inicio de sesión alojada por Twitter que concede a una aplicación específica permiso para acceder a los datos de ese usuario. Hace clic en el botón "Permitir" o "Denegar" y el proceso de autenticación se completa. Facebook usa el mismo mecanismo que mejor puedo decir.
Tras futuras investigaciones, esto parece ser OAuth en acción, y dado que mi API está basada en .Net, creo que debería usar DotNetOpenAuth y proporcionar un mecanismo similar. Lamentablemente, las muestras están escasamente documentadas (si acaso) y los únicos tutoriales que puedo encontrar en línea parecen estar enfocados en ayudarlo a proporcionar un mecanismo de inicio de sesión para sus usuarios, de modo que puedan iniciar sesión en su sitio web utilizando un proveedor externo.
Lo que realmente me gustaría hacer es hacer que mi API REST maneje toda la autenticación básica y la lógica de negocios para mi aplicación web y, bajo el capó, mi aplicación web es esencialmente otra aplicación que solo usa la API a través de OAuth. Los usuarios se autenticaban en el sitio web directamente usando su nombre de usuario y contraseña, o a través de un proveedor externo como MyOpenID o Facebook y luego el sitio web de alguna manera usaría el token devuelto para autenticarse contra la API REST.
Básicamente parece que necesito que mi API aloje de alguna manera un servicio de OAuth, pero también que los usuarios usen un servicio de OAuth de terceros. No puedo evitar pensar que no tengo suficiente comprensión de OAuth para decidir si estoy complicando demasiado las cosas o si lo que intento hacer es una buena o mala manera de hacer las cosas.
¿Alguien puede darme, al menos, una visión general de los pasos que debo seguir o qué debo considerar para que esto suceda? ¿O apuntarme a algunos tutoriales? ¿O arruinar mi propuesta y decirme que estoy hablando de esto (arquitectónicamente) todo mal?
Ante todo. Necesita separar mentalmente cuál es su API: desde métodos de autenticación.
Su API es básicamente recursos y métodos para manipular esos recursos. Y puede tener varios métodos para autenticar el acceso a su API.
OAuth es uno de esos mecanismos de autenticación. Ser un proveedor de OAuth es excelente, aunque la especificación es un poco difícil de comprender, especialmente las partes que tienen que ver con las firmas. Una vez que tiene OAuth en su lugar, las aplicaciones de los clientes generalmente se autentican con facilidad, ya que hay tantas bibliotecas de "código abierto, ya hechas, solo implementadas" disponibles en la mayoría de los idiomas.
Los pros y los contras de OAuth se han debatido por un tiempo. Pero para formarte tu propia opinión, sugiero leer esta guía definitiva, escrita por Eran Hammer-Lahav , una de las personas responsables de la especificación OAuth.
Las únicas alternativas reales a OAuth hasta donde yo lo veo, son OAuth 2.0 y solo autenticación básica simple.
Aparte de eso, estás hablando de autenticar usando Open-ID o facebook identity, etc. Esta es otra pregunta que debes hacerte a ti mismo. Pero realmente queda fuera del alcance de las API y OAuth. Para mí, eso se trata más de una cuestión de creación de usuarios en su servicio. Puedo estar equivocado.
Primero, me gustaría enfatizar la diferencia entre autenticación y autorización:
Un usuario se autentica en su sitio web mediante el suministro de alguna credencial, como un nombre de usuario + contraseña. OpenID permite que esto se desplace al hacer que el usuario se autentique en otro servicio, que luego confirma la identidad del usuario en su sitio web en nombre del usuario. Su sitio confía en el servicio de terceros (el proveedor de OpenID) y, por lo tanto, considera que el usuario ha iniciado sesión.
Un servicio o aplicación no se autentica en su sitio web, al menos no de forma típica. Un usuario autoriza a un servicio o aplicación para acceder a los datos del usuario. Esto normalmente lo hace la aplicación que solicita la autorización del proveedor del servicio, luego envía al usuario al proveedor del servicio, donde el usuario se autentica primero (para que el proveedor de servicios sepa con quién está hablando) y luego el usuario le dice al sitio "sí, está bien que [aplicación] acceda a mis datos [de alguna manera restringida] ". A partir de ese momento, la aplicación utiliza un token de autorización para acceder a los datos del usuario en el sitio del proveedor del servicio. Tenga en cuenta que la aplicación no se autentica como si fuera el usuario, pero utiliza otro código para garantizar que el servicio esté autorizado para acceder a los datos de un usuario en particular.
Entonces, con esa distinción aclarada, puede tomar decisiones en su sitio sobre autenticación y autorización de forma completamente independiente. Por ejemplo, si desea que sus usuarios puedan iniciar sesión con todo: nombre de usuario + contraseña, OpenID y Facebook, puede hacerlo. Una decisión completamente ortogonal es cómo autorizar las aplicaciones (hay muchos protocolos que puede usar para esto, por supuesto, OAuth es bastante popular).
OpenID se centra en la autenticación de usuarios. OAuth se centra en la autorización de la aplicación. Sin embargo, algunos servicios como Facebook y Twitter han elegido usar OAuth para la autenticación y autorización en lugar de utilizar OpenID para la autenticación y OAuth para la autorización.
Ahora, para su propio proyecto, le recomiendo que consulte la plantilla de proyecto del sitio web ASP.NET MVC 2 OpenID (C #) disponible en la Galería VS. De fábrica, viene con la autenticación OpenID y el soporte del proveedor de servicios OAuth. Esto significa que los usuarios pueden iniciar sesión con OpenID, y las aplicaciones y servicios de terceros pueden usar OAuth para hacer llamadas a la API a su sitio web y acceder a los datos del usuario.
Lo que parece que le gustaría agregar a esta plantilla de proyecto una vez que se pone en marcha es la capacidad de los usuarios para iniciar sesión con nombre de usuario + contraseña, así como OpenID. Además, si desea que Facebook y Twitter sean una opción para sus usuarios, debe implementarlos también, ya que no usan el estándar OpenID. Pero la descarga de DotNetOpenAuth incluye muestras para iniciar sesión con Twitter y Facebook, por lo que tiene alguna orientación allí.
Sospecho que no tendrás mucho o nada que hacer en el frente de autorización. Viene con OAuth como dije antes, y eso probablemente sea suficiente para ti.