Mitigación de la suplantación de identidad en OAuth 2 0 Parte I de II
OAuth2 es uno de los protocolos de autorizaci�n/single sign-on (SSO) m�s extendidos en Internet sobre el que adem�s se basa el est�ndar de autenticaci�n OpenID Connect. Es su gran difusi�n y aceptaci�n lo que provocar�a que el descubrimiento de un nuevo vector de ataque contra dicho protocolo tuviera un gran impacto. Hasta la fecha, los an�lisis realizados sobre OAuth2 basan sus vectores de ataque en las consideraciones de seguridad ya descritas en la propia especificaci�n del protocolo, como por ejemplo, los par�metros que deber�an ser saneados por el servidor de autorizaci�n como la URL de redirecci�n o la suplantaci�n del usuario.
Con vistas a mitigar los vectores de ataque conocidos sobre OAuth2, en este trabajo se desarrollar� una posible soluci�n basada en mecanismos de identificaci�n de cliente y tokens autocontenidos. Por un lado, los mecanismos de identificaci�n permitir�an a un servidor de OAuth2 ser capaz de proteger las credenciales del usuario mediante una autenticaci�n basada en riesgos, y por otro lado, los tokens autocontenidos permitir�an que, aunque se hubiesen visto comprometidos en su transmisi�n o almacenamiento, s�lo ser�an v�lidos para los clientes para los que fueron emitidos gracias a la informaci�n que contienen sobre el cliente identificado.
1.- Introducci�n
OAuth2 es un protocolo que permite independizar, en entornos distribuidos, la capa de autorizaci�n y la separaci�n de roles de clientes y usuarios, de los propios recursos HTTP protegidos. Para gestionar dicha autorizaci�n, en vez de utilizar los credenciales del usuario propietario del recurso al que se quiere acceder, un cliente o aplicaci�n de tercero utilizar� un token de acceso, es decir, una cadena de caracteres que denota un �mbito de uso, un tiempo de vida y otros atributos de acceso a los recursos protegidos. Estos tokens de acceso son emitidos a dichas aplicaciones de terceros previa autorizaci�n del propietario del recurso protegido para que puedan acceder a dicho recurso en su nombre. Esto es lo que se denominar�a como autorizaci�n delegada.
Esta autorizaci�n delegada obtenida por la aplicaci�n de terceros, al ser concedida bajo previa autorizaci�n del usuario propietario del recurso, permite a dicho usuario definir un �mbito de acceso tan reducido como el propio servidor de autorizaci�n le permita. Por este motivo, si la aplicaci�n de terceros intenta acceder a otro recurso protegido del usuario fuera del �mbito del token de acceso inicial que se le proporcion�, dicha aplicaci�n necesitar� volver a solicitar permiso al usuario final. Esto desmitifica por completo la err�nea creencia de que OAuth2 es un protocolo de SSO para autenticaci�n, ya que es necesario reiteradas autenticaciones del usuario final para autorizar el acceso a aplicaciones de terceros a nuevos recursos protegidos fuera del �mbito del token de acceso inicial del que dispon�an.
Por otro lado, sobre el propio protocolo OAuth2 y fundamentado en las dos premisas que define su RFC 6749:
2.- Motivaci�n
El protocolo OAuth2, tanto en su propia RFC 6749 como en la RFC 6819 que define el modelo de riesgos de OAuth2, describe las consideraciones de seguridad a tener en cuenta a la hora de utilizar o implementar un servidor de OAuth2. Entre dichas consideraciones de seguridad podemos encontrar, la recomendaci�n de registrar las URIs de redirecci�n asociadas a cada cliente para evitar redirecciones no controladas gestionadas por ellos mismos o por terceros, la recomendaci�n de que el cliente deber�a utilizar el par�metro "state" en sus peticiones al servidor de autorizaci�n como un token anti-CSRF [A. Barth, C. Jackson, J. C. Mitchell, "Robust defenses for cross-site request forgery", CCS, pp. 75�88, 2008.], y la recomendaci�n de mantener de manera confidencial, tanto durante la comunicaci�n como durante el almacenamiento, los credenciales del usuario as� como los tokens emitidos por el servidor de autorizaci�n, es decir, los tokens de acceso, los tokens de refresco y los c�digos de autorizaci�n.
A lo largo de esta secci�n se describir�n algunos de los vectores de ataque basados en las implementaciones que cada IdP de Internet ha llevado a cabo para cubrir la especificaci�n del protocolo OAuth2. Tambi�n se describir�n los vectores de ataque basados en la propia especificaci�n del protocolo, los cuales son agn�sticos de la implementaci�n posterior que se realice.
3.- Vectores de ataque basados en la implementaci�n
Aunque el protocolo defina a priori las consideraciones de seguridad a tener en cuenta, no siempre los servidores que implementan la especificaci�n del protocolo OAuth2 cumplen estas recomendaciones. Un ejemplo lo podemos encontrar en los fallos de seguridad reportados por Egor Homakov y documentados en su blog a los programas de Bug Bounty de Facebook y Github, los cuales son programas que recompensan econ�micamente a los investigadores que reporten de manera responsable los fallos de seguridad en vez de realizar un uso malicioso de los mismos.
El caso reportado a Facebook se aprovechaba de que la versi�n de Google Chrome XSS Auditor fugaba la informaci�n de "document.referer", es decir, se mostraba la informaci�n referida a la URL desde la que se propici� la carga de la p�gina actual. A lo anterior se sumaba que Facebook introduc�a la cabecera HTTP "X-XSS-Protection: 1;mode=block" para bloquear los ataques de XSS.
Teniendo en cuenta ambas premisas, si el cliente introduc�a un XSS en el par�metro "state" de su petici�n, cuando llegaba la respuesta con el token de acceso al navegador, �ste la bloqueaba al tener el "mode=block" y dicha respuesta se redirig�a a la p�gina "about:blank" de Google Chrome, mostrando, como se ha comentado, la informaci�n de la URL que en este caso conten�a el token de acceso. En la Figura 6 se muestra un ejemplo de fuga del token de acceso a trav�s de la cabecera HTTP referer la cual indica la URL desde la que se propici� la carga de la p�gina actual.
Por otro lado, en el caso reportado a Github, la URL de redirecci�n enviada por el usuario al servidor de autorizaci�n no se filtraba de manera adecuada, lo que posibilitaba el vector de ataque de path transversal. Este hecho, sumado a un par m�s de vulnerabilidades descritas en el caso reportado, permit�a a un usuario atacante ganar acceso a recursos de otros usuarios con los mismos permisos que el usuario atacante ten�a sobre sus propios recursos protegidos.
Estos fallos de seguridad encontrados en IdPs tan importantes como pueden ser Facebook y Github, podr�an haber sido evitados siguiendo las recomendaciones de seguridad descritas en el punto 10.14 de la propia RFC 6749 del protocolo OAuth2, en la cual se define que tanto el servidor de autorizaci�n como el cliente deben sanear cualquier valor recibido siempre que sea posible, en particular, el valor de los par�metros "state" y "redirect_uri".
4.- Vectores de ataque basados en la especificaci�n
Aunque los detalles de implementaci�n que provocan las vulnerabilidades son vectores de ataque completamente v�lidos y reales de las implementaciones del protocolo OAuth2 que actualmente existen en los grandes IdPs de Internet, no se debe pasar por alto los vectores de ataque basados en la especificaci�n del propio protocolo, ya que �stos podr�an ser agn�sticos de la implementaci�n posterior realizada y conllevar un mayor impacto.
El estudio formal sobre el protocolo OAuth2 llevado a cabo por la Universidad de Trier de Alemania, cuya �ltima versi�n data de 2016, pone de manifiesto cuatro vectores de ataque no descritos hasta la fecha, los cuales se basan principalmente, en la RFC 6749 del protocolo OAuth2. Dichos vectores de ataque ser�an los siguientes:
Por otro lado, la fuga de informaci�n, como por ejemplo, el valor del par�metro anti-CSRF "state" o el de los tokens codificados en la URL se basa, del mismo modo que el fallo de seguridad reportado a Facebook detallado en la secci�n de vectores de ataque basados en la implementaci�n, en una mala configuraci�n de las pol�ticas de la cabecera HTTP referer. Esta mala configuraci�n propicia que si el IdP tuviera enlaces a recursos externos, si el usuario siguiera dichos enlaces, los recursos externos tendr�an a su alcance en la cabecera HTTP el valor de los par�metros ya citados, permiti�ndoles, por ejemplo, saltare la protecci�n anti-CSRF o robar la sesi�n o los tokens emitidos por el servidor de autorizaci�n.
En cuanto a lo que se denomina gesti�n "inocente" de la integridad de la sesi�n por parte del recurso protegido, se refiere a que dicho recurso lleva a cabo un seguimiento del usuario entre una petici�n y otra, es decir, es un recurso con estado (stateful), pero sin embargo, no realiza comprobaciones de la integridad de la sesi�n con la que est� identificando a dicho usuario. Del mismo modo que pasaba con las redirecciones HTTP 307, ninguna RFC de OAuth2 ya citada, define m�s all� de la obligaci�n del recurso protegido de validar el token de acceso y comprobar que no est� expirado.
Por este motivo, el ataque descrito en el estudio se basa en la suplantaci�n de la sesi�n de seguimiento emitida por el recurso protegido. Para ello, un atacante comienza una sesi�n leg�tima con un IdP con el fin de obtener su token de acceso, haciendo adem�s creer al recurso protegido, que �l es su IdP leg�timo. Cuando un tercer usuario intente acceder al recurso protegido, �ste le redireccionar� al IdP del atacante que le devolver� su propia sesi�n de seguimiento y su token obtenido de manera leg�tima con el IdP. Esta suplantaci�n provocar� que el recurso protegido crea que es propiedad del usuario atacante y no del nuevo usuario.
Por �ltimo, el ataque de confusi�n de IdP es el m�s complejo y requiere de m�ltiples asunciones para que se pudiera llevar a cabo. Dicho ataque consistir�a en lo que podr�amos denominar un servidor OAuth2-in-the-middle, permitiendo al atacante la obtenci�n de la informaci�n de los credenciales del usuario, tokens y dem�s informaci�n sensible. En la Figura 10 se muestra el diagrama de flujo del ataque de confusi�n de IdP extra�do del estudio formal sobre OAuth2 llevado a cabo por la Universidad de Trier de Alemania.
En 2016, Wanpeng Li y Chris J. Mitchell de la Universidad de Londres, realizaron una presentaci�n en la que demostraban que ciertas de las asunciones del modelo formal descrito para llevar a cabo este ataque no aplican en la pr�ctica y se reafirmaban en que el modelo de seguridad de OAuth2 se construye sobre la confianza del IdP, por lo que si el IdP es malicioso, el sistema al completo de OAuth2 est� corrupto. Esta �ltima premisa de que el modelo de seguridad se construye sobre la confianza en el IdP, aplicar�a tanto a este ataque de confusi�n de IdP como al de gesti�n "inocente" de la integridad de la sesi�n por parte del recurso protegido descrito en el p�rrafo anterior.
Los tipos de vectores de ataque descritos en esta secci�n, basados en la especificaci�n y basados en la implementaci�n, cuya finalidad es romper la autorizaci�n, la autenticaci�n o la integridad de sesi�n, aplican a los flujos de authorization code e implicit descritos en la RFC 6749 del protocolo OAuth2. Como ya se ha mencionado con anterioridad, estos flujos est�n incluidos en el protocolo OpenID Connect al estar �ste construido sobre OAuth2, por lo que dichos vectores de ataque descritos son igualmente v�lidos sobre el protocolo OpenID Connect.
[Contin�a en la Parte II]
Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM
 |
