2009-08-10 13 views
6

Estoy trabajando en una API REST para una aplicación web que hasta ahora hemos desarrollado internamente para un par de aplicaciones complementarias. Ahora que estamos buscando abrirnos a desarrolladores externos, queremos agregar tokens a la API para ayudar a identificar quién está haciendo las solicitudes y, en general, para ayudar a administrar su uso. En este punto, estamos utilizando https y autenticación básica para la autenticación de usuario en la API.¿Buen enfoque para un esquema de token API web?

El esquema de token que hemos estado discutiendo sería muy simple en el que a cada desarrollador se le asignarían 1 o más tokens y estos tokens se pasarían como un parámetro con cada solicitud.

Mi pregunta es si has hecho algo similar antes de cómo lo hiciste (hiciste más o menos, cómo manejaste la seguridad, etc.) y ¿tienes alguna recomendación?

Gracias!

+0

Para cualquier persona interesada, escribí una historia sobre cómo pasar de no tener seguridad a una API REST segura sin OAuth aquí: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without- oauth-authentication/ El problema no está en la identificación (tokens únicos, etc.) sino en el cierre de los vectores de ataque y las personas que suplantan a los usuarios. Sobre HTTP que requiere una suma de comprobación o un "HMAC": firma de todos los valores en la solicitud con una clave secreta que solo el cliente y el servidor conocen. Sobre HTTPS, es mucho más fácil, un token simple funciona bien. –

Respuesta

6

En primer lugar, es posible que desee mirar http://OAuth.net. Dependiendo de sus cajas de uso, podría proporcionar la seguridad que necesita.

En cuanto al token, es un BLOB para la mayoría de los protocolos, incluido OAuth. Puede poner cualquier información que necesite en cualquier formato.

Esto es lo que hacemos,

  1. En primer lugar, asigne a cada desarrollador de una clave secreta asociada con.
  2. El token en sí es un par de nombre-valor encriptado. Ponemos cosas como nombre de usuario, vencimiento, identificación de sesión, roles, etc. allí. Está encriptado con nuestro propio secreto para que nadie más pueda hacerlo.
  3. Para facilitar su uso con API web, utilizamos la versión URL-safe de Base64 para que el token siempre sea seguro para URL.

Espero que ayude!

2

Quizás también desee pensar en agregar un token basado en el tiempo que le permita limitar la cantidad de tiempo que una solicitud es válida. esto ayudará con alguien que intente hacer un ataque de repetición.

Tendría una llamada de reconocimiento para obtener/asignar un token válido en función de la clave developerKey anterior. Este token se almacenaría localmente y se devolvería a la persona que llama.

El desarrollador usaría esta clave en una solicitud para validar la solicitud y el desarrollador.

Por ejemplo, esa clave se puede usar durante 5 minutos o para 10 solicitudes o lo que usted defina. después de ese punto, el token generado basado en el tiempo se elimina de la lista válida y ya no se puede usar. el desarrollador tendrá que pedir un nuevo token.

1

UUID es muy bueno para cualquier clave aleatoria temporal que desee repartir. Impredecible y rápido de generar, con colisiones tan improbables que son efectivamente únicos. Haga buenas teclas de sesión también.

Cuestiones relacionadas