Tu pregunta es muy confusa ya que no está claro quién eres realmente o crees que eres ... Entonces, revisemos el protocolo OAuth2.
Los roles
OAuth define cuatro roles:
propietario del recurso :
Una entidad capaz de otorgar acceso a un recurso protegido.
Cuando el propietario del recurso es una persona, se le conoce como
usuario final.
servidor de recursos :
El servidor que aloja los recursos protegidos, capaz de aceptar.
y responder a solicitudes de recursos protegidos mediante tokens de acceso.
cliente :
Una solicitud que realiza solicitudes de recursos protegidos en nombre de la
Propietario del recurso y con su autorización. El término "cliente" hace
no implica ninguna característica particular de implementación (por ejemplo,
si la aplicación se ejecuta en un servidor, un escritorio u otro
dispositivos).
servidor de autorización :
El servidor que emite tokens de acceso al cliente después de haberlo realizado correctamente.
autenticar al propietario del recurso y obtener la autorización.
Si tomamos stackoverflow como ejemplo, los roles serían
- propietario del recurso: Le agradezco, pero más su navegador (de forma extraña)
- cliente: stackoverflow
- servidor de recursos: facebook
- servidor de autorización: facebook
¿Quién eres?
Empieza diciendo que usted es el servidor de recursos y luego dice que el servidor de recursos está usando nodo y angular.
Estoy implementando un servidor de recursos OAuth 2.0 usando la Autorización
Flujo de código (es decir, los usuarios autorizarán las aplicaciones cliente para conectarse a nuestro
servidor). El servidor de recursos ejecuta Node en el servidor y Angular en
El cliente y todas las comunicaciones cliente-servidor se realizan a través de AJAX.
No tiene sentido. El servidor de recursos es básicamente un servicio web al que llaman otras aplicaciones, los clientes, para recuperar información. ¿Por qué utilizarías angularjs que está diseñado para crear una aplicación web en un navegador cuando las cosas que accederán son otras aplicaciones que no tienen el concepto de navegador en absoluto?
¿Quién eres realmente?
La estimación aleatoria sería que usted es el servidor de autorización, o más específicamente, con respecto a su pregunta, el servidor de autorización mencionado en la sección 1.3.1 Código de autorización.
El código de autorización se obtiene utilizando un servidor de autorización como
Un intermediario entre el cliente y el propietario del recurso. En lugar de
solicitando autorización directamente del propietario del recurso, el cliente
dirige al propietario del recurso a un servidor de autorización (a través de su
user-agent como se define en [RFC2616]), que a su vez dirige el
El propietario del recurso vuelve al cliente con el código de autorización.
Ahora volvamos a tu pregunta ...
Sí, puedes hacerlo sin ningún problema. Más específicamente, su servidor de autorización puede devolver el comando de redirección al navegador, que luego redirigirá a la página de la derecha usando javascript. No cambia nada en el flujo, por lo que no debería haber ningún problema.
¿Dónde está la confusión entonces?
Es simplemente que AJAX no funciona en lugar de la redirección, pero aquí no es lo que estás haciendo. El flujo es así:
- el cliente redirige el navegador al servidor de autorización
- el servidor de autorización redirige el navegador al cliente
Una idea común que no funciona es que podría reemplazar aquellos que redirigen una solicitud AJAX desde el javascript del cliente al servidor de autorización y obtener su autorización de autorización. No funciona debido a la misma política de origen y los usuarios no tendrían la oportunidad de confirmar la concesión de la autorización. Pero no es tu caso aquí, así que olvidémonos de eso.
Conclusión
El javascript en una página es realmente solo una extensión del servidor (cuando se usa https). La única diferencia es que es una parte pública en lugar de una privada como el servidor. Es una parte pública porque el usuario puede ver todo el código y todos los datos. Puedes hacer casi toda tu lógica en el código javascript, que es lo que estás haciendo con angularjs.
Las únicas partes que nunca deberían estar en él son las cosas que el usuario nunca debería saber. Por ejemplo, el secreto del cliente, por lo que se creó el flujo de concesión de autorización implícito (1.3.2). En su caso, no procesa ninguna información que el usuario nunca debería saber, por lo que no hay problema.
Referencia: enlace