español - que es api auth

Autenticación OpenID y acceso API (4)

La autenticación de OpenID está inherentemente basada en el navegador. Si quisiera permitir que un usuario de OpenID se autenticara frente a una API para usar en clientes alternativos, ¿existe una mejor práctica aceptada para eso?

Entonces, si un usuario intentara iniciar sesión con su OpenID en una aplicación de iPhone, por ejemplo, ¿cómo funcionaría? Lo único que se me ocurre es generar un token de API de algún tipo para ellos y hacer que el usuario lo ingrese manualmente en alguna parte. Este enfoque no es fácil de usar.

Esta es la forma en que funcionan sitios como Basecamp , pero aún me parece torpe.

Lo que quiere no es posible con OpenID. OpenID se basa en la premisa de que usted (la aplicación de iPhone) solo desea saber sobre sus usuarios que su proveedor de OpenID confía en ellos. Nunca se autentican a ti.

Los buenos proveedores de OpenID, de hecho, incluso evitan que medie en el proceso de autenticación (ya que esto expondría a los usuarios a un posible ataque: por usted): exigen que los usuarios inicien sesión directamente con ellos y rechacen el inicio de sesión por referencia.

El problema que está viendo no es exclusivo de OpenID. Cualquier esquema de autenticación sin contraseña puede tener este problema. OAuth ( http://oauth.net/ ) es una solución que es un estándar abierto que está ganando tracción rápidamente en una gran cantidad de sitios web. Es totalmente independiente de cómo se autentica el usuario, por lo que su proveedor de OpenID no necesita admitir ni siquiera ser consciente de que su sitio (el "proveedor de servicios" en términos de OAuth) está usando OAuth. ¡Su cliente de API puede estar basado en la web o incluso en una aplicación local!

El proceso sería algo como esto:

Roles:

el usuario: alguien que tiene una cuenta en su sitio web.
proveedor de servicios: su sitio web, que tiene una API programática que requiere alguna credencial para acceder.
consumidor: el cliente, ya sea la aplicación web o local, que necesita acceso a la API del proveedor de servicios.

Fluir:

El usuario está en el consumidor. Él indica que quiere acceder a los datos en el proveedor del servicio.
El usuario es redirigido (si el consumidor es un sitio web) o aparece un navegador (si el consumidor es una aplicación local) y el usuario ve el sitio web del proveedor del servicio.
El usuario ya inició sesión en el Proveedor de servicios a través de una cookie persistente, o el usuario primero debe iniciar sesión en el Proveedor de servicios sin embargo, eso se hace (OpenID en su caso).
El proveedor de servicios luego pregunta al usuario: "El consumidor (algún consumidor) quiere acceder a sus datos (o a nuestra API, o lo que sea). ¿Desea autorizar esto? (Sí / no)
El usuario confirma y la ventana del navegador se cierra o se redirige al sitio del consumidor.
Gracias a la magia del protocolo OAuth, el consumidor ahora tiene una credencial secreta que puede usar para acceder a su API y acceder a la información de usuario-privada que acaba de autorizar.

Obviamente no puedo incluir toda la especificación de OAuth aquí, pero se puede ver con suerte de lo anterior que esto debería resolver su problema. Existen las librerías OAuth para facilitar la agregación de soporte.

Si está usando ASP.NET, le sugiero http://dotnetopenid.googlecode.com/, ya que recientemente agregó soporte OAuth (v3.0 beta 1).

Ni OpenID ni OAuth definen cómo se autentica un usuario. Definen cómo el consumidor dirige al agente de usuario al proveedor de autenticación, cómo se remite al agente de usuario y cómo el consumidor puede verificar la identidad que el usuario autenticó.

El método real utilizado para autenticar está fuera de banda para ambos esquemas.

Existen diferencias entre OpenID y OAuth, pero ambos requieren que el consumidor use los redireccionamientos HTTP y las URL de devolución de llamada. Ambos están basados en el navegador. Si su aplicación habla HTTP, puede hacerlo. Sin embargo, un punto principal es que el usuario solo está ingresando credenciales en una aplicación de confianza.

Ver: esta pregunta relacionada

El problema es que la especificación openid no tiene una disposición estándar para la autenticación con el proveedor, por lo que el proveedor puede elegir que la autenticación se realice a través de una llamada telefónica o lo que sea.

Es de esperar que más proveedores adopten OAuth . Alternativamente, podría codificar manualmente la autenticación de algunos de los sitios más grandes.