¿Cuál es la diferencia entre Basic Auth, Digest Auth, oAuth1.0 y oAuth2.0? ¿Cuál es un ejemplo de cada uno en el núcleo de PHP?

Bueno, no soy un chico PHP, pero definitivamente puedo proporcionar la diferencia

Existen 2 tipos de autenticación cuando se trata de aplicaciones / servicios web, ya sea que se base en PHP, Node.js o Java.

Autenticación básica: el uso de HTTP puede funcionar con el navegador (antiguo y nuevo), incluso con aplicaciones como Excel como cliente. Utiliza reinos de servidores web como UserRealm basado en Tomcat o JDBCRealm. El inconveniente es que envía la contraseña como texto sin cifrar, que fuera de curso puede ser remediado por HTTPS.

• ¿Cómo puede haber una clase de una clase de objetos en la teoría de conjuntos?
• Cómo usar el lenguaje C para escribir un programa para hacer una matriz de multiplicación que permita 1, 2, 3, 4, 5, 6 o 7 hilos que corren paralelos
• ¿Por qué la teoría de la medida es más común en economía que en informática?
• ¿En qué se diferencian las mónadas del encadenamiento?
• Cómo calcular los componentes conectados, sin usar la función nx.connected_components (g) en NetworkX

Nonce based: Básicamente, acceda a la autenticación y autorización posterior emitida basada en token. Hay 2 tipos de marcos de autenticación basados ​​en tokens, Digest y OAuth (1.0 y 2.0)

• Basado en resumen: resumen simplemente significa un hash de nombre de usuario, reino, contraseña). Aquí esta el flujo

1. El cliente hace la solicitud
2. El cliente recupera un nonce del servidor y una solicitud de autenticación 401
3. El cliente devuelve la siguiente matriz de respuestas (nombre de usuario, reino, generate_md5_key (nonce, nombre de usuario, reino, URI, contraseña_given_by_user_to_browser)) (sí, eso es muy simplificado)
4. El servidor toma el nombre de usuario y el reino (además conoce el URI que solicita el cliente) y busca la contraseña para ese nombre de usuario. Luego va y hace su propia versión de generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
5. Compara la salida de generate_md5 () que obtuvo con la que envió el cliente, si coinciden, el cliente envió la contraseña correcta. Si no coinciden, la contraseña enviada fue incorrecta.

• OAuth 1.0: Básicamente, OAuth es cuando la aplicación se autentica en otra aplicación. Al igual que Spotify (consumidor) publica en Twitter usando su cuenta de Twitter (Ajit, usuario) de Twitter (proveedor de servicios). No comparte la identificación de usuario y la contraseña. Aquí esta el flujo

1. El usuario le dice al consumidor que manipule su cuenta basada en el proveedor de servicios
2. El consumidor solicita acceso al proveedor de servicios.
3. El proveedor de servicios se autentica, pasa un token generado y una clave secreta. El consumidor tiene que usar la clave secreta cada vez que se conecta / se comunica con el proveedor de servicios. Esto es por la autenticidad del consumidor al proveedor de servicios
4. El consumidor redirige al usuario al sitio web del proveedor de servicios con el token
5. El consumidor obtiene la aprobación de Twitter para usar la cuenta con token
6. Spotify lo usa para seguir adelante.
7. OAuth 1.0 ha sido reemplazado por OAuth 2.0, especialmente para ECommerce 3.0.

• OAuth 2.0: (Comparado con OAuth 1.0, soporte para token de corta duración que no es del navegador).

1. Permite al propietario del recurso (usuario final, Joe con cuenta de Twitter), utilizando el agente de usuario (navegador, móvil, aplicación), permitir que el cliente / consumidor (consumidor de API, Spotify) acceda a un recurso en el servidor (API / servicio
2. Proveedor) usando credenciales almacenadas en un servidor de autorización. El acceso a los
3. El recurso protegido es a través del token de acceso.
4. El usuario le dice a Consumer (Spotify) que manipule su cuenta basada en el proveedor de servicios (Twitter) a través del navegador.
5. El agente de usuario se conecta a un URI del navegador proporcionado por el consumidor.
6. El consumidor luego redirige al servidor de autorización con información adicional como client_id, permisos solicitados, URI de redireccionamiento
7. El servidor de autorizaciones autoriza al propietario de los recursos haciendo autenticación y verificando / confirmando la acción solicitada.
8. En caso de éxito, redirige al agente de usuario nuevamente a la URL del cliente agregando un código de autorización a la url
9. La redirección es un script del lado del servidor (JSP, Servlet) en el servidor del consumidor que luego solicitará un token de acceso usando POST al servidor de autorización.
10. La autorización responde con un token de acceso y una fecha de vencimiento.

Espero que esto ayude
Ajit