¿La especificación de OpenID Connect Core define incorrectamente el proveedor de OpenID y la parte que confía en términos de participantes humanos?

1

Hay algunas definiciones importantes en la especificación de OpenID Connect Core que se refieren a un humano participante, y a primera vista parece que OpenID Connect solo se aplica en los casos en que hay un participante humano, pero esto no es cierto en la práctica. ¿Están estos términos definidos incorrectamente en términos de participación humana, y deberían haberse definido de manera más general para abarcar el uso donde no hay participación humana?

Aquí están las definiciones, con otros términos definidos también en negrita (esas definiciones también se enumeran a continuación):

  • Usuario final : participante humano
  • Proveedor de OpenID : OAuth 2.0 Servidor de autorización que es capaz de autenticar el usuario final y proporcionar reclamaciones a una Parte que confía sobre el evento Autenticación y el Usuario final
  • Parte dependiente : OAuth 2.0 Cliente que requiere la aplicación de usuario final autenticación y reclamaciones en un proveedor de OpenID

A pesar de la existencia de las definiciones de los términos centrados en el ser humano anteriores, hay muchas otras definiciones relevantes en la especificación que expresan explícitamente o implican que un participante humano es innecesario. Dadas estas definiciones adicionales (ver más abajo), está claro que el uso de OAuth 2 / OpenID Connect en un contexto sin interacción humana es razonable, y de hecho, es ampliamente compatible. Aquí están esas definiciones:

  • Entidad : algo que tiene una existencia separada y distinta y que se puede identificar en un contexto. Un usuario final es un ejemplo de una entidad (lo que implica que hay otros ejemplos que no son participantes humanos) .
  • Token de ID : JSON Web Token (JWT) que contiene Reclamaciones sobre el evento Autentificación . PUEDE contener otras Reclamaciones .
  • Autenticación : proceso utilizado para lograr la suficiente confianza en el enlace entre la Entidad y la Identidad presentada.
  • Identidad : conjunto de atributos relacionados con una Entidad .
  • Reclamación : pieza de información afirmada sobre una Entidad .

La especificación OpenID Connect Core utiliza varios términos definidos por la especificación OAuth 2 que apoyan la noción de interacción sin la participación humana :

  • Propietario del recurso : Entidad capaz de otorgar acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se le conoce como usuario final (lo que implica que hay otros ejemplos que no son personas) . / li>
  • Servidor de recursos : el servidor aloja recursos protegidos, capaz de aceptar y responder a solicitudes de recursos protegidos utilizando Tokens de acceso .
  • Cliente : la aplicación realiza solicitudes de recursos protegidos en nombre del propietario del recurso y con su autorización.
  • Servidor de autorización : el servidor emite tokens de acceso al cliente después de autenticar con éxito al propietario del recurso y obtener la autorización
  • Token de acceso : credenciales utilizadas para acceder a los recursos protegidos; es una cadena que representa una autorización emitida al Cliente .

Teniendo en cuenta todo esto, no puedo evitar pensar que las definiciones de Proveedor de OpenID y Parte que confía deberían haberse referido a Entidad en lugar de usuario final . ¿Estoy en lo correcto?

    
pregunta rndgstn 04.03.2018 - 17:09
fuente

2 respuestas

1

No, las definiciones son correctas.

Tenga en cuenta que una parte que confía no se autentica, sino que se autoriza a través del proceso en el que el usuario final se autenticó y luego proporcionó una autorización (en forma de token) a la parte confiada.

Más aclaraciones sobre su comentario final:

  • El proveedor de OpenID no autentica ninguna entidad, es específicamente un servidor de autorización capaz de autenticar a un USUARIO FINAL humano.
  • La parte que confía es una aplicación que se ejecuta en un servidor o en el dispositivo de un usuario. Un usuario humano debe autenticarse antes de que se proporcione un token a la parte que confía, de ahí el usuario final de trabajo en la definición.
respondido por el Johan 05.03.2018 - 10:05
fuente
-1

El proveedor de OpenID es un servidor.

Relying Party es una aplicación.

Claro, los servidores y las aplicaciones no aparecen por sí solos. Los humanos desarrollan aplicaciones, los humanos los implementan y configuran, los humanos definen políticas de seguridad. Pero no consideramos cómo se configuró . Consideramos cómo actúa .

    
respondido por el mentallurg 03.06.2018 - 12:59
fuente

Lea otras preguntas en las etiquetas