| Figura 1: Mitigaci�n de la suplantaci�n de identidad en OAuth 2.0 |
Con vistas a mitigar los vectores de ataque conocidos sobre OAuth2, en este trabajo se desarrollar� una posible soluci�n basada en mecanismos de identificaci�n de cliente y tokens autocontenidos. Por un lado, los mecanismos de identificaci�n permitir�an a un servidor de OAuth2 ser capaz de proteger las credenciales del usuario mediante una autenticaci�n basada en riesgos, y por otro lado, los tokens autocontenidos permitir�an que, aunque se hubiesen visto comprometidos en su transmisi�n o almacenamiento, s�lo ser�an v�lidos para los clientes para los que fueron emitidos gracias a la informaci�n que contienen sobre el cliente identificado.
1.- Introducci�n
OAuth2 es un protocolo que permite independizar, en entornos distribuidos, la capa de autorizaci�n y la separaci�n de roles de clientes y usuarios, de los propios recursos HTTP protegidos. Para gestionar dicha autorizaci�n, en vez de utilizar los credenciales del usuario propietario del recurso al que se quiere acceder, un cliente o aplicaci�n de tercero utilizar� un token de acceso, es decir, una cadena de caracteres que denota un �mbito de uso, un tiempo de vida y otros atributos de acceso a los recursos protegidos. Estos tokens de acceso son emitidos a dichas aplicaciones de terceros previa autorizaci�n del propietario del recurso protegido para que puedan acceder a dicho recurso en su nombre. Esto es lo que se denominar�a como autorizaci�n delegada.
 |
