JWT o claves públicas-privadas para llamadas de API de servicio a servicio

Question

JWT o claves públicas-privadas para llamadas de API de servicio a servicio

#1 de Anders (4 votos)
#2 de Geir Emblemsvag (2 votos)

4

Estoy estudiando la configuración de la autenticación entre dos servicios de aplicación. El servicio A llamará al servicio B, y quiero que el servicio B solo acepte llamadas (http) del servicio A, en ningún otro lugar.

Sé cómo funciona la autenticación JWT y podría implementarlo. Si comprendo correctamente (creo que sí, pero me corrijo si me equivoco), funciona así:

el servicio A solicita un JWT del servicio B (o un servidor de identidad, pero supongamos punto a punto)
el servicio B responde con el JWT, firmado con el secreto del servicio B
el servicio A realiza la llamada al servicio B e incluye el JWT
el servicio B inspecciona el JWT y puede saber si en realidad fue el servicio A el que realizó la llamada, sin alterar el JWT

¿Pero es realmente necesaria la primera llamada? No podría hacer esto:

el servicio A firma cada solicitud con la clave privada del servicio A
el servicio B descifra la solicitud con la clave pública del servicio A
el servicio B ahora sabe si la solicitud proviene realmente del servicio A

Estaré trabajando sobre https y no tendré necesidad de reclamos. Todo lo que necesito saber es si la solicitud se originó desde el servicio A. Debido a que solo el servicio A puede llamar al servicio B, pero cuando lo hace, tiene acceso a todos los puntos finales de la API (por lo que no es necesario realizar reclamaciones).

Parece más sencillo usar cifrado asimétrico en lugar de JWT, pero me pregunto si es tan seguro, correcto y estándar para hacerlo.

asymmetric api jwt

pregunta Peter 09.03.2018 - 09:03

fuente

2 respuestas

2

De alguna manera, apunta a él, utilizando tokens de acceso JWT en una infraestructura de Oauth, con un servidor de autorización adecuado (AS) es la forma estandarizada de hacerlo. Le proporciona formas estándar de sintonizar el acceso más adelante, a través de un servicio central. Y se escala bien.

Su solución probablemente sea segura a pequeña escala, si no necesita dar acceso a muchos usuarios u otros servicios. Debe lidiar con la administración de claves, que podría ser igualmente una clave simétrica.

Eso haría que esto se pareciera al protocolo de webhook de Github: enlace

Esto utiliza un encabezado HMAC en la solicitud.

respondido por el Geir Emblemsvag 09.03.2018 - 09:39

fuente

Lea otras preguntas en las etiquetas asymmetric api jwt

¿Cuál es la diferencia entre una carga útil y un código de shell? ¿Cómo puedo mejorar la seguridad en un entorno de producción?

score 4 · Accepted Answer

El JWT se creó para manejar una amplia gama de situaciones (reclamos diferenciados, servidores de identidad separados, muchos usuarios, etc.). Su situación es bastante sencilla: solo tiene un cliente (A) que necesita comunicarse con un servidor (B).

Puede manejar este caso con JWT si lo desea, pero tampoco es necesario. De hecho, sería excesivo, ya que el JWT requiere algún tipo de autenticación en el primer paso. Y si tiene que configurar eso, ¿por qué no usarlo todo el tiempo? La configuración de la clave pública privada que sugieres funcionaría igual de bien. Por lo tanto, a menos que espere que sus requisitos cambien, yo preferiría uno que sea más sencillo de implementar.

En realidad, algo muy similar a su sugerencia ya está implementado en TLS, a saber, la autenticación del cliente. En esa configuración, el cliente debe proporcionar un certificado al servidor para la autenticación. Es posible que desee ver eso.