Emisión de tokens de acceso personal para mis API

2

Tengo un sitio de intranet, alojado localmente dentro de mi organización. El mismo sitio también expone algunos datos a través de varios servicios web. Está escrito utilizando ASP.NET MVC 5 y WebAPI 2.

En este momento, los usuarios pueden iniciar sesión en el sitio web mediante la autenticación de Windows y, una vez autenticados, pueden acceder a las API. Sin embargo, también debo permitir el acceso a las API utilizando tokens para que puedan ser interrogados por procesos automatizados. El proceso que estoy considerando implementar es el siguiente:

  1. Un usuario autorizado para acceder al sitio de Intranet inicia sesión y va a una nueva página que crearé donde pueda solicitar un token. Se generará un token y se mostrará en la pantalla para que lo anoten.
  2. Las llamadas a la API se realizan incluyendo el token en el encabezado HTTP, que el servidor verificará antes de devolver los datos.

Tenga en cuenta que:

  • Necesito la capacidad de revocar tokens, por lo que los JWT no son realmente adecuados.
  • Usar OAuth no es una opción.
  • Se accede a las API mediante HTTPS (y también estoy buscando encriptar los datos devueltos).

Creo que me estoy enredando en nudos implementando esto, sin embargo. Dado que la capacidad de revocar los tokens significa que tengo que persistir algo en la base de datos, y que esencialmente estoy usando tokens de acceso personal que representan las credenciales del usuario, en lugar de pedirles que generen sus propios tokens usando un privado compartido clave, estoy luchando para justificarme por qué no debería simplemente generar cualquier clave antigua (incluso podría ser un GUID) almacenarla en la base de datos junto con una fecha de caducidad y un nombre de usuario asociado y tal vez algún tipo de alcance para restringir Las API a las que se puede acceder y que se pueden hacer con ellas.

He estado escribiendo código para crear HMAC y demás, pero en la solución que he propuesto no hay verificación del origen de la llamada a la API, solo estoy aceptando que si el token coincide con uno que ha sido un problema y no revocado, es bueno.

Creo que el modelo que sugiero es similar a los utilizados por GitHub y Microsoft Visual Studio Team Services PAT para acceder a sus API, pero no puedo evitar pensar que mi sugerencia tiene algunos defectos fundamentales. ¿Alguien podría tal vez señalar cómo podría mejorarse mi propuesta y / o sugerir un modelo adecuado para mi escenario?

    
pregunta Philip Stratford 16.07.2018 - 17:57
fuente

0 respuestas

Lea otras preguntas en las etiquetas