| Figura 2: RFC para discutir OAuth 2.0 |
Esta autorizaci�n delegada obtenida por la aplicaci�n de terceros, al ser concedida bajo previa autorizaci�n del usuario propietario del recurso, permite a dicho usuario definir un �mbito de acceso tan reducido como el propio servidor de autorizaci�n le permita. Por este motivo, si la aplicaci�n de terceros intenta acceder a otro recurso protegido del usuario fuera del �mbito del token de acceso inicial que se le proporcion�, dicha aplicaci�n necesitar� volver a solicitar permiso al usuario final. Esto desmitifica por completo la err�nea creencia de que OAuth2 es un protocolo de SSO para autenticaci�n, ya que es necesario reiteradas autenticaciones del usuario final para autorizar el acceso a aplicaciones de terceros a nuevos recursos protegidos fuera del �mbito del token de acceso inicial del que dispon�an.
Por otro lado, sobre el propio protocolo OAuth2 y fundamentado en las dos premisas que define su RFC 6749:
"los servidores de autorizaci�n deber�an ignorar cualquier par�metro de las peticiones que no est�n reconocidos en la RFC", y "los clientes deber�an ignorar cualquier par�metro de las respuestas que no est�n reconocidos en la RFC"se ha construido el protocolo OpenID Connect. Este protocolo si es un protocolo SSO para autenticaci�n y est� muy extendido en IdPs (Identity Providers) de Internet como Google, GitHub, Facebook o Microsoft Office 365 - como se pudo ver en los ataques Sappo "Spear Apps to Steal OAuth-tokens" - entre otros. Es importante tener en cuenta el protocolo OpenID Connect a la hora de realizar este estudio, ya que al estar construido sobre el protocolo OAuth2, cualquier nuevo vector de ataque podr�a repercutir directamente en OpenID Connect. En la Figura 3 se muestra de manera gr�fica los m�dulos que componen el protocolo OpenID Connect incluyendo entre sus pilares, los componentes de la especificaci�n de OAuth2.
 |
