La implementación de un proveedor OAuth 2 patas

Question

Estoy tratando de encontrar el camino de vuelta de la especificación OAuth, sus requisitos y cualquier implementaciones que puedo encontrar y, hasta ahora, realmente parece más problemas de lo que vale porque estoy teniendo problemas para encontrar un solo recurso que tira todo junto. O tal vez es sólo que yo estoy buscando algo más especializado que la mayoría de los tutoriales.

Tengo un conjunto de APIs existentes - algunos en Java, algunos en PHP - que ahora tengo que asegurar y, por una serie de razones, OAuth parece ser el camino correcto a seguir. Por desgracia, mi incapacidad para localizar a los recursos adecuados para ayudar a conseguir un proveedor en funcionamiento es un reto que la teoría. Dado que la mayoría de este habrá uso de la API de sistema a sistema, voy a tener que implementar un proveedor de 2 patas. Con esto en mente ...

1. ¿Alguien sabe de cualquier tutoriales buenos para la implementación de un proveedor OAuth 2 patas con PHP?
2. Dado que tengo API asegurables en 2 idiomas, qué necesito para implementar un proveedor en tanto o hay una manera de crear el proveedor como un "controlador frontal" que puedo canalizar todas las solicitudes a través de?
3. Cuando la obtención de servicios de PHP, por ejemplo, tengo que asegurar cada API de forma individual mediante la inclusión de los recursos necesarios en cada proveedor?

Gracias por su ayuda.

Answer 1

Me tomaría un paso atrás y pensar en lo que un cliente debidamente autenticado se va a enviar más.

Se puede almacenar las claves y credenciales en una base de datos común que es accesible desde ambos conjuntos de servicios, y acaba de poner en práctica el proveedor OAuth en un idioma? Cuando el usuario envía una solicitud a un servicio (PHP o Java), a continuación, comprueba en el almacén común. Cuando el usuario está instalando el cliente de OAuth entonces hacer todo eso, ya sea a través de una aplicación PHP o Java (su preferencia), y almacenar las credenciales en la base de datos común.

Hay algunos proveedores Oauth escritos en otros idiomas que es posible que desee echar un vistazo a:

• PHP - http://term.ie/oauth/example/ (ver parte inferior de página)
• Ruby - http://github.com/mojodna/sample-oauth-provider
• http: //blog.bittercoder .com / PermaLink, GUID, 0d080a15-b412-48cf-b0d4-e842b25e3813.aspx

Answer 2

Rob, no sabe dónde se posó en esto, pero quería añadir mis 2 centavos en el caso de cualquier otra persona corrió a través de esta pregunta.

Yo tenía más o menos la misma pregunta hace unos meses y escuchar sobre "OAuth" para la mayor parte de un año. Que estaba desarrollando una API REST que necesitaba para asegurar así que empecé a leer sobre OAuth ... y luego mis ojos hacia atrás empecé a rodar en mi cabeza.

Probablemente le dio un buen día sólido o 2 de desnatado y leyendo hasta que decidí, al igual que usted, que era confusa OAuth basura y dejó el trabajo en él.

Así que me puse a investigar maneras en las API de seguros en general y comenzó a tener una mejor comprensión de maneras de hacer eso. La manera más popular parecía ser el envío de solicitudes a la API, junto con una suma de comprobación de todo el mensaje (codificado con un secreto que sólo usted y el know servidor) que el servidor puede utilizar para decidir si el mensaje había sido manipulado en su camino desde el cliente, así:

1. El cliente envía /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
2. Servidor consigue todo eso, mira hacia arriba de usuario "123" en la base de datos, cargas de su clave secreta y después (utilizando el mismo método que el cliente utiliza) vuelve a calcular su propio checksum dados los argumentos de la petición.
3. Si la suma de comprobación generada del servidor y la suma de comprobación enviado del cliente coinciden, la solicitud está bien ejecutada y, si no, se considera manipulado y rechazado.

La suma de control se denomina HMAC y si quieres un buen ejemplo de esto, es lo que utiliza los servicios web de Amazon (que ellos llaman el argumento 'firma' no 'suma de comprobación' sin embargo).

