example angularjs oauth oauth-2.0 frontend backend

angularjs - example - spring security angular 5



¿Cómo interactuar con el back-end después de la autenticación exitosa con OAuth en el front-end? (6)

Quiero construir una pequeña aplicación. Habrá algunos usuarios. No quiero hacer mi propio sistema de usuario. Quiero integrar mi aplicación con oauth / oauth2.0.

No hay ningún problema en la integración de mi aplicación de front-end y auth 2.0. Hay tantos artículos útiles, cómo hacerlo, incluso en stackoverflow.com. Por ejemplo, esta publicación es muy útil.

Pero. ¿Qué debo hacer después de una autorización exitosa en el front-end? Por supuesto, solo puedo tener una marca en el cliente, que dice "está bien, amigo, el usuario está autenticado", pero ¿cómo debo interactuar con mi backend ahora? No puedo simplemente hacer algunas peticiones. Back-end: alguna aplicación que proporciona funciones de API. TODOS pueden acceder a esta api.

Por lo tanto, necesito algún sistema de autenticación de todos modos entre mi FE y BE. ¿Cómo debería funcionar este sistema?

PD: tengo algunos problemas con el inglés y puede que no pueda simplemente ''preguntar a google'' correctamente al respecto. ¿Puede proporcionar la pregunta correcta, por favor :) o al menos dar algunos artículos sobre mi pregunta?

UPD

Estoy buscando concepto. No quiero encontrar una solución para mi problema actual. No creo que sea un asunto que utilice FE y BE (de todos modos, proporcionaré información al respecto a continuación)

FE y BE utilizarán JSON para la comunicación. FE hará solicitudes, BE enviará respuestas JSON. Mi aplicación tendrá esta estructura (probablemente):

  • Frontend - probablemente AngularJS
  • Backend - probablemente Laravel (laravel implementará la lógica, también hay una base de datos en su estructura)

Tal vez "proveedor de servicios" como google.com, vk.com, twitter.com, etc. recuerda el estado del usuario? Y después de la autenticación exitosa en FE, solo puedo preguntar sobre el estado del usuario de BE?

Bueno, no necesitas un sistema de usuario en tu parte frontal. La interfaz es solo una forma de interactuar con su servidor y solicitar un token por usuario y contraseña válidos.

Su servidor supone gestionar los usuarios y los permisos.

Escenario de inicio de sesión de usuario

Usuario que solicita token ingresando su nombre de usuario y contraseña. La API del servidor acepta la solicitud porque es un método anónimo (todos pueden llamar a este método sin importar si ha iniciado sesión o no).

El servidor verifica la base de datos (O algo de almacenamiento) y compara los detalles del usuario con los detalles que tiene. En caso de que los detalles coincidan, el servidor devolverá el token al usuario.

A partir de ahora, el usuario debe establecer este token con cualquier solicitud para que el servidor reconozca al usuario. El token contiene los roles de usuario, la marca de tiempo, etc.

Cuando el usuario solicita datos por API, obtiene el token del usuario del encabezado y verifica si el usuario tiene permiso para acceder a ese método.

Así es como funciona en general.

Me basé en .NET en mi respuesta. Pero la mayoría de las bibliotecas de BE funcionan así.

Como estoy haciendo un proyecto para SSO y de acuerdo con mi comprensión de su pregunta, puedo sugerirle que cree un punto final en su back-end para generar sesiones, una vez que el cliente haya autorizado el frontend de manera exitosa, y obtuvo la información de usuario del proveedor, usted publica esa información en el punto final de back-end, el extremo de back-end genera una sesión y almacena esa información, y devuelve el ID de sesión, frecuentemente llamado jSessionId, con una cookie a la cliente-frontend, por lo que el navegador puede guardarlo para usted y todas las solicitudes posteriores al back-end considerado un usuario autenticado.

para cerrar sesión, simplemente cree otro punto final en el back-end para aceptar una ID de sesión para que el back-end pueda eliminarlo.

Espero que esto te sea de utilidad.

Debe almacenar el token en el estado de su aplicación y luego pasarlo al backend con cada solicitud. El paso al backend se puede hacer en encabezados, cookies o como parámetros, depende de cómo se implementa el backend.

Siga el código para ver un buen ejemplo de todas las piezas en acción (no mi código) Este ejemplo establece el encabezado Autorización: Portador TOKEN https://github.com/cornflourblue/angular-registration-login-example

Leí todas las respuestas con mucho cuidado, y más de la mitad de las personas que respondieron han perdido la pregunta por completo. OP solicita la conexión INICIAL entre FE y BE, después de que el proveedor de servicios haya emitido el token de OAuth.

