Asegurando Java REST Api para Saas usecase

0

Estoy creando una API RESTFul de Java con Jersey2. La API será consumida por los desarrolladores. Los desarrolladores deben obtener acceso a los puntos finales a través de un access_token (preferiblemente no caducado).

Eché un vistazo a Kong y otras implementaciones de oauth2, pero tengo la sensación de que esto podría ser superado.

Así que creo que una autenticación RBA basada en token debería estar bien para el principio. El problema es que este enfoque se basa en las fechas de caducidad de los tokens. Pero como dije, esto no es lo que quiero. Entonces, ¿está bien tener tokens que no caducan?

También, ¿qué te parece? ¿Es Oauth2 esencial para mi caso de uso? ¿Y qué tan difícil sería migrar luego de un concepto de seguridad simple (RBAC con tokens de acceso) a Oauth2?

    
pregunta Fabian Lurz 19.11.2015 - 11:00
fuente

1 respuesta

1

Comenzaré respondiendo con otras dos preguntas:

  • Si lanza su propia solución, ¿cuánto tiempo le llevará?
  • Si su API es pública por diseño, ¿qué tan rápido puede su desarrollador entender un mecanismo de autorización no estándar?

OAuth 2.0 tiene la ventaja de ser bastante popular, por lo que puede esperar que sus clientes (desarrolladores) ya lo sepan. No es necesario que documente todos los detalles de Gore, solo puede indicar a los principiantes las especificaciones y los tutoriales existentes.

También si está utilizando Java, está implementando su propio servidor de autorización con Spring Security + Spring Boot o Spring Cloud será cuestión de días, incluso si empiezas desde cero. Asegurar sus servidores de recursos (API HTTP) con Spring Security también es fácil.

Desde un punto de vista muy pragmático, OAuth 2.0 es menos excesivo que construir tu propia solución.

    
respondido por el Michael Tecourt 27.11.2015 - 10:08
fuente

Lea otras preguntas en las etiquetas