Quali noti provider OpenID è previsto che un nuovo sito supporti?

Question

Ho intenzione di sviluppare un'applicazione Web che supporti OpenID Connect come parte relying, in modo che un utente dell'applicazione possa registrarsi e accedere utilizzando il provider di identità di sua scelta. (Questa è la stessa tecnologia utilizzata da "My Logins" in ogni sito Stack Exchange.) Questa applicazione sarebbe disponibile per il download e l'installazione da parte degli operatori di server, così come sono resi disponibili WordPress, phpBB e il software MediaWiki. Con quali fornitori di OpenID Connect dovrebbe un operatore di server aspettarsi di registrarsi manualmente?

Indietro quando OpenID 2.0 era la versione di protocollo più comune, la maggior parte dei provider di identità (IDP) consentiva a qualsiasi parte relying (RP) di utilizzare i propri servizi di identità. Solo alcuni sfollati gestivano una whitelist di RP; quello in cui mi sono imbattuto era PayPal Access (ora chiamato Log In with PayPal). Ci sono ragioni commerciali per chiudere l'accesso, ma una politica chiusa richiedeva uno sforzo supplementare per gli IDP, quindi la maggior parte non si preoccupò.

Nell'aprile 2015, Google ha abbandonato OpenID 2.0 a favore di OpenID Connect, in cui ogni RP è un'applicazione client OAuth 2.0 con il proprio ID cliente e segreto client emesso dal provider. Normalmente, OAuth richiede che ogni cliente si registri con ciascun fornitore fuori banda, il che va bene quando ciascun provider espone una risorsa protetta con un'API unica. Ma OpenID Connect è un'API di autenticazione comune a cui tutti gli IDP dovrebbero esporre allo stesso modo quando l'utente immette un URI identificatore OpenID corrispondente nella pagina di accesso di un RP. Quindi lo OpenID Connect spec descrive una funzione di registrazione dinamica dei clienti (dyn-reg) opzionale che consente a un RP di registrarsi automaticamente come client OAuth, come indicato in Hans Z.'s answer to "Can you use OpenID Connect without obtaining OAuth credentials?". Tuttavia, ogni IDP deve fare lo sforzo per implementare il dyn-reg. Google e PayPal sono esempi di IDP OpenID Connect che hanno scelto di non farlo. E anche se un fornitore implementa il dyn-reg, la specifica consente comunque all'IDP di richiedere che l'RP presenti per prima cosa un token di accesso iniziale valido emesso dal provider. Così se ci sono n RP e m sfollati interni pubblici, un essere umano deve leggere ed accettare un contratto n * m volte.

Per dirla in altro modo, il valore predefinito in OpenID 2.0 è aperto; il valore predefinito in OpenID Connect è chiuso.

Così come più provider OpenID seguono il lead di Google e lasciano OpenID 2.0 a favore di OpenID Connect, se prendo un RP live, mi aspetto che gli utenti finali che incollano un URI identificatore vengano respinti con un messaggio di errore all'effetto "Il provider di questo identificatore è sconosciuto a Example.com e non supporta la registrazione del client dinamico." L'operatore di un server che esegue la mia applicazione Web dovrebbe quindi leggere il registro di tali errori e registrarsi manualmente con ciascun IDP per ottenere le credenziali del cliente. E dovrei creare variabili di configurazione in questa applicazione web per consentire all'operatore del server di specificare in anticipo le credenziali del client per ciascun provider popolare, in modo che gli utenti del sito vengano convertiti anziché delusi.

Desidero semplificare l'operatività di un operatore di server che ha scaricato la mia applicazione per installarlo su un server Web nel suo dominio e andare in diretta come RP. Quindi voglio che il suo processo di installazione suggerisca gli IDP pubblici per i quali è probabile che gli operatori di server si imbattano in questo problema, al contrario di un semplice modulo "Aggiungi provider OpenID Connect" che lascia l'amministratore da solo.

Altre domande correlate (OpenID Connect providers e List of OpenID Connect providers) hanno un elenco troppo breve, obsoleto, che non separa gli IDP per i quali è prevista la registrazione manuale e non separa gli IDP popolari da quelli di nicchia. Ad esempio, Salesforce.com è un IDP di nicchia che è allows only its own customers to be RPs e non penso che gli utenti finali si aspettino di poter inserire un identificatore da un IDP di nicchia su un'applicazione web pubblica. Mi piacerebbe sapere da quali fonti potrei raccogliere informazioni sugli IDP ampiamente utilizzati e tenermi aggiornato.

Quindi, come faccio a trovare i provider OpenID Connect noti e generici che non supportano la registrazione aperta dei client dinamici prima del che registra un sito dal vivo?

Answer 1

1. posizione migliore per verificare la presenza di OpenID provider di connessione è qui: http://openid.net/developers/libraries/ e up-to-date elenco di fornitori certificati è qui: http://openid.net/certification/

2. Se ho capito bene, il vostro caso d'uso è totalmente supportato da OpenID Connect.

3. Vi consiglio di dare un'occhiata a IdentityServer3: https://github.com/IdentityServer/IdentityServer3, poiché sono sicuro che risponda alle vostre esigenze. Lo sto utilizzando personalmente e il suo grande progetto open source mantenuto e sviluppato da esperti nel campo della sicurezza.

Aggiornamento:

non sono sicuro se si ha realmente bisogno di richiesta del cliente dinamico, in OIDC tutta la vostra applicazione considerato come singolo cliente/RP. i client/utenti dell'applicazione (e il set di utenti per ogni client dell'applicazione) sono totalmente supportati dalla maggior parte dei provider OIDC senza richiedere la registrazione dinamica dei client. avresti bisogno di DCR se la tua applicazione è un ombrello di portali dinamici.