| Figura 3: Protocolo OpenID Connect |
2.- Motivaci�n
El protocolo OAuth2, tanto en su propia RFC 6749 como en la RFC 6819 que define el modelo de riesgos de OAuth2, describe las consideraciones de seguridad a tener en cuenta a la hora de utilizar o implementar un servidor de OAuth2. Entre dichas consideraciones de seguridad podemos encontrar, la recomendaci�n de registrar las URIs de redirecci�n asociadas a cada cliente para evitar redirecciones no controladas gestionadas por ellos mismos o por terceros, la recomendaci�n de que el cliente deber�a utilizar el par�metro "state" en sus peticiones al servidor de autorizaci�n como un token anti-CSRF [A. Barth, C. Jackson, J. C. Mitchell, "Robust defenses for cross-site request forgery", CCS, pp. 75�88, 2008.], y la recomendaci�n de mantener de manera confidencial, tanto durante la comunicaci�n como durante el almacenamiento, los credenciales del usuario as� como los tokens emitidos por el servidor de autorizaci�n, es decir, los tokens de acceso, los tokens de refresco y los c�digos de autorizaci�n.
 |
| Figura 4: Modelo de riesgos en OAuth 2.0 |
A lo largo de esta secci�n se describir�n algunos de los vectores de ataque basados en las implementaciones que cada IdP de Internet ha llevado a cabo para cubrir la especificaci�n del protocolo OAuth2. Tambi�n se describir�n los vectores de ataque basados en la propia especificaci�n del protocolo, los cuales son agn�sticos de la implementaci�n posterior que se realice.
3.- Vectores de ataque basados en la implementaci�n
Aunque el protocolo defina a priori las consideraciones de seguridad a tener en cuenta, no siempre los servidores que implementan la especificaci�n del protocolo OAuth2 cumplen estas recomendaciones. Un ejemplo lo podemos encontrar en los fallos de seguridad reportados por Egor Homakov y documentados en su blog a los programas de Bug Bounty de Facebook y Github, los cuales son programas que recompensan econ�micamente a los investigadores que reporten de manera responsable los fallos de seguridad en vez de realizar un uso malicioso de los mismos.
 |
