Una aplicación OAuth es una aplicación que usa OAuth para obtener permisos para hacer algo.
Una implementación de OAuth es un sistema que implementa los protocolos de OAuth para permitir que las aplicaciones de OAuth soliciten permisos. Esto generalmente se llama el “servidor de recursos”. Ejemplos comunes: facebook, twitter, dropbox.
El propietario de un recurso es miembro del servidor de recursos y es quien otorga o deniega el permiso para que la aplicación OAuth haga algo. Este es comúnmente el usuario final: el propietario de la cuenta en Facebook, Twitter, Dropbox, etc.
- ¿Cuál es la explicación de la "violación" de privacidad que el WSJ encontró esta mañana?
- ¿Cuál debería comenzar primero: Ruby on Rails o Django? ¿Cuál es la diferencia entre estos dos y sus usos?
- ¿Cuáles son las diferencias entre estos métodos de reloj en angularJS?
- ¿Cuánto se paga por cada función agregada a una página web?
- ¿Qué es Elasticsearch y por qué uno lo incorporaría a una aplicación de pila completa?
Un cliente es una aplicación que quiere hacer algo en nombre del propietario del recurso. Esta es la aplicación que está utilizando el usuario final.
Entonces, la respuesta a su primera pregunta es que los propietarios de recursos no se crean en ninguna aplicación. Se crean cuando un usuario se suscribe al servicio en el servidor de recursos. Por ejemplo, si se registra en Facebook, entonces (el propietario del recurso) se está registrando para el servicio en Facebook (el servidor de recursos). Si usa una aplicación (por ejemplo, Cumpleaños) que desea publicar en su línea de tiempo, entonces la aplicación es el cliente. Usted da (o niega) permiso para que la aplicación Cumpleaños publique los próximos cumpleaños en su línea de tiempo de Facebook.
En su segunda oración, una declaración, usted dice que los propietarios de recursos y los clientes deben estar registrados en el servidor de autorización. Eso no es cierto: solo el propietario del recurso se registra. El cliente no se registra en Facebook, solo pide permiso para usarlo para publicar algo en la línea de tiempo de alguien. (En realidad, esto no es cierto. Pero explicarlo ahora lo confundiría, así que lo explico más tarde. En realidad, ambas oraciones son ciertas. Solo quería agregar drama a su pregunta. De todos modos, los detalles se explican mejor más adelante .)
En su próxima pregunta sobre las mejores prácticas: para los propósitos de OAuth, esa no es su preocupación: el servidor de recursos se encarga de eso. Ninguna aplicación de Facebook se preocupa por los usuarios que no están registrados en Facebook. Si lo fueran, entonces le dicen al usuario (el propietario que aún no tiene los recursos) que se registre en Facebook antes de usar la aplicación. Eso probablemente responde a su pregunta: usted le dice al usuario que debe registrarse con Facebook (o algún otro servidor de recursos que admita).
En cuanto a los servicios web populares que implementan esto, eso depende de lo que entiendas por “implementar”. Si te refieres a la aplicación, entonces no hay implementación, aunque mi comentario anterior sobre las mejores prácticas es probablemente la mejor manera. Si te refieres a cómo implementar OAuth, ese es un libro en sí mismo.
En cuanto a las aplicaciones web populares que implementan esto, también es un libro, pero puedo explicarlo brevemente. Usemos la aplicación Cumpleaños y Facebook como ejemplo.
Digamos que escribí la aplicación Cumpleaños. Y digamos que tienes una cuenta de Facebook.
Supongamos que ve un enlace que lo invita a instalar mi aplicación en su Facebook que lo contactará para recordarle que uno de los cumpleaños de su amigo es hoy.
Mi aplicación quiere escribir en tu línea de tiempo de Facebook.
No sé quién está usando mi aplicación, por lo que no tengo su nombre de usuario y contraseña. No sabes quién soy, solo conoces esta aplicación genial. Pero también le preocupa darme su nombre de usuario y contraseña de Facebook, porque no sabe quién soy y le preocupa lo que le sucede a mi aplicación si tiene que cambiar las contraseñas, y le preocupa lo que le sucede a su Contraseña de Facebook si lees el Wall Street Journal sobre un escándalo de piratas informáticos que involucra a mi aplicación (que sabes que tiene tu contraseña de Facebook) Y te preocupas por mi personaje: ¿voy a robar tu contraseña y hacer cosas no naturales con tu cuenta de Facebook?
OAuth aborda tus miedos. Hace clic en mi aplicación; mi aplicación le pregunta a Facebook si puede escribir en su línea de tiempo. Facebook le dice a mi aplicación: “Espera un segundo, déjame averiguarlo. BRB …” Facebook, mientras tanto, te envía un mensaje (¿estás en la computadora, verdad? ¡Así es como mi aplicación le pidió permiso a Facebook! ) Y si aún no ha iniciado sesión, primero le pide que inicie sesión. Cuando / después de haber iniciado sesión, Facebook le pregunta: “¡Hola! La aplicación Cumpleaños quiere escribir en su línea de tiempo y acceder a los perfiles de sus amigos (aparentemente quiere sus cumpleaños). ¿Quieres permitir esto? ” Si dice “No”, entonces todas las apuestas están apagadas y Facebook regresa a mi aplicación y le dice que se apague.
Si dice “sí”, Facebook le da a mi aplicación Cumpleaños un código de autorización. Ahora mi aplicación puede hacer todo lo que dice que haría. Accede de inmediato a su lista de amigos de Facebook, buscando los cumpleaños de hoy. Pero acceder a tu Facebook no es un proceso simple: ¿Recuerdas ese código de autorización? Ese es un artículo de corta duración. Es como un cupón de Walgreen en el acto, válido solo por los próximos 10 minutos. Si este código de autorización fuera válido para siempre, entonces, este protocolo sería una víctima de un ataque de repetición o un ataque de hombre en el medio que un pirata informático podría usar para obtener acceso a su cuenta. Por lo tanto, mi aplicación tiene aproximadamente 10 minutos para usar el código de autorización e intercambiarlo por un token de acceso, que tiene mucha más flexibilidad en términos de cuándo se puede usar. (El código de autorización y el token de acceso solo se pueden usar una vez. A partir de entonces, no son válidos. El servidor de recursos en realidad mantiene una base de datos de estas cosas, o estos tienen códigos incorporados para determinar cuándo son válidos e inválidos).
Ahora mi aplicación ha cambiado un código de autorización para un token de acceso. El token de acceso es la clave del proceso: lo usa para hacer lo que le dijo que haría. Entonces, mi aplicación puede intercambiar el código de autorización para el token de acceso.
Quizás estés pensando, ¿no podría un hacker robar mi código de autorización también?
OAuth también pensó en eso. Para que el código de autorización se cambie por un token de acceso, mi aplicación también debe proporcionar algunos detalles de registro que se le dieron cuando se registró en Facebook.
(Oh, ¿olvidé mencionar ese pequeño detalle? Esa fue la parte dramática de su pregunta. Aquí está la explicación: tuve que escribir una aplicación, luego ir a Facebook y decirle que estoy escribiendo esta aplicación genial que recuerda a la gente de los cumpleaños de sus amigos. Facebook examina mi aplicación, le da varios identificadores (una identificación de cliente y un secreto de cliente). Ahí, ahora ya lo sabe. Así es como registra un cliente en el servidor de recursos).
Los detalles de registro que utiliza mi aplicación para intercambiar el código / token es mi identificación de cliente y secreto de cliente. Facebook sabe que le diste permiso a mi aplicación, y sabe que mi aplicación ha sido examinada. Ninguna otra aplicación puede hacer esto, a menos que también conozca mi ID de cliente y mi secreto. Y, el token de acceso así intercambiado también es bueno para un solo uso. ¿Y adivina qué?
Solo lo usamos.
Entonces, ¿cómo verifica mi aplicación los cumpleaños mañana cuando inicias sesión?
Bueno, cuando mi aplicación accedió a los cumpleaños de tus amigos hoy, parte de ese intercambio de datos también incluye lo que se llama un “token de actualización”. No todos los sistemas usan esto, pero Facebook sí.
Mantengo este token de actualización seguro. Es bueno para un uso hasta 60 días después de los cuales caducará. Eso significa que tiene hasta 60 días sin iniciar sesión en Facebook antes de que caduque mi token de actualización, y tengo que volver al principio y pedir permiso nuevamente. Además, cualquier hacker que encuentre el token de actualización puede usarlo y puede usarlo para obtener más tokens de acceso. Así que cuídalo con seguridad. Puede comprarlos y venderlos en eBay, si sabe lo que está haciendo. En la práctica, se implementan como “tokens al portador”, que tienen una nomenclatura similar a los “bonos al portador”. Lo cual no es sorprendente, porque los tokens al portador son como bonos al portador que son como efectivo porque cualquiera que los posea puede usarlos, sin hacer preguntas.
Mañana, mi aplicación usará el token de actualización y lo cambiará por un token de acceso, y usará el token de acceso resultante para verificar los cumpleaños de tus amigos mañana. (Y eso producirá otro token de actualización, que debo guardar para usar en el día después de mañana. Y así sucesivamente, hasta la saciedad).
¡Eso es!
