2010-08-20 31 views
8

Estoy desarrollando varias API RESTful para que terceros puedan llamar, y estas API necesitan autenticación (apikey & base secreta) y autorización (método HTTP & URI basado).Restful API authentication recommendation?

¿Existe algún software existente que podamos reutilizar que me impida implementar nuestra propia implementación para la capa de seguridad?

Respuesta

7

HTTP da soporte para que le concede, por lo que no es necesario reinventar la rueda

De cualquier uso:

  • HTTP Basic Auth (con SSL para eludir la contraseña en texto plano presentar problemas)
  • HTTP de autenticación implícita

autenticación implícita tiene la ventaja, que no transmite la passowrd en texto plano y se ocupa de los ataques de repetición (con valores de uso único).

Usamos HTTP Auth Digest (el contenedor de servlets Tomcat tiene soporte directo) y estamos contentos con ello.

EDITAR: Algunos clientes tienen problemas con Digest (no tan triviales), por lo que en estos días optaría por Basic y SSL. Advantage for Basic también es que usted puede realizar una autenticación preventiva (enviando usuario: pwd en la primera solicitud).

+0

Deseo autorización también, p. algunas API como POST http://www.example.com/adduser, solo concedo el acceso a algún cliente. – Howard

+1

Veo que depende de la plataforma tecnológica que use. Si usa java y servlet-container, puede usar la autorización integrada basada en roles. Adjunta estos roles a las URL permitidas y, por lo tanto, puede evitar las visibilidades. A continuación, agrupa un conjunto de clientes en roles (es decir, client1 + 2 pertenece a role1, client3-6 a role2). Si el enfoque de la base de roles es demasiado grueso (es decir, cada cliente tiene diferentes reglas de acceso), debe implementar una capa de autorización adicional. Pero primero pruebe si la seguridad de roles se ajusta a sus requisitos (más fácil de implementar). –

0

Independientemente de la tecnología se puede aplicar algún sistema como utiliza AWS.

  • Cada uso registrado debe tener un ID de usuario y una clave de acceso secreta.
  • Cada solicitud debe estar firmada con el SAK y debe contener el ID de usuario. (Tenga en cuenta la marca de tiempo también).
  • El servidor, dado el ID de usuario, recupera de DB el SAK y vuelve a firmar la solicitud, si la firma continúa mucho, de lo contrario devuelve un error.

La implementación no es muy difícil, pero debe tener en cuenta que cada solicitud al servidor requiere consultar la tienda para recuperar el SAK. Una opción es usar una base de datos NoSQL o similar (como Redis o Memcache) para almacenar el ID de usuario/sak.