¿Cuál es la diferencia entre OpenID y OAuth?

Realmente estoy tratando de entender la diferencia entre OpenID y OAuth? ¿Quizás son dos cosas totalmente separadas?

OpenID se trata de autenticación (es decir, demostrar quién eres), OAuth se trata de autorización (es decir, otorgar acceso a la funcionalidad / datos / etc. sin tener que lidiar con la autenticación original).

OAuth podría usarse en sitios de socios externos para permitir el acceso a datos protegidos sin que tengan que volver a autenticar a un usuario.

La publicación del blog " OpenID versus OAuth desde la perspectiva del usuario " tiene una comparación simple de los dos desde la perspectiva del usuario y " OAuth-OpenID: Estás ladrando el árbol equivocado si crees que son lo mismo " tiene más información al respecto

Hay tres formas de comparar OAuth y OpenID:

1. Propósitos

OpenID se creó para la autenticación federada, es decir, permitir que un tercero autentique a sus usuarios por usted, utilizando cuentas que ya tienen . El término federado es crítico aquí porque el objetivo de OpenID es que se puede usar cualquier proveedor (con la excepción de las listas blancas). No necesita preseleccionar o negociar un acuerdo con los proveedores para permitir que los usuarios usen cualquier otra cuenta que tengan.

OAuth se creó para eliminar la necesidad de que los usuarios compartan sus contraseñas con aplicaciones de terceros . En realidad, comenzó como una forma de resolver un problema de OpenID: si admite OpenID en su sitio, no puede usar las credenciales HTTP básicas (nombre de usuario y contraseña) para proporcionar una API porque los usuarios no tienen una contraseña en su sitio.

El problema con esta separación de OpenID para autenticación y OAuth para autorización es que ambos protocolos pueden lograr muchas de las mismas cosas. Cada uno de ellos proporciona un conjunto diferente de características deseadas por diferentes implementaciones, pero esencialmente son bastante intercambiables. En esencia, ambos protocolos son un método de verificación de afirmación (OpenID se limita a la afirmación 'esto es quién soy', mientras que OAuth proporciona un 'token de acceso' que se puede intercambiar por cualquier afirmación compatible a través de una API).

2. Características

Ambos protocolos proporcionan una manera para que un sitio redirija a un usuario a otro lugar y regrese con una afirmación verificable. OpenID proporciona una afirmación de identidad, mientras que OAuth es más genérico en forma de un token de acceso que luego se puede utilizar para "hacer preguntas al proveedor de OAuth" . Sin embargo, cada uno admite diferentes características:

OpenID : la característica más importante de OpenID es su proceso de descubrimiento. OpenID no requiere una codificación rígida de cada uno de los proveedores que desea utilizar con anticipación. Mediante el descubrimiento, el usuario puede elegir cualquier proveedor de terceros que desee autenticar. Esta característica de descubrimiento también ha causado la mayoría de los problemas de OpenID porque la forma en que se implementa es mediante el uso de URI HTTP como identificadores que la mayoría de los usuarios web simplemente no obtienen. Otras características que OpenID tiene es su soporte para el registro de clientes ad-hoc usando un intercambio DH, modo inmediato para una experiencia optimizada para el usuario final y una forma de verificar las afirmaciones sin hacer otro viaje de ida y vuelta al proveedor.

OAuth : la característica más importante de OAuth es el token de acceso que proporciona un método duradero para realizar solicitudes adicionales. A diferencia de OpenID, OAuth no termina con la autenticación, sino que proporciona un token de acceso para obtener acceso a recursos adicionales proporcionados por el mismo servicio de terceros. Sin embargo, dado que OAuth no admite el descubrimiento, requiere la preselección y la codificación de los proveedores que decida utilizar. Un usuario que visita su sitio no puede usar ningún identificador, solo aquellos preseleccionados por usted. Además, OAuth no tiene un concepto de identidad, por lo que usarlo para iniciar sesión significa agregar un parámetro personalizado (como lo hizo Twitter) o realizar otra llamada a la API para obtener el usuario actualmente "conectado".

3. Implementaciones técnicas

Los dos protocolos comparten una arquitectura común al usar la redirección para obtener la autorización del usuario. En OAuth, el usuario autoriza el acceso a sus recursos protegidos y en OpenID, a su identidad. Pero eso es todo lo que comparten.

