Sto studiando l'utilizzo di Social Login per un servizio web gestito da portali basati su Web e applicazioni mobili. L'idea è di "autenticare" l'utente e lasciare che il servizio crei una "chiave API" una volta che l'utente è stato autenticato.
Sto guardando OpenID / OpenID connect / OAuth 2.
L'ultimo paragrafo della sezione 10.16 di RFC6749 afferma:
Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience-restricting the access token).
E Google afferma che per evitare il cosiddetto problema con confuso devi convalidare i token di accesso. Questo consiste nel controllare che il pubblico previsto corrisponda al tuo ID cliente.
Il problema, a quanto vedo, è che l'ID cliente può ancora essere raccolto da un'app o una persona malintenzionata e utilizzato in un client pubblico dannoso per ottenere token di accesso che "eseguono il check-out" per il client.
Facebook ti consente di attivare un'opzione per richiedere appsecret_proof e afferma:
Access tokens are portable. It's possible to take an access token generated on a client by Facebook's SDK, send it to a server and then make calls from that server on behalf of the person. An access token can also be stolen by malicious software on a person's computer or a man in the middle attack. Then that access token can be used from an entirely different system that's not the client and not your server, generating spam or stealing data.
You can prevent this by adding the appsecret_proof parameter to every API call from a server and enabling the setting to require proof on all calls. This prevents bad guys from making API calls with your access tokens from their servers. If you're using the official PHP SDK, the appsecret_proof parameter is automatically added.
Questo approccio non sembra migliore: un client pubblico malintenzionato (dopo aver ottenuto e utilizzando il tuo ID cliente legittimo) può ancora eseguire il processo di accesso e quindi raccogliere il token di accesso portatile da inviare al tuo servizio web (client sicuro) che includerebbe il parametro appsecret_proof.
O mi manca qualcosa. Devo rinunciare a OAuth2 / OpenID Connect?