Hai qualche indicazione su come dovresti implementare il protocollo oAuth2 stesso? Cioè, il lato server o il facet "provider" di OAuth2?
Se hai provato a implementare (una parte di) esso, ti preghiamo di condividere i problemi e le soluzioni. Si noti che questo è completamente indipendente dalla tecnologia e dal linguaggio di programmazione, tranne, ovviamente, per le tecnologie crittografiche standard di fatto che potrebbero essere coinvolte. La bozza IETF (v23) per oAuth2 si trova qui
Anche se non l'ho ancora implementato, intendo e ho letto più volte la bozza di OAuth 1 RFC e OAuth 2. A differenza di OAuth 1 RFC, la bozza di OAuth 2 contiene molti dettagli su come implementare il server e troverai tutti i dettagli necessari nella bozza.
Ciò di cui avrai bisogno prima di capire è il tuo gruppo target di clienti poiché ciò ti aiuterà a decidere quali metodi di autorizzazione devi supportare.
App Web? Controlla link
App JS? link
App desktop? link (se l'utente si fida della tua app con le sue credenziali)
Il protocollo si riduce fondamentalmente a generare token utilizzando funzioni crittografiche adeguate e codificando e inviando i parametri correttamente. Per un esempio di come potrebbe apparire la comunicazione, vai al spazio giochi Google OAuth 2 .
Ad esempio, la bozza indica chiaramente che quando un client richiede l'autorizzazione come 4.1 (autorizzazione del codice di autorizzazione) fornisce i campi obbligatori response_type e client_id insieme ai due campi facoltativi redirect_uri e scope, nonché il campo dello stato consigliato. Nell'implementazione del server si estraggono e convalidano tali parametri (è possibile definire ulteriori parametri obbligatori), autorizzano l'utente e se tutto è ben reindirizzato al client di reindirizzamento specificato uri (inclusa una concessione di autorizzazione).
Le modalità di autenticazione dei client possono variare, ma le specifiche suggeriscono che l'utilizzo di Autenticazione HTTP funzionerebbe correttamente per le app Web (ma non app dove nascondere le credenziali del cliente è difficile)
È molto importante che tutte le comunicazioni siano su un canale sicuro (TLS / SSL). OAuth non è un sostituto di TLS / SSL.
Buona fortuna!
OAuth 2 non ha molto in termini di requisiti di crittografia. Si basa maggiormente sulle comunicazioni essendo su canali sicuri. Abbiamo implementato un servizio OAuth 2 completo ( link ) e abbiamo scoperto che le parti più complesse sono l'autenticazione (prima di emettere il token) e la verifica di un token in entrata. Entrambe queste non sono in realtà parte delle specifiche, quindi hai bisogno di un'enorme flessibilità qui.
L'altro problema è stato. Poiché il server OAuth deve ricordare il token, deve conservare tutti i token attuali non scaduti. Per essere a prova di errore è necessario esaminare un archivio di sessioni distribuite come jcache o nCache.
Poiché esiste una comunicazione e una verifica del canale posteriore, è necessaria anche una buona libreria client HTTP e JSON.
L'altra area che abbiamo affrontato è stata la performance. Poiché ogni richiesta da un'applicazione client a un servizio di applicazione richiede un token di accesso e tale token di accesso deve essere verificato con il servizio di sicurezza, questo ha generato molto traffico. Abbiamo implementato uno schema di memorizzazione nella cache per ridurre il back and forth assicurandoti che la cache sia scaduta prima della scadenza dei token.
Sono d'accordo, le implementazioni di Google sono un buon punto di partenza poiché sono diventate uno standard de facto.
Buona fortuna!
Oleg