Sto sviluppando una piattaforma B2B, in cui altri sviluppatori (i nostri clienti) costruiranno app in stile shop-front che sfruttano la nostra piattaforma.

Esporremo un'API basata sul REST che i nostri clienti chiamano direttamente dai loro server di app, oppure le loro app client possono tutti, per conto dei loro utenti.

Le loro app sono indipendenti e "proprietarie" della relazione con i loro utenti, inclusa l'autenticazione.

Dal punto di vista degli utenti finali, l'interazione con la nostra applicazione è trasparente.

Inoltre, i nostri clienti operano sulla nostra piattaforma ad un livello elevato di fiducia. Dato che possiedono la relazione con gli utenti (e utilizzano semplicemente la nostra piattaforma simile all'elaborazione del back-office), gli utenti non devono concedere loro l'accesso per operare sulla nostra piattaforma per loro conto.

Pertanto, abbiamo identificato due modelli di interazione standard da utilizzare con la nostra API.

Mi piacerebbe implementare il più vicino possibile a OAuth2, ma non sono sicuro che questi siano strettamente conformi ai flussi esistenti.

Flusso n. 1: server delle app dei clienti sulla nostra piattaforma

Questoèilflussoperunastrettacomunicazionedaserveraserver.

1. L'appdelclienteeffettual'autenticazioneconnoi,passandoilclient_ideilclient_password.Restituiamounaccess_token.
2. L'appdelclientepassailaccess_tokeninun'intestazioneAutorizzazioneatuttelechiamatefuture.
3. Inoltre,quandolachiamatastaeseguendoun'azionepercontodiunutente,passaancheunusernameinun'intestazioneAutorizzazione.

Note:

• Ilauthentication_tokenemessononèassociatoaunsingoloutente.Permettelorodiagirepercontodimoltiutenti(ancheselimitatoaunachiamata)

Isospettoquestaèunavariazionedelflusso"password", ma in cui la password dell'utente non è richiesta.

Flusso # 2: cliente dell'app clienti alla nostra piattaforma

Questo è il flusso in cui l'app di un cliente comunica direttamente con la nostra piattaforma, piuttosto che attraverso il proprio server delle app.

In questo scenario, l'utente è già stato autenticato con l'app clienti.

1. L'app dei clienti è già autenticata dal flusso n. 1 e ha un access_token
2. Il server delle app dei clienti chiama la nostra piattaforma, con il loro access_token e un nome utente. Restituiamo un access_token per l'uso per quell'utente.
3. L'app clienti serve questo token al suo cliente.
4. Il client dell'app dei clienti chiama la nostra piattaforma, passando il access_token in un'intestazione di autorizzazione.

Domande

Questi flussi standard esistono all'interno delle specifiche OAuth2? L'ho letto e non credo che nessuno di loro sia descritto.

Se non esistono, ci sono flussi simili che dovremmo guardare, che soddisfano ancora le nostre esigenze? In particolare:

• I server delle app dei clienti possono eseguire azioni per conto degli utenti
• I server delle app dei clienti non richiedono nuovi codici di accesso per ogni utente che desiderano effettuare il proxy
• I clienti / utenti dei clienti possono accedere alla nostra piattaforma senza accedere direttamente (ma sono ancora autenticati tramite il proprio server delle app).

Ci sono problemi con uno di questi flussi che li rendono davvero pessimi?