Cada protocolo tiene una forma diferente de calcular una firma utilizada para verificar la autenticidad de la solicitud o respuesta, y cada uno tiene diferentes requisitos de registro.

OpenID es (principalmente) para identificación / autenticación, por lo que stackoverflow.comsabe que soy el propietario chris.boyle.name(o donde sea) y, por lo tanto, que probablemente soy la misma persona que chris.boyle.nameayer poseía y ganó algunos puntos de reputación.

OAuth está diseñado para la autorización para tomar medidas en su nombre, de modo que stackoverflow.com(o donde sea) pueda pedir permiso para, por ejemplo, tuitear en su nombre automáticamente, sin conocer su contraseña de Twitter.

Mucha gente todavía visita esto, así que aquí hay un diagrama muy simple para explicarlo.

Cortesía de Wikipedia

OAuth

Se usa authorizationsolo para delegados , lo que significa que está autorizando el acceso a un servicio de terceros para usar datos personales, sin proporcionar una contraseña. También las "sesiones" de OAuth generalmente viven más tiempo que las sesiones de usuario. Lo que significa que OAuth está diseñado para permitir la autorización

es decir, Flickr usa OAuth para permitir que servicios de terceros publiquen y editen una imagen de personas en su nombre, sin que tengan que dar su nombre de usuario y contraseña de parpadeo.

OpenID

Se utiliza para la authenticateidentidad de inicio de sesión único. Todo lo que se supone que OpenID debe hacer es permitir que un proveedor de OpenID demuestre que usted lo dice. Sin embargo, muchos sitios usan autenticación de identidad para proporcionar autorización (sin embargo, los dos se pueden separar)

es decir, uno muestra su pasaporte en el aeropuerto para autenticar (o probar) el nombre de la persona que figura en el boleto que está usando.

Use OAuth si sus usuarios solo desean iniciar sesión con Facebook o Twitter. Use OpenID si sus usuarios son barbaros que ejecutan sus propios proveedores de OpenID porque "no quieren que nadie más sea dueño de su identidad".

• OpenID es un protocolo de autenticación descentralizado y estándar abierto controlado por la Fundación OpenID.
• OAuth es un estándar abierto para la delegación de acceso.
• OpenID Connect (OIDC) combina las características de OpenID y OAuth, es decir, realiza autenticación y autorización.

OpenID toma la forma de un URI único administrado por algún "proveedor de OpenID", es decir, un proveedor de identidad (idP).

OAuth se puede usar junto con XACML donde OAuth se usa para el consentimiento de propiedad y la delegación de acceso, mientras que XACML se usa para definir las políticas de autorización.

OIDC utiliza JSON Web Tokens (JWT) simples, que puede obtener utilizando flujos que cumplan con las especificaciones de OAuth 2.0 . OAuth está directamente relacionado con OIDC ya que OIDC es una capa de autenticación construida sobre OAuth 2.0 .

Por ejemplo , si elige iniciar sesión en Auth0 usando su cuenta de Google, entonces usó OIDC . Una vez que se autentique con éxito con Google y autorice a Auth0 a acceder a su información, Google enviará de vuelta a Auth0 información sobre el usuario y la autenticación realizada. Esta información se devuelve en un token web JSON (JWT). Recibirá un token de acceso y, si se solicita, un token de identificación. Tipos de token : Fuente: OpenID Connect

Analogía :
Un uso organización ID tarjeta para fines de identificación y contiene virutas, almacena detalles acerca de los empleados junto con Autorización es decir / acceso Campus Puerta / ODC. La tarjeta de identificación actúa como un OIDC y el chip actúa como un OAuth . más ejemplos y wiki de formulario

OpenID y OAuth son protocolos basados ​​en HTTP para autenticación y / o autorización. Ambos están destinados a permitir a los usuarios realizar acciones sin dar credenciales de autenticación o permisos generales a clientes o terceros. Si bien son similares, y hay estándares propuestos para usarlos juntos, son protocolos separados.

OpenID está destinado a la autenticación federada. Un cliente acepta una afirmación de identidad de cualquier proveedor (aunque los clientes son libres de incluir en la lista blanca o en la lista negra a los proveedores).

OAuth está destinado a la autorización delegada. Un cliente se registra con un proveedor, que proporciona tokens de autorización que aceptará para realizar acciones en nombre del usuario.

