2

in RFC 6749 The OAuth 2.0 Authorization Framework

2.3.1. Client Password definitely states that authentication at TokenEndpoint can be done in two alternate ways

  1. HTTP basic authentication - client_id:client_secret
  2. in the POST request-body, client_id={client_id}, client_secret={client_secret}

While Facebook API demands a Get request with URL encoded parameters:

    GET https://graph.facebook.com/oauth/access_token?
    client_id={app-id}
    &redirect_uri={redirect-uri}
    &client_secret={app-secret}
    &code={code-parameter}

Isn't this (non standard compliant way) exposing of client passwords in URL breaking security logic of AUTH2. And opening doors to vulnerabilities?

|improve this question
  • It's over HTTPS. So I think everything should be cool. – RoraΖ Aug 13 '14 at 14:32
  • IIRC, Facebook implemented OAuth 2.0 very early on, at something like v12 of the draft. As the standard is something like v31, there will indeed be differences between their implementation and the final spec. – Xander Aug 13 '14 at 14:37
  • HTTPS, but not in body! URL parameters are visibly sometimes: Servers Logs, Browser history. I was sure sensitive data in URL should be excluded when possible. :) – nsb Aug 13 '14 at 14:55
  • you're right. that's an attack-vector, but not a critical one. could be avoided by using OAuth1 ;) – JimiDini Aug 14 '14 at 11:38

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.