Decidir a REST API Security

6

He desarrollado una API. Me confundí y he estado leyendo artículos durante días. En realidad, mi pregunta es cercana a estas pero no exacta (tal vez una combinación de ellas);
API REST de seguridad a la que se accederá desde diferentes clientes
API REST segura sin inicio de sesión para muy pocos clientes

Necesito proporcionar seguridad a mi API. La API será utilizada por aplicaciones de terceros de clientes. He adjuntado un esquema a continuación.

¿Qué debo hacer?

HTTP-Basic con SSL \ TLS, HTTP-Digest con SSL \ TLS, OAuth 2.0 o qué más debería ser?

Editar(2015-03-25):
Sehaabandonadoestaparte.Mire"Editar (2015-04-01)" en la siguiente página

Decidí implementar SSL + OAuth 2.0 ( Subvención de credenciales de contraseña del propietario del recurso ). Si cree que no es conveniente para el escenario, infórmeme.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

El flujo ilustrado en la Figura 5 incluye los siguientes pasos:

(A) El propietario del recurso le proporciona al cliente su nombre de usuario y         contraseña.

(B) El cliente solicita un token de acceso de la autorización         token endpoint del servidor al incluir las credenciales recibidas         del propietario del recurso. Al realizar la solicitud, el cliente.         se autentica con el servidor de autorización.

(C) El servidor de autorización autentica al cliente y valida         las credenciales del propietario del recurso y, si son válidas, emiten un acceso         token.

Editar (2015-04-01):

He implementado Credenciales de cliente OAuth 2.0 . Y ahora estoy buscando cómo puedo implementar un certificado SSL para la solicitud de API de los clientes.

El tipo de concesión de credenciales de cliente DEBE ser utilizado únicamente por confidencial    clientes.

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

El flujo ilustrado en la Figura 6 incluye los siguientes pasos:

(A) El cliente se autentica con el servidor de autorización y         solicita un token de acceso desde el punto final del token.

(B) El servidor de autorización autentica al cliente y, si es válido,         emite un token de acceso.

    
pregunta efkan 25.03.2015 - 17:25
fuente

2 respuestas

6

Lo que diría sobre las opciones que describe es que la autenticación HTTP con SSL es una opción más simple pero menos flexible y Oauth2 es más compleja pero tiene más flexibilidad en lo que puede lograr con ella.

Un ejemplo, como ha señalado en su diagrama artístico ASCII, con OAuth2 es posible crear un token que se puede usar en lugar de la contraseña para autenticar las solicitudes. Es probable que esto sea una ventaja sobre HTTP Basic / Digest, ya que significa que no tiene que almacenar la contraseña de los usuarios en el cliente, solo puede almacenar el token.

Entonces, en general, si puedes implementar OAuth2 bien, diría que sigue con eso ...

    
respondido por el Rоry McCune 25.03.2015 - 21:47
fuente
5

Si un token OAuth 2.0 está comprometido, solo debes preocuparte por el TTL del token.

Si un encabezado de Autenticación básica HTTP está comprometido, las credenciales no caducan. Necesitaría manualmente cambiar su ID de cliente y su secreto, y eso es si incluso sabía o pensaba que estaban comprometidos. Y es probable que necesite cambiar el código de su cliente cada vez para adaptarse a esto.

La diferencia clave entre estas 2 opciones es que la creación de token OAuth 2.0 implica 1 paso crítico en el que se intercambian client_id y el secreto. En la Autenticación básica HTTP, cada llamada a la API implica el mismo intercambio.

Desde esta perspectiva, OAuth 2.0 es una opción mucho más segura.

    
respondido por el akoo1010 25.03.2015 - 22:58
fuente

Lea otras preguntas en las etiquetas