Actualmente, OAuth es más adecuado para la autorización, porque las interacciones posteriores a la autenticación están integradas en el protocolo, pero ambos protocolos están evolucionando. OpenID y sus extensiones podrían usarse para autorización, y OAuth puede usarse para autenticación, lo que puede considerarse como una autorización no operativa.

Creo que tiene sentido revisar esta pregunta como también se señaló en los comentarios, la introducción de OpenID Connect puede haber traído más confusión.

OpenID Connect es un protocolo de autenticación como OpenID 1.0 / 2.0, pero en realidad está construido sobre OAuth 2.0, por lo que obtendrá funciones de autorización junto con funciones de autenticación. La diferencia entre los dos está bastante bien explicada en detalle en este artículo (relativamente reciente, pero importante): http://oauth.net/articles/authentication/

La explicación de la diferencia entre OpenID, OAuth, OpenID Connect:

OpenID es un protocolo para autenticación mientras que OAuth es para autorización. La autenticación se trata de asegurarse de que el tipo con el que está hablando sea realmente quien dice ser. La autorización se trata de decidir qué se le debe permitir a ese tipo hacer.

En OpenID, la autenticación se delega: el servidor A quiere autenticar al usuario U, pero las credenciales de U (por ejemplo, el nombre y la contraseña de U) se envían a otro servidor, B, en el que A confía (al menos, confía en autenticar a los usuarios). De hecho, el servidor B se asegura de que U sea realmente U, y luego le dice a A: "ok, esa es la U genuina".

En OAuth, la autorización se delega: la entidad A obtiene de la entidad B un "derecho de acceso" que A puede mostrar al servidor S para obtener acceso; B puede así entregar claves de acceso temporales y específicas a A sin darles demasiada potencia. Puedes imaginar un servidor OAuth como el maestro clave en un gran hotel; da a los empleados las llaves que abren las puertas de las habitaciones en las que se supone que deben ingresar, pero cada llave es limitada (no da acceso a todas las habitaciones); Además, las teclas se autodestruyen después de unas horas.

Hasta cierto punto, se puede abusar de la autorización en alguna pseudo-autenticación, sobre la base de que si la entidad A obtiene de B una clave de acceso a través de OAuth y la muestra al servidor S, entonces el servidor S puede inferir que B autenticó A antes de otorgar el acceso llave. Entonces, algunas personas usan OAuth donde deberían estar usando OpenID. Este esquema puede o no ser esclarecedor; Pero creo que esta pseudo-autenticación es más confusa que cualquier otra cosa. OpenID Connect hace exactamente eso: abusa de OAuth en un protocolo de autenticación. En la analogía del hotel: si me encuentro con un supuesto empleado y esa persona me muestra que tiene una llave que abre mi habitación, entonces supongo que este es un verdadero empleado, sobre la base de que el maestro de llaves no le habría dado una llave. que abre mi habitación si no lo estaba.

(fuente)

¿En qué se diferencia OpenID Connect de OpenID 2.0?

OpenID Connect realiza muchas de las mismas tareas que OpenID 2.0, pero lo hace de una manera amigable con la API y utilizable por aplicaciones nativas y móviles. OpenID Connect define mecanismos opcionales para la firma robusta y el cifrado. Mientras que la integración de OAuth 1.0a y OpenID 2.0 requería una extensión, en OpenID Connect, las capacidades de OAuth 2.0 están integradas con el protocolo mismo.

(fuente)

OpenID connect le dará un token de acceso más un token de identificación. El token de identificación es un JWT y contiene información sobre el usuario autenticado. Está firmado por el proveedor de identidad y se puede leer y verificar sin acceder al proveedor de identidad.

Además, OpenID connect estandariza un par de cosas que oauth2 deja a la elección. por ejemplo, ámbitos, descubrimiento de punto final y registro dinámico de clientes.

Esto facilita la escritura de código que permite al usuario elegir entre múltiples proveedores de identidad.

(fuente)

OAuth 2.0 de Google

Las API OAuth 2.0 de Google se pueden usar tanto para autenticación como para autorización. Este documento describe nuestra implementación de OAuth 2.0 para la autenticación, que se ajusta a la especificación OpenID Connect y cuenta con la certificación OpenID. La documentación que se encuentra en Uso de OAuth 2.0 para acceder a las API de Google también se aplica a este servicio. Si desea explorar este protocolo de forma interactiva, le recomendamos Google OAuth 2.0 Playground .

(fuente)

