OAuth, Open Authorization Protocol
Cuando en 2006 los ingenieros de twitter estaban tratando de implementar OpenID para permitir a los desarrolladores de aplicaciones acceder a su API sin que los usuarios tuvieran que introducir sus credenciales en la propia aplicación, se dieron cuenta, por un lado, de que OpenID no era la solución que necesitaban y, más importante aún, de que no existía ningún estándar que permitiera hacer algo parecido.
Comenzaron entonces a trabajar en la implementación de OAuth, que pronto fue apoyada por otras empresas como Google. Hasta que por fin, en octubre de 2007, se publicó OAuth 1.0. Aunque no fue hasta agosto de 2010 que no se aprobó como estándar RFC 5849.
Pero, ¿cómo funciona OAuth y cómo soluciona el problema de que el usuario tenga que introducir sus credenciales en una aplicación de un tercero para acceder a otro servicio?
Antes de explicarlo, voy a introducir unos conceptos que son usados en toda documentación referente a OAuth:
Y ahora sí, veamos cómo funciona el protocolo con un ejemplo y utilizando la siguiente imagen como punto de referencia.
Contenido completo en fuente original S21Sec
Comenzaron entonces a trabajar en la implementación de OAuth, que pronto fue apoyada por otras empresas como Google. Hasta que por fin, en octubre de 2007, se publicó OAuth 1.0. Aunque no fue hasta agosto de 2010 que no se aprobó como estándar RFC 5849.
Pero, ¿cómo funciona OAuth y cómo soluciona el problema de que el usuario tenga que introducir sus credenciales en una aplicación de un tercero para acceder a otro servicio?
Antes de explicarlo, voy a introducir unos conceptos que son usados en toda documentación referente a OAuth:
- Service Provider: La aplicación web que permite acceder via OAuth.
- User (usuario): Cualquiera que tenga una cuenta en el Service Provider.
- Consumer: Aplicación de un tercero que usa OAuth para acceder al Service Provider en nombre de un usuario.
- Protected Resource: Recurso (normalmente información aunque también puede ser una funcionalidad) al que se desea acceder y que se almacena en el Service Provider.
- Consemer Key / Consumer Secret: Par de identificador / secreto que sirven para que el Consumer pueda identificarse frente al Service Provider.
- Request Token / Request Secret: Par de identificador / secreto de carácter temporal que es utilizado por el Consumer para que el usuario autorice al Consumer a acceder a sus recursos frente al Service Provider.
- Access Token / Access Secret: Par de identificador / secreto usado por el Consumer para acceder a los recursos del Service Provider una vez que el usuario lo ha autorizado.
Y ahora sí, veamos cómo funciona el protocolo con un ejemplo y utilizando la siguiente imagen como punto de referencia.
Contenido completo en fuente original S21Sec
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!