Come si scrive un server OAuth2 in Perl?

Question

Sto cercando di comprendere OAuth2 e Perl (ovvero Net :: OAuth2), in particolare, impostando un'API RESTful per un database e un'applicazione che lo utilizza.

Perl Oauth2 package mi ha portato a Net :: OAuth2.

Da quanto riesco a capire, ci sono un paio di cose che devo fare (si prega di correggermi se sono fuori nelle erbacce da qualche parte):

1. lato server: costruire il server REST (attualmente sta giocando con mojolicious per questo), che parla con il database.
2. lato server: costruire il server di autenticazione/autorizzazione (??)
3. applicazione client: utilizza WWW :: Mechanize (o qualcosa di simile) per comunicare con il server REST

Nella mia testa, ecco come funziona:

1. l'applicazione client dispone di una chiave API (?? registrato con il server (server REST server di Auth), e “cotto in” al client)
2. l'utente ha una voce (nome utente e password) in una tabella nel database sul server
3. l'utente apre l'app client e tenta di accedere a una risorsa protetta (ad esempio per aggiornare una riga) (ancora, ad esempio, selezionando un'opzione del menu "Esegui questa cosa" nel client; il cliente si traduce che nella API REST URI, ad esempio http://the.rest.server/api/thisthing)
4. server reindirizza il client al() bit autenticazione/autorizzazione del server
5. server, client e utente non una danza magica OAuth per autenticare l'utente
6. il server, il client e l'utente eseguono un'altra magia OAuth dance per assicurarsi che l'utente sia autorizzato a vedere quell'URI della risorsa
7. se tutto va bene, il server reindirizza il client all'URI della risorsa originariamente richiesto (con qualunque sia l'autorizzazione necessaria).

È una valutazione ragionevole del processo?

In tal caso, avrebbe più senso disporre di "autenticazione/autorizzazione" come parte del server REST o come server completamente separato? (sullo stesso hardware).

Net::OAuth2::Profile::WebServer spiega chiaramente cosa deve accadere sul lato dell'applicazione client.

I test in http://cpansearch.perl.org/src/MARKOV/Net-OAuth2-0.55/t/ (a meno che io sono veramente manca qualcosa) sono di lavorare con Net :: OAuth2 profilo server web, che sarebbe (ancora una volta) la “applicazione client”.

Esistono altri esempi per la scrittura del client: la connessione a un server OAuth2 esistente, ad esempio le informazioni sull'API di Google, ma non riesco a trovare esempi di scrittura del server .... (Sono abbastanza disponibile a RTFM , se posso trovare i puntatori FM ... apprezzati!)

Answer 1

L'idea generale è quella di lasciare che un server di autenticazione centrale per gestire le credenziali + generazione + politica token di gestione (politica => è questo applicazione autorizzata dalla questo utente).

Parliamo prima del server OAuth.
i) Il server è responsabile di una pagina di accesso in cui l'utente può inserire le proprie credenziali.
ii) Convalida le credenziali, se corretto questo server quindi controlla quale app client ha effettuato la chiamata e verifica se "è questa app autorizzata da questo utente". - Ecco che arriva il concetto di ambito.
iii) Genera un codice di accesso/codice di accesso per l'app.
iv) Quando un'API viene colpita da un client con un token di accesso, l'API deve passare internamente il token su questo server. È compito di questo server verificare i contenuti del token.

Ora, i API
i) L'API deve accettare gettone da un'applicazione client, passare al server - recuperare un ID cliente univoco dal server e restituire i dati al client per quel cliente.

Per i applicazioni 3rd party,
i) È necessario disporre di un processo di registrazione. Il cliente ha bisogno di avere ID client e segreto. Google ti consente di registrarti nello console.
ii) Dovrebbe esserci un ambito che si associa ad ogni API univoca. Ad esempio, quando crei un'app OAuth di Google, devi registrare la tua app come scope: G +, picasa, google drive, ecc.
iii) I token di accesso sono esclusivi dell'ambito e mappano alle autorizzazioni concesse all'app da l'utente. Se l'app client utente seleziona solo l'ambito G + e gli viene concesso l'accesso dall'utente, l'app può utilizzare il token solo per l'endpoint G +.

una risposta più dettagliata su come implementare un server di OAuth può essere trovato qui: How would an efficient OAuth2.0 server/provider work?