Más una extensión de la pregunta que una respuesta, pero puede agregar algo de perspectiva a las excelentes respuestas técnicas anteriores. Soy un programador experimentado en varias áreas, pero un novato total en la programación para la web. Ahora estoy tratando de construir una aplicación basada en web usando Zend Framework.

Definitivamente implementará una interfaz de autenticación de nombre de usuario / contraseña básica específica de la aplicación, pero reconoce que para un número creciente de usuarios la idea de otro nombre de usuario y contraseña es un elemento disuasorio. Si bien no es exactamente una red social, sé que un gran porcentaje de los usuarios potenciales de la aplicación ya tienen cuentas de Facebook o Twitter. La aplicación realmente no quiere o necesita acceder a información sobre la cuenta del usuario desde esos sitios, solo quiere ofrecer la comodidad de no requerir que el usuario configure nuevas credenciales de cuenta si no lo desea. Desde el punto de vista de la funcionalidad, parecería un elemento secundario para OpenID. Pero parece que ni Facebook ni Twitter son proveedores de OpenID como tales, aunque sí admiten la autenticación OAuth para acceder a los datos de sus usuarios.

En todos los artículos que he leído sobre los dos y en qué se diferencian, hasta que no vi la observación de Karl Anderson, "OAuth se puede utilizar para la autenticación, que se puede considerar como una autorización no operativa" que Vi una confirmación explícita de que OAuth era lo suficientemente bueno para lo que quería hacer.

De hecho, cuando fui a publicar esta "respuesta", no siendo miembro en ese momento, busqué largamente en la parte inferior de esta página las opciones para identificarme. La opción de usar un inicio de sesión de OpenID u obtener uno si no tenía uno, pero nada sobre Twitter o Facebook, parecía sugerir que OAuth no era adecuado para el trabajo. Pero luego abrí otra ventana y busqué el proceso de registro general para stackoverflow, y he aquí que hay una gran cantidad de opciones de autenticación de terceros que incluyen Facebook y Twitter. Al final, decidí usar mi identificación de Google (que es un OpenID) exactamente por la razón por la que no quería otorgar acceso a stackoverflow a mi lista de amigos y cualquier otra cosa que Facebook le gusta compartir sobre sus usuarios, pero al menos '

Realmente sería genial si alguien pudiera publicar información o punteros para obtener información sobre el soporte de este tipo de configuración de autorización múltiple de terceros, y cómo tratar con los usuarios que revocan la autorización o pierden el acceso a su sitio de terceros. También tengo la impresión de que mi nombre de usuario aquí identifica una cuenta de stackoverflow única a la que podría acceder con autenticación básica si quisiera configurarla, y también acceder a esta misma cuenta a través de otros autenticadores de terceros (por ejemplo, para que se me considere registrado en stackoverflow si estaba conectado a cualquiera de google, facebook o twitter ...). Como este sitio lo está haciendo, alguien aquí probablemente tenga una idea bastante buena sobre el tema. :-)

Lo siento, esto fue tan largo, y más una pregunta que una respuesta, pero el comentario de Karl hizo que pareciera el lugar más apropiado para publicar en medio del volumen de hilos en OAuth y OpenID. Si hay un lugar mejor para esto que no encontré, me disculpo de antemano, lo intenté.

OpenID demuestra quién eres.

OAuth otorga acceso a las funciones proporcionadas por la parte que autoriza.

Actualmente estoy trabajando en OAuth 2.0 y OpenID connect spec. Así que aquí está mi entendimiento: antes eran:

1. OpenID fue una implementación patentada de Google que permite que aplicaciones de terceros, como sitios web de periódicos, puedan iniciar sesión usando google y comentar un artículo, etc. en otros casos de uso. Básicamente, no se comparte contraseña en el sitio web del periódico. Permítanme poner una definición aquí, este enfoque en el enfoque empresarial se llama Federación. En la Federación, tiene un servidor donde se autentica y autoriza (denominado IDP, proveedor de identidad) y, en general, el guardián de las credenciales de usuario. la aplicación cliente donde tiene negocios se llama SP o proveedor de servicios. Si volvemos al mismo ejemplo del sitio web del periódico, el sitio web del periódico es SP aquí y Google es IDP. En la empresa, este problema se resolvió anteriormente con SAML. ese tiempo XML solía gobernar la industria del software. Entonces, desde los servicios web hasta la configuración, todo solía ir a XML, así que tenemos SAML,

