Estoy desarrollando una plataforma B2B, donde otros desarrolladores (nuestros clientes) crearán aplicaciones de estilo de tienda que aprovechan nuestra plataforma.

Exponemos una API basada en REST a la que nuestros clientes pueden llamar directamente desde sus servidores de aplicaciones o sus propias aplicaciones de cliente pueden hacerlo todos, en nombre de sus usuarios.

Sus aplicaciones son independientes y "poseen" la relación con sus usuarios, incluida la autenticación.

Desde la perspectiva de los usuarios finales, la interacción con nuestra aplicación es transparente.

Además, nuestros clientes operan en nuestra plataforma con un alto nivel de confianza. Dado que son propietarios de la relación con los usuarios (y simplemente utilizan nuestra plataforma similar al procesamiento de back-office), los usuarios no tienen que otorgarles acceso para operar en nuestra plataforma en su nombre.

Por lo tanto, hemos identificado dos patrones de interacción estándar para usar con nuestra API.

Me gustaría implementar lo más cerca posible de OAuth2, pero no estoy seguro de que se ajusten estrictamente a los flujos existentes.

Flujo n. ° 1: servidor de aplicaciones de los clientes a nuestra plataforma

Esteeselflujoparaunacomunicaciónestrictadeservidoraservidor.

1. Laaplicacióndelclienteseautenticaconnosotros,pasandosusclient_idyclient_password.Devolvemosunaccess_token.
2. Laaplicacióndelclientepasaelaccess_tokenenunencabezadodeautorizaciónentodaslasllamadasfuturas.
3. Además,cuandolallamadaestárealizandounaacciónennombredeunusuario,tambiénpasanunusernameenunencabezadodeautorización.

Notas:

• Elidentificadordeautenticaciónemitidonoestávinculadoaunsolousuario.Lespermiteactuarennombredemuchosusuarios(aunquelimitadoaunoporllamada)

Isospechoestaesunavariacióndelflujode"contraseña", pero no se requiere la contraseña del usuario.

Flujo n. ° 2: cliente de aplicaciones de los clientes a nuestra plataforma

Este es el flujo en el que una aplicación de los clientes se comunica directamente con nuestra plataforma, en lugar de a través de su servidor de aplicaciones.

En este escenario, el usuario ya se ha autenticado con la aplicación para clientes.

1. La aplicación de los clientes ya está autenticada en el Flujo n. ° 1 y tiene un access_token
2. El servidor de aplicaciones de los clientes llama a nuestra plataforma, con su access_token y un nombre de usuario. Devolvemos un access_token para su uso por ese usuario.
3. La aplicación de los clientes sirve este token a su cliente.
4. El cliente de la aplicación de los clientes llama a nuestra plataforma y pasa access_token en un encabezado de autorización.

Preguntas

¿Son estos flujos estándar existentes dentro de la especificación OAuth2? Lo he leído y no creo que ninguno de los dos esté descrito.

Si no existe, ¿hay flujos similares que deberíamos tener en cuenta y que siguen siendo adecuados para nuestros requisitos? Específicamente:

• Los servidores de aplicaciones de los clientes pueden realizar acciones en nombre de los usuarios
• Los servidores de aplicaciones de los clientes no requieren nuevos códigos de acceso para cada usuario que desean usar como proxy
• Los clientes / usuarios de los clientes pueden acceder a nuestra plataforma sin iniciar sesión directamente (pero aún se autentican a través de su servidor de aplicaciones).

¿Hay problemas con cualquiera de estos flujos que los hacen realmente malas ideas?