estandar - oauth2
OAuth: ¿qué es exactamente un propietario de un recurso? ¿Cuándo no es un usuario final? (6)
El término "propietario del recurso" se define en la Especificación OAuth v2.0 como "Una entidad que puede otorgar acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se lo denomina usuario final".
Mi pregunta es, ¿cuándo el propietario de un recurso no es un usuario final? Agradecería la explicación a través de ejemplos que podrían ser casos de uso real. Por ejemplo, si el recurso protegido es la foto de un usuario de Facebook, ¿el propietario del recurso es Facebook o el usuario de Facebook que subió la foto? Además, ¿por qué el propietario del recurso (que también es una persona) se considera un usuario final si esa persona ni siquiera es un usuario de la aplicación que está implementando OAuth? Y, si el usuario de Facebook es el propietario del recurso, ¿qué papel desempeña Facebook en este intercambio?
Mi empresa colabora con un proveedor de videoconferencias para compartir pantalla. Nuestros usuarios pueden usar su solución como parte de nuestra oferta. La comunicación entre nosotros y la herramienta de terceros se realiza a través de llamadas a una API, utilizando OAuth de 2 patas.
No somos una persona, una mejor redacción es quizás un sistema externo, pero definitivamente somos propietarios de recursos, ya que pagamos los recursos que utilizamos y somos la entidad que autoriza las llamadas a las API.
Además, en el ejemplo de Facebook que mencionas. El propietario del recurso es la persona que cargó la foto. Esa persona también es el usuario final. El que beneficia a una aplicación de terceros emite llamadas API.
De la especificación:
Propietario del recurso : una entidad que puede otorgar acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se lo conoce como un usuario final
De esta definición, leí que muchas entidades pueden ser capaces de otorgar acceso a un recurso protegido.
Como ha notado, los ejemplos humanos son fáciles de asimilar: cuando solicita acceso a mi foto protegida, solo una entidad puede otorgar acceso. Esa entidad soy yo. Debo realizar alguna acción para otorgar su solicitud. Dependiendo de la aplicación, esto puede implicar hacer clic en un botón, enviar un mensaje de texto, hablar, aplaudir, lo que sea. El mecanismo por el cual mi acción es capturada y procesada no es relevante para esta definición.
Continuando con este ejemplo, digamos que otra entidad podría otorgar acceso a mi foto protegida. Imagine que es un socio de negocios de confianza del servicio de alojamiento de fotos. O tal vez sea otro equipo en la empresa de alojamiento de fotos, y sus servidores operan dentro del mismo centro de datos. En este escenario, podría ser conveniente otorgarle permiso automáticamente a la foto protegida. Si el servidor de recursos decidió otorgarle acceso automáticamente (por ser quien es), esto representaría una segunda entidad. Aquí, esta entidad no humana ha decidido (en toda su sabiduría) que su solicitud de acceso debe ser aceptada automáticamente.
Considere la situación en la que el propietario de un recurso es una corporación, tal vez una con una política que habilite / deshabilite el acceso a un recurso.
Considera un ejemplo de arte; digamos que quieres hacer que tu domicilio se vea mejor con una obra de arte; hay varios lugares a los que puede ir (Costco, por ejemplo) donde puede elegir una obra de arte, imprimirla en el medio de su elección del tamaño que desee y entregarla en su casa.
Aquí está la cosa; Costco no es el propietario de los derechos de licencia para esa obra de arte; eso está fuera del ámbito de sus negocios. Venden cosas, no coleccionan arte. Lo que hacen es negociar con el propietario del contenido (propietario de la licencia del arte) los derechos para usar ese arte en una impresión, que luego le crean y le entregan. Usted paga a Costco por la obra de arte; Luego, Costco le paga al licenciante una parte de su pago por el derecho de usar la obra de arte.
Esto también funciona en la situación en la que ya tiene una relación con el propietario del recurso; digamos que negoció y compró los derechos de música, por ejemplo. Usted no es el propietario de la música, ya que no tiene derecho a revenderla; pero usted tiene los derechos para escucharlo (esta es una situación estándar de DRM). Ahora digamos que quieres reproducir esa música a través de un sitio web; puede hacer una solicitud al sitio web para esa música; el sitio web puede ponerse en contacto con el propietario del contenido (licenciante, en realidad, pero es efectivamente el mismo) con su identificación; el propietario del contenido puede decidir si otorga o no acceso al sitio web de su parte al contenido, en función de sus términos.
Espero que aclare algunas cosas.
El propietario del recurso puede ser una máquina, no solo personas. Hay muchos casos en los que no hay seres humanos involucrados en todo el flujo de OAuth, especialmente en configuraciones empresariales. Al menos, eso es lo que quise decir cuando introduje el término en RFC 5849 (y más tarde en OAuth 2.0).
Me gustaría enfatizar la sólida respuesta de @Paul Sonier con un ejemplo más concreto relacionado con OAuth 2.0.
En una configuración empresarial, los empleados de una empresa pueden querer acceder al contenido en un servicio de almacenamiento de archivos (por ejemplo, Google Drive, Box.com, DropBox, etc.) bajo la égida de la cuenta empresarial de la empresa.
Dichos servicios pueden tener ya arreglos de inicio de sesión único donde las cuentas de los usuarios con el proveedor del servicio se aprovisionan dinámicamente o se aprovisionan a granel.
Es importante destacar que los empleados suelen firmar todos los derechos sobre los documentos u otros trabajos que producen para la empresa. En un sentido legal, la empresa y no el usuario final es el propietario del recurso.
En tal situación, el paso de autorización de OAuth2 es superfluo. La compañía, en su contrato con el proveedor del servicio, podría razonablemente decir: "considere cualquier sesión de usuario autenticada desde nuestro IDP como preautorizada para todas nuestras aplicaciones". Un proveedor de servicios simplemente podría omitir el paso de autorización para estas aplicaciones y, por cierto, salvar a miles de empleados un paso confuso y muchas llamadas al servicio de asistencia técnica, etc.
Al final del día, una autorización solo otorga una entrada en un almacén de datos y está sujeta a políticas que están fuera de las especificaciones de OAuth 2.0. No hay nada en las especificaciones de OAuth 2.0 que impida o desaliente tal "autorización masiva". Es solo una cuestión de acuerdo entre el proveedor del servicio y el verdadero propietario del recurso.
Tenga en cuenta que esta autorización de nivel de aplicación es distinta de los permisos de archivos y directorios, que generalmente también se administran fuera de banda. Es decir, los servicios de almacenamiento proporcionan una interfaz de usuario para administrar el acceso de usuarios y grupos a archivos y directorios. Los clientes OAuth 2.0, entonces, adquieren tokens de nivel de usuario (la mayoría solo admiten el tipo de concesión de "código de autorización" orientado al consumidor).
Considera que tienes una aplicación de Facebook.
Ahora desea obtener estadísticas (en otras palabras, "Estadísticas" ) sobre la actividad de todos los usuarios.
En este caso, el recurso ( "Información de la aplicación" ) es propiedad de su aplicación, no de cada usuario.
Por lo tanto, su aplicación obtiene un token de acceso de cliente (llamado OAuth de 2 patas) y accede a sus ideas.
Facebook también proporciona "Estadísticas de la página" como un recurso que es la actividad de los fanáticos de una página. En este caso, el recurso es propiedad de una página, no de los fanáticos de la página, por lo que su aplicación obtiene el token de acceso de la página .
Sin embargo, puedo entender tu confusión.
Anteriormente, Facebook permitía el acceso a las estadísticas de página mediante el token de acceso del propietario de la página o el token de acceso a la página (significa que Facebook lo manejó como un recurso tanto de la página como del propietario de la página; ahora solo se permite el token de acceso a la página).
Por fin, en todos los casos, Facebook actúa como "Servidor de autorización" y "Servidor de recursos" . Autentica a los usuarios y obtiene la aprobación del acceso del cliente a sus recursos. (Servidor de autorización). También sirve recursos. (Servidor de recursos)