tutorial implementar implement how example ejemplo como api rest authentication oauth oauth-2.0

implementar - Confusión de autenticación api tranquila con oauth2



oauth2 token (3)

En oAuth 2.0, hay varios tipos de tipos de subvención. Un tipo de concesión es solo una forma de intercambiar algún tipo de credenciales para un token de acceso. Por lo general, oAuth se refiere al uso de terceros con una concesión de código de autorización. Esto significa redirigir al usuario al sitio web del propietario del recurso para la autenticación, que devolverá un Código de autorización.

Esto claramente no tiene sentido para el uso de la primera parte, ya que usted ES el propietario del recurso. oAuth 2.0 ha considerado esto e incluye la concesión de credenciales de contraseña del propietario del recurso para este propósito. En este caso, puede intercambiar un nombre de usuario y una contraseña para un token de acceso en el primer nivel.

Consulte http://tools.ietf.org/html/rfc6749#section-4.3 para obtener más detalles.

Hice una investigación sobre la autenticación api tranquila. La mayoría de la gente señaló a Oauth2 para una autenticación api tranquila. Revisé algunos de los recursos, especialmente este enlace https://developers.google.com/accounts/docs/OAuth2 .

Me parece que Oauth2 es para que una aplicación de terceros acceda a los datos de los usuarios en google / facebook (u otro proveedor de datos).

Nuestro problema es que somos dueños de los datos, no necesitamos acceder a los datos de terceros de nuestros clientes y nuestros clientes no tienen a los datos de terceros. Queremos proteger nuestra api con algún tipo de autenticación.

Para nuestro caso, ¿cuáles son las tecnologías convenientes para nuestra autenticación api tranquila? Vamos a exponer nuestro api como este

https://ourdomain.com/api/<endpoint>

Nuestros clientes pueden acceder primero a un sitio web para registrarse https://ourdomain.com y deberían poder obtener clientId y clientKey de nuestro sitio web para acceder a las API. Nuestros clientes deberían poder consumir a través de algún tipo de autenticación.


Si lo comprendo correctamente, lo necesita de forma similar a OAuth de manera que haga exactamente lo mismo menos que otorga a una aplicación de terceros acceso a los recursos de un usuario.

En OAuth, existe un sistema central que administra la autenticación y la autorización al verificar las credenciales de una aplicación + las credenciales del usuario y al entregar tokens de autorización. Existen múltiples puntos finales que aceptarán estos tokens de autorización.

Los tokens son básicamente cadenas cifradas que contienen información sobre las credenciales del usuario y otra información que podría ser necesaria para su aplicación.

Lo que necesita (creo) es un punto final de autenticación similar, que el cliente cumple con sus credenciales y obtiene un token.

Asi que,
i) Cree un formulario de registro / consola donde un cliente pueda registrarse y obtener sus credenciales. Echa un vistazo a this .
ii) Defina un punto final HTTP donde el usuario intercambia sus credenciales por un token de acceso + token de actualización.
iii) El cliente puede golpear el punto final del recurso con los tokens de acceso para realizar llamadas autenticadas a cualquiera de su punto final.
iv) En el back-end necesitarías un servicio común que verifique los tokens y extraiga información de ellos.

PD: esto es solo un sistema mínimo, habría muchas consideraciones de seguridad como si una aplicación no autorizada tuviera acceso a los tokens de acceso de algunos clientes.
Puede encontrar mucha información sobre los ataques CSRF, mediodía, marcas de tiempo y otros métodos para mitigar los problemas de seguridad.


Solo para ser claros con la pregunta original:

OAuth2 necesita al menos un cliente y un servidor

OP se preguntaba cómo asegurar una API REST y por qué todo el mundo habla de proveedores de autenticación de terceros (Google, Facebook, ...)

Hay 2 necesidades diferentes aquí:

1 - Ser capaz de asegurar una API personal (ourdomain.com)

Client Server Consumers <----> Your API

2 - Poder consumir una API pública (por ejemplo, obtener la lista de contactos de Google de un usuario)

Client Server You <----> Google APIs

OP realmente necesita el primero: implementar un servidor OAuth2 delante de su propia API.
Existen muchas implementaciones para todos los lenguajes / marcos en Github

Finalmente, aquí hay una buena explicación técnica de Oauth2 , y estoy tomando descaradamente uno de sus esquemas aquí:

No, no estoy trabajando en Google, solo tomo Google como un ejemplo de proveedor de API pública.