| Figura 5: Fallos en OAuth2 utilizados para hackear Facebook |
El caso reportado a Facebook se aprovechaba de que la versi�n de Google Chrome XSS Auditor fugaba la informaci�n de "document.referer", es decir, se mostraba la informaci�n referida a la URL desde la que se propici� la carga de la p�gina actual. A lo anterior se sumaba que Facebook introduc�a la cabecera HTTP "X-XSS-Protection: 1;mode=block" para bloquear los ataques de XSS.
Teniendo en cuenta ambas premisas, si el cliente introduc�a un XSS en el par�metro "state" de su petici�n, cuando llegaba la respuesta con el token de acceso al navegador, �ste la bloqueaba al tener el "mode=block" y dicha respuesta se redirig�a a la p�gina "about:blank" de Google Chrome, mostrando, como se ha comentado, la informaci�n de la URL que en este caso conten�a el token de acceso. En la Figura 6 se muestra un ejemplo de fuga del token de acceso a trav�s de la cabecera HTTP referer la cual indica la URL desde la que se propici� la carga de la p�gina actual.
 |
| Figura 6: Fuga de informaci�n en la cabecera HTTP |
Por otro lado, en el caso reportado a Github, la URL de redirecci�n enviada por el usuario al servidor de autorizaci�n no se filtraba de manera adecuada, lo que posibilitaba el vector de ataque de path transversal. Este hecho, sumado a un par m�s de vulnerabilidades descritas en el caso reportado, permit�a a un usuario atacante ganar acceso a recursos de otros usuarios con los mismos permisos que el usuario atacante ten�a sobre sus propios recursos protegidos.
 |
| Figura 7: Punto 10.4 RFC 6749 |
Estos fallos de seguridad encontrados en IdPs tan importantes como pueden ser Facebook y Github, podr�an haber sido evitados siguiendo las recomendaciones de seguridad descritas en el punto 10.14 de la propia RFC 6749 del protocolo OAuth2, en la cual se define que tanto el servidor de autorizaci�n como el cliente deben sanear cualquier valor recibido siempre que sea posible, en particular, el valor de los par�metros "state" y "redirect_uri".
4.- Vectores de ataque basados en la especificaci�n
Aunque los detalles de implementaci�n que provocan las vulnerabilidades son vectores de ataque completamente v�lidos y reales de las implementaciones del protocolo OAuth2 que actualmente existen en los grandes IdPs de Internet, no se debe pasar por alto los vectores de ataque basados en la especificaci�n del propio protocolo, ya que �stos podr�an ser agn�sticos de la implementaci�n posterior realizada y conllevar un mayor impacto.
 |
| Figura 8: Estudio de la Universidad Trier de Alemania sobre OAuth 2.0 |
El estudio formal sobre el protocolo OAuth2 llevado a cabo por la Universidad de Trier de Alemania, cuya �ltima versi�n data de 2016, pone de manifiesto cuatro vectores de ataque no descritos hasta la fecha, los cuales se basan principalmente, en la RFC 6749 del protocolo OAuth2. Dichos vectores de ataque ser�an los siguientes:
� Redirecciones HTTP 307
� Fuga de informaci�n
� Gesti�n "inocente" de la integridad de la sesi�n por parte del recurso protegido
� Confusi�n de IdPEl primer vector de ataque basado en redirecciones HTTP 307 se fundamenta en que ni la RFC 6749 del protocolo OAuth2, ni la RFC 6819 que define el modelo de riesgos de OAuth2 especifican el m�todo exacto de redirecci�n HTTP. El problema de la redirecci�n HTTP 307 radica, como bien se indica en el punto 6.4.7 de la RFC 7231, en que dicha redirecci�n no permite cambiar el m�todo de la petici�n de POST a GET. Esto quiere decir que si la redirecci�n se produce inmediatamente despu�s de introducir los credenciales del usuario, �stos viajar�n en el cuerpo del POST de la redirecci�n hacia donde el navegador sea redirigido.
 |
