1

I am investigating using Social Login for a web service fronted by Web-based portals and Mobile applications. The idea is to "Authenticate" the user and let the service create an "API-Key" once the user has been Authenticated.

I am Looking at OpenID/OpenID connect/OAuth 2.

The last paragraph of section 10.16 of RFC6749 states:

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).

And Google states that to Avoid the so-called Confused Deputy Problem you must validate Access tokens. This consists of checking that the intended Audience matches your own Client-ID.

The problem as I see it is that the client-ID can still be harvested by a malicious app or person and used in a malicious public client to obtain access tokens that would "check-out" for your client.

Facebook allows you to Enable an option to require appsecret_proof and states:

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.

This approach seems no better - a malicious public client (having obtained and using your legitimate Client-ID) can still perform the login process and then harvest the portable access token to submit to your web service (secure client) which would include the appsecret_proof parameter.

Or am I missing something. Do I need to give up on OAuth2 / OpenID Connect?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.