2. OAuth: OAuth vio su surgimiento como un estándar que analiza todo este tipo de enfoques patentados y, por lo tanto, teníamos OAuth 1.o como estándar, pero solo abordaba la autorización. No mucha gente se dio cuenta, pero comenzó a recuperarse. Luego tuvimos OAuth 2.0 en 2012. Los CTOs, arquitectos realmente comenzaron a prestar atención a medida que el mundo se está moviendo hacia la computación en la nube y con los dispositivos informáticos hacia dispositivos móviles y otros dispositivos similares. OAuth se consideraba como la resolución de un problema importante en el que los clientes de software podrían brindar el servicio IDP a una compañía y tener muchos servicios de diferentes proveedores como salesforce, SAP, etc. Así que la integración aquí realmente parece un escenario de federación, un gran problema, usar SAML es costoso así que vamos a explorar OAuth 2.o. Ohh, perdí un punto importante que durante este tiempo, Google sintió que OAuth en realidad no

   a. OAuth 2.o no dice claramente cómo ocurrirá el registro del cliente b. no menciona nada acerca de la interacción entre SP (Resource Server) y la aplicación cliente (como Analytics Server que proporciona datos es Resource Server y la aplicación que muestra esos datos es Cliente)

Ya hay respuestas maravillosas dadas aquí técnicamente, pensé en dar una breve perspectiva de evolución

OpenId usa OAuth para lidiar con la autenticación.

Por analogía, es como .NET se basa en la API de Windows. Puede llamar directamente a la API de Windows, pero es tan amplio, complejo y los argumentos de método tan amplios que fácilmente podría cometer errores / errores / problemas de seguridad.

Lo mismo con OpenId / OAuth. OpenId se basa en OAuth para gestionar la autenticación, pero define un token específico (Id_token), firma digital y flujos particulares.

Me gustaría abordar un aspecto particular de esta pregunta, como se captura en este comentario:

OAuth: antes de otorgar acceso a alguna función, la autenticación debe hacerse, ¿verdad? entonces OAuth = ¿qué OpenId + otorga acceso a algunas funciones? - Hassan Makarov 21 de junio a las 1:57

Si y no. La respuesta es sutil, así que tengan paciencia conmigo.

Cuando el flujo de OAuth lo redirige a un servicio de destino (el proveedor de OAuth, es decir), es probable que deba autenticarse con ese servicio antes de que se devuelva un token a la aplicación / servicio del cliente. El token resultante permite que la aplicación cliente realice solicitudes en nombre de un usuario determinado.

Tenga en cuenta la generalidad de esa última oración: específicamente, escribí "en nombre de un usuario determinado", no "en nombre de usted ". Es un error común suponer que "tener la capacidad de interactuar con un recurso propiedad de un usuario determinado" implica "usted y el propietario de los recursos de destino son uno en el mismo".

No cometas este error.

Si bien es cierto que se autentica con el proveedor de OAuth (por ejemplo, por nombre de usuario y contraseña, o tal vez certificados de cliente SSL, o algún otro medio), lo que el cliente obtiene a cambio no necesariamente debe tomarse como prueba de identidad. Un ejemplo sería un flujo en el que se delegaba el acceso a los recursos de otro usuario (y por proxy, el cliente OAuth). La autorización no implica autenticación.