¿Cómo sabe tu servidor que el token OAuth es válido? Recuerde que su BE puede enviar una solicitud al proveedor de servicios y confirmar la validez del token de OAuth, que fue recibido por primera vez por su FE. El Proveedor de servicios solo puede descifrar esta clave OAuth porque solo ellos tienen la clave secreta. Una vez que descifran la clave, generalmente responderán con información como nombre de usuario, correo electrónico y demás.

En resumen:

Su FE recibe el token OAuth del proveedor de servicios después de que el usuario autoriza. FE pasa el token de OAuth a BE. BE envía el token de OAuth al proveedor de servicios para validar el token de OAuth. El proveedor de servicios responde a BE con nombre de usuario / información de correo electrónico. Luego puede usar el nombre de usuario / correo electrónico para crear una cuenta.

Luego, después de que su BE cree la cuenta, su BE debe generar su propia implementación de un token OAuth. Luego envía a su FE este token de OAuth, y en cada solicitud, su FE enviaría este token en el encabezado a su BE. Dado que solo su BE tiene la clave secreta para validar este token, su aplicación será muy segura. Incluso puede actualizar el token OAuth de su BE en cada solicitud, dándole una nueva clave a su FE cada vez. En caso de que alguien robe el token de OAuth de su FE, ese token se invalidará rápidamente, ya que su BE ya habrá creado un nuevo token de OAuth para su FE.

Hay más información sobre cómo su BE puede validar el token de OAuth. ¿Cómo validar un token de acceso OAuth 2.0 para un servidor de recursos?

Tenemos 3 preocupaciones principales de seguridad al crear una API.

  1. Autenticación : un proveedor de identidad como Google es solo una solución parcial. Debido a que no desea que el usuario inicie sesión o confirme su identidad para cada solicitud de API, debe implementar la autenticación para las solicitudes posteriores. Debes almacenar, accesible al backend:

    1. Identificación de un usuario. (tomado del proveedor de identidad, por ejemplo: correo electrónico)
    2. Un token de usuario. (Un token temporal que genera y que puede verificar desde el código API)

  2. Autorización : Su backend debe implementar reglas basadas en la ID de usuario (es su propio negocio).

  3. Seguridad del transporte : HTTPS y las cookies que caducan son seguras y no pueden ser reproducidas por otros. (HTTPS está encriptando el tráfico, por lo que derrota los ataques del hombre en el medio, y las cookies vencidas repiten los ataques de repetición más adelante)

Así que su API / backend tiene una tabla de búsqueda de correos electrónicos a cadenas aleatorias. Ahora, no tienes que exponer la identificación del usuario. El token no tiene sentido y es temporal.

Así es como funciona el flujo, en este sistema:

User-Agent IdentityProvider (Google/Twitter) Front-End Back-End |-----------------"https://your.app.com"---------->| |---cookies-->| your backend knows the user or not. if backend recognizes cookie, user is authenticated and can use your API

MÁS:

if the user is unknown: |<--"unknown"-| |<----"your/login.js"----------+ "Do you Authorize this app?" |<------------------+ |--------"yes"----->| +----------auth token--------->| |<---------/your/moreinfo.js---| |-------access_token ---------->| 1. verify access token 2. save new user info, or update existing user 3. generate expiring, random string as your own API token +----------->| |<-------------- set cookie: your API token --------------------|

AHORA, el usuario puede usar directamente su API:

|--------------- some API request, with cookie ---------------->| |<-------------- some reply, depends on your logic, rules ------|

EDITAR

Basado en la discusión: agregar que el backend puede autenticar a un usuario verificando el token de acceso con el proveedor de identidad:

Por ejemplo, Google expone este punto final para verificar un token XYZ123 :

https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123

Usemos el concepto OAuth para comenzar, FE aquí es Cliente , ESTÁ aquí es Resource Server .

  • Dado que su cliente ya está autorizado, el servidor de Autorización debe otorgar el token de acceso al cliente.
  • El cliente realiza una solicitud al servidor de recursos con el token de acceso
  • El servidor de recursos valida el token de acceso , si es válido, maneja la solicitud.

Puede preguntar, ¿qué es el token de acceso , el token de acceso fue emitido por el servidor de autorización, otorgado al cliente y reconocido por el servidor de recursos?

El token de acceso es una cadena que indica la información de autorización (por ejemplo, información del usuario, alcance del permiso, caduca el tiempo ...).

El token de acceso puede estar encriptado por seguridad, y usted debe asegurarse de que el servidor de recursos pueda descifrarlo.

Para obtener más detalles, lea la especificación OAuth2.0 https://tools.ietf.org/html/rfc6749 .