| Figura 9: Redirecciones HTTP Temporales |
Por otro lado, la fuga de informaci�n, como por ejemplo, el valor del par�metro anti-CSRF "state" o el de los tokens codificados en la URL se basa, del mismo modo que el fallo de seguridad reportado a Facebook detallado en la secci�n de vectores de ataque basados en la implementaci�n, en una mala configuraci�n de las pol�ticas de la cabecera HTTP referer. Esta mala configuraci�n propicia que si el IdP tuviera enlaces a recursos externos, si el usuario siguiera dichos enlaces, los recursos externos tendr�an a su alcance en la cabecera HTTP el valor de los par�metros ya citados, permiti�ndoles, por ejemplo, saltare la protecci�n anti-CSRF o robar la sesi�n o los tokens emitidos por el servidor de autorizaci�n.
En cuanto a lo que se denomina gesti�n "inocente" de la integridad de la sesi�n por parte del recurso protegido, se refiere a que dicho recurso lleva a cabo un seguimiento del usuario entre una petici�n y otra, es decir, es un recurso con estado (stateful), pero sin embargo, no realiza comprobaciones de la integridad de la sesi�n con la que est� identificando a dicho usuario. Del mismo modo que pasaba con las redirecciones HTTP 307, ninguna RFC de OAuth2 ya citada, define m�s all� de la obligaci�n del recurso protegido de validar el token de acceso y comprobar que no est� expirado.
Por este motivo, el ataque descrito en el estudio se basa en la suplantaci�n de la sesi�n de seguimiento emitida por el recurso protegido. Para ello, un atacante comienza una sesi�n leg�tima con un IdP con el fin de obtener su token de acceso, haciendo adem�s creer al recurso protegido, que �l es su IdP leg�timo. Cuando un tercer usuario intente acceder al recurso protegido, �ste le redireccionar� al IdP del atacante que le devolver� su propia sesi�n de seguimiento y su token obtenido de manera leg�tima con el IdP. Esta suplantaci�n provocar� que el recurso protegido crea que es propiedad del usuario atacante y no del nuevo usuario.
Por �ltimo, el ataque de confusi�n de IdP es el m�s complejo y requiere de m�ltiples asunciones para que se pudiera llevar a cabo. Dicho ataque consistir�a en lo que podr�amos denominar un servidor OAuth2-in-the-middle, permitiendo al atacante la obtenci�n de la informaci�n de los credenciales del usuario, tokens y dem�s informaci�n sensible. En la Figura 10 se muestra el diagrama de flujo del ataque de confusi�n de IdP extra�do del estudio formal sobre OAuth2 llevado a cabo por la Universidad de Trier de Alemania.
 |
| Figura 10: Diagrama de flujo del ataque de confusi�n de IdP |
En 2016, Wanpeng Li y Chris J. Mitchell de la Universidad de Londres, realizaron una presentaci�n en la que demostraban que ciertas de las asunciones del modelo formal descrito para llevar a cabo este ataque no aplican en la pr�ctica y se reafirmaban en que el modelo de seguridad de OAuth2 se construye sobre la confianza del IdP, por lo que si el IdP es malicioso, el sistema al completo de OAuth2 est� corrupto. Esta �ltima premisa de que el modelo de seguridad se construye sobre la confianza en el IdP, aplicar�a tanto a este ataque de confusi�n de IdP como al de gesti�n "inocente" de la integridad de la sesi�n por parte del recurso protegido descrito en el p�rrafo anterior.
 |
| Figura 11: Does the IdP Mix-Up attack really work? |
Los tipos de vectores de ataque descritos en esta secci�n, basados en la especificaci�n y basados en la implementaci�n, cuya finalidad es romper la autorizaci�n, la autenticaci�n o la integridad de sesi�n, aplican a los flujos de authorization code e implicit descritos en la RFC 6749 del protocolo OAuth2. Como ya se ha mencionado con anterioridad, estos flujos est�n incluidos en el protocolo OpenID Connect al estar �ste construido sobre OAuth2, por lo que dichos vectores de ataque descritos son igualmente v�lidos sobre el protocolo OpenID Connect.
[Contin�a en la Parte II]
Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM
Sigue Un inform�tico en el lado del mal - Google+ RSS 0xWord
download file now
alternative link download