Así que dado que uno de los componentes clave de este trabajo es para que el cliente y el servidor tiene que generar el HMAC de la misma manera (de lo contrario no coincidirán), tiene que haber reglas sobre cómo combinar toda la argumentos ... entonces de repente me entienden todo lo que "byte-ordenamiento natural de los parámetros" basura de OAuth ... se acaba de definir las reglas sobre cómo generar la firma, ya que necesitaba.

Otro punto es que cada parámetro se incluye en la generación HMAC es un valor que luego no puede ser manipulado cuando se envía la solicitud.

Así que si usted acaba de codificar la URI madre como la firma, por ejemplo:

• /user.json == askJdla9 / kjdas + Askj2l8add

entonces la única cosa en su mensaje que no puede ser manipulado es el URI, todos los argumentos puede ser manipulado, porque no son parte del valor "suma de comprobación" que el servidor va a volver a calcular.

Por otra parte, incluso si se incluyen CADA parámetro en el cálculo, aún corre el riesgo de "ataques de reproducción", donde un hombre de mediana malicioso o evesdropped puede interceptar una llamada API y simplemente mantener volver a enviar al servidor una y otra vez.

Se puede arreglar eso mediante la adición de una marca de tiempo (siempre usar UTC) en el cálculo HMAC también.

RECORDATORIO: Desde el servidor necesita para calcular la misma HMAC, usted tiene que enviar a lo largo de cualquier valor que se utiliza en el cálculo SALVO SU CLAVE SECRETA (OAuth lo llama un consumer_secret creo). Así que si se agrega marca de tiempo, asegúrese de enviar un parámetro de marca de tiempo, junto con su solicitud.

Si desea realizar la API a salvo de los ataques de repetición, se puede utilizar un valor nonce (que es un valor de uso 1-tiempo, el servidor genera, da al cliente, el cliente utiliza en el HMAC, envía la solicitud , confirma el servidor y luego marcas de ese valor nonce como "usado" en el PP y nunca deja que otra petición de uso de nuevo).

NOTA: 'nonce' son una forma muy exacta para resolver el problema "replay attack" - marcas de tiempo son grandes, pero porque las computadoras no siempre tienen los valores de fecha y hora en la sincronización, usted tiene que permitir que una ventana aceptable en el del lado del servidor de la forma "antigua" una solicitud podría ser (por ejemplo, 10 minutos, 30 minutos, 1 hora y 15 minutos .... Amazon utiliza) antes de aceptarla o rechazarla. En este escenario su API es técnicamente vulnerables durante toda la ventana de tiempo.

piensan que los valores nonce son grandes, pero sólo deberían necesitar ser utilizado en las API que son críticos mantienen su integridad. En mi API, yo no lo necesitaba, pero sería trivial para agregar más tarde si así lo exigían los usuarios ... Yo, literalmente, sólo tiene que añadir una tabla "nonce" en mi DB, exponer una nueva API para clientes como:

• /nonce.json

y luego cuando envían que volver a mí en el cálculo HMAC, que tendría que comprobar la base de datos para asegurarse de que nunca se había utilizado antes y una vez utilizado, se marca como tal en la base de datos por lo que si una solicitud llegó NUNCA de nuevo con la misma nonce me rechazarla.

Resumen

De todos modos, para hacer el cuento largo, todo lo que acabo de describir es básicamente lo que se conoce como "OAuth 2 patas". No existe ese paso adicional de que fluye a la autoridad (Twitter, Facebook, Google, lo que sea) para autorizar el cliente, ese paso se retira y en su lugar el servidor confía implícitamente al cliente si el HMAC es que están enviando coinciden. Eso significa que el cliente tiene la secret_key derecha y se firmarlo de mensajes con ella, por lo que las servidor confía a él.

Si usted comienza a mirar alrededor en línea, esto parece ser el método preferido para asegurar métodos de la API hoy en ADAYS, o algo parecido. Amazon utiliza casi exactamente este método a menos que utilicen un método de combinación ligeramente diferente para sus parámetros antes de firmar todo lo que hay que generar el HMAC.

Si está interesado me escribió seguridad de todo este viaje y proceso de pensamiento que estaba aprendiendo él. Esa ayuda podría proporcionar un recorrido guiado por el pensamiento de este proceso.