Para manejar la autenticación, es probable que desee ver OpenID Connect, que es esencialmente otra capa en la parte superior de la base establecida por OAuth 2.0. Aquí hay una cita que captura (en mi opinión) los puntos más destacados con respecto a OpenID Connect (de https://oauth.net/articles/authentication/ ):

OpenID Connect es un estándar abierto publicado a principios de 2014 que define una forma interoperable de usar OAuth 2.0 para realizar la autenticación del usuario. En esencia, es una receta ampliamente publicada para el dulce de chocolate que ha sido probada y probada por una gran cantidad y variedad de expertos. En lugar de crear un protocolo diferente para cada proveedor de identidad potencial, una aplicación puede hablar un protocolo a tantos proveedores como quieran trabajar. Dado que es un estándar abierto, OpenID Connect puede ser implementado por cualquier persona sin restricciones ni preocupaciones de propiedad intelectual.

OpenID Connect se basa directamente en OAuth 2.0 y, en la mayoría de los casos, se implementa junto con (o sobre) una infraestructura de OAuth. OpenID Connect también utiliza el conjunto de especificaciones JSON Object Signing And Encryption (JOSE) para transportar información firmada y encriptada en diferentes lugares. De hecho, una implementación de OAuth 2.0 con capacidades JOSE ya es un largo camino para definir un sistema OpenID Connect totalmente compatible, y el delta entre ambos es relativamente pequeño. Pero ese delta marca una gran diferencia, y OpenID Connect se las arregla para evitar muchas de las dificultades discutidas anteriormente al agregar varios componentes clave a la base de OAuth: [...]

Luego, el documento continúa describiendo (entre otras cosas) ID de token y un punto final UserInfo. El primero proporciona un conjunto de reclamos (quién es usted, cuándo se emitió el token, etc., y posiblemente una firma para verificar la autenticidad del token a través de una clave pública publicada sin tener que solicitar el servicio ascendente), y el último proporciona un significa, por ejemplo, preguntar por el nombre / apellido del usuario, correo electrónico y partes similares de información, todo de manera estandarizada (a diferencia de las extensiones ad-hoc de OAuth que la gente usaba antes de las cosas estandarizadas de OpenID Connect).

Ambos protocolos fueron creados por diferentes razones. OAuth fue creado para autorizar a terceros a acceder a los recursos. OpenID fue creado para realizar la validación descentralizada de identidad. Este sitio web establece lo siguiente:

OAuth es un protocolo diseñado para verificar la identidad de un usuario final y para otorgar permisos a un tercero. Esta verificación da como resultado un token. El tercero puede usar este token para acceder a los recursos en nombre del usuario. Las fichas tienen un alcance. El alcance se utiliza para verificar si un recurso es accesible para un usuario o no

OpenID es un protocolo utilizado para la autenticación descentralizada. La autenticación se trata de identidad; Establecer el usuario es, de hecho, la persona que dice ser. Descentralizar eso significa que este servicio desconoce la existencia de recursos o aplicaciones que necesitan protección. Esa es la diferencia clave entre OAuth y OpenID.

OpenID Connect amplía el protocolo de autorización OAuth 2.0 para usarlo como protocolo de autenticación, de modo que pueda hacer un inicio de sesión único con OAuth. OpenID Connect presenta el concepto de un token de ID, que es un token de seguridad que permite al cliente verificar la identidad del usuario

OAuth 2.0 es un protocolo de seguridad. NO es una autenticación ni un protocolo de autorización.

Autenticación por definición las respuestas dos preguntas.

1. Quien es el usuario?
2. ¿El usuario está actualmente presente en el sistema?

OAuth 2.0 tiene los siguientes tipos de subvención

• client_credentials: cuando una aplicación necesita interactuar con otra aplicación y modificar los datos de varios usuarios.
• autorización_código: el usuario delega el servidor de autorización para emitir un acceso_token que el cliente puede usar para acceder a recursos protegidos
• refresh_token: cuando expire access_token, se puede aprovechar el token de actualización para obtener un access_token nuevo
• contraseña: el usuario proporciona sus credenciales de inicio de sesión a un cliente que llama al servidor de autorización y recibe un access_token

Los 4 tienen una cosa en común, access_token, un artefacto que se puede usar para acceder a recursos protegidos.

Access_token no proporciona la respuesta a las 2 preguntas que debe responder un protocolo de "Autenticación".

Un ejemplo para explicar Oauth 2.0 (créditos: OAuth 2 en acción, publicaciones de Manning)

Hablemos de chocolate. Podemos hacer muchos dulces con chocolate, como dulce de azúcar, helado y pastel. Pero ninguno de estos puede equipararse al chocolate porque se necesitan muchos otros ingredientes, como la crema y el pan, para hacer el dulce, a pesar de que el chocolate suena como el ingrediente principal. Del mismo modo, OAuth 2.0 es el chocolate, y las cookies, la infraestructura de TLS, los proveedores de identidad son otros ingredientes que se requieren para proporcionar la funcionalidad de "autenticación".

Si desea la autenticación, puede optar por OpenID Connect, que proporciona un "id_token", además de un access_token, que responde a las preguntas que debe responder cada protocolo de autenticación.

OAuth crea la autenticación además de la autorización: el usuario delega el acceso a su identidad a la aplicación, que luego se convierte en un consumidor de la API de identidad, descubriendo así quién autorizó al cliente en primer lugar http://oauth.net/ artículos / autenticación /