Sí, OAuth es la elección correcta para esto. Como se trata de una implementación nueva, le recomiendo que use OAuth 2.0.
Para su configuración, recomendaría un tercer sitio (llamémoslo “Sitio Z”) para manejar la autenticación para A y B. De esta manera, eliminamos una dependencia de B a A que puede romperse si decide hacer cambios en A Z será el proveedor de OAuth, A y B son consumidores.
Debe elegir entre el Código de autorización o los tipos OAuth de concesión implícita. Para el Código de autorización, el consumidor también estará del lado del servidor. Para Grant implícito, el consumidor estará en JavaScript del navegador.
- ¿Cómo hace un novato en desarrollo web para obtener una pasantía?
- ¿Cuál es el futuro de MEAN stack?
- Usando WordPress, ¿cuál fue su primera razón para aplicar el código usted mismo?
- ¿Cuál es el mejor instituto para el curso de desarrollo de pila completa en Chennai?
- ¿Cuál es la diferencia entre HTML y XML?
El resultado final de un proceso de autorización OAuth exitoso es un token de acceso que los sitios A y B pueden usar para realizar llamadas API contra Z. OAuth no especifica cómo se verán estas llamadas API, sino que solo especifica cómo funcionará la Autorización en un REST HTTP llamada – http://tools.ietf.org/html/draft…
En un caso de inicio de sesión único en el que Z no ofrece ninguna API, completar el flujo de OAuth es suficiente para la autorización. O Z pasó un token de acceso o Z devolvió un error. Simplemente verifique si el parámetro de consulta de URL (Código de autorización) o Hash (Concesión implícita) es access_token = … o error = ….
El parámetro expires_in le dice al cliente cuánto tiempo es válido el inicio de sesión, por lo tanto, no es necesario volver a autorizar en cada llamada.
Tenga en cuenta que la autorización de API de OAuth es diferente de la autorización de sesión de usuario.
Autorización para una aplicación del lado del servidor
Para un inicio de sesión con nombre de usuario / contraseña, cuando el navegador realiza la POST de
los datos del formulario, la aplicación del lado del servidor verifica el nombre de usuario / contraseña. Si la verificación tiene éxito, la aplicación del lado del servidor crea una sesión y establece una cookie para que el usuario haga que las solicitudes GET del navegador sucesivas envíen la cookie.
Para convertir esto a OAuth, puede hacer lo mismo para el redirect_uri usando el código de autorización OAuth 2.0. Cuando la aplicación del servidor recibe el código de autorización y puede obtener un token de acceso del proveedor (su servidor SSO), se completa la autorización.
Autorización para una aplicación web enriquecida / aplicación de una sola página
Para una aplicación web enriquecida, JavaScript mantiene el estado de la sesión en el cliente de su página web. Por lo tanto, debe escribir la lógica de autenticación en el lado del cliente.
