Facebook OAuth security using passport-facebook

前端 未结 2 1544
醉酒成梦
醉酒成梦 2021-02-06 18:10

I am currently using a client-side React component to have a user login to Facebook via OAuth in my application. On the server-side, I use the npm package passport-facebook-toke

相关标签:
2条回答
  • 2021-02-06 18:16

    Your approach to validate the email as well as the token is a bit superfluous because Facebook's opaque user access tokens are inherently tied to email.

    From Facebook

    An access token is an opaque string that identifies a user, app, or Page

    "opaque" is defined by Auth0 here

    Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage

    In your case, the identifier is the user's email, and the server belongs to Facebook.

    I will elaborate further. Here is your step by step with some edits:

    1. User uses React component on the client to authenticate with Facebook, inputting both their email and password directly to Facebook. React component gets the token from Facebook on login success.

    2. React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.

    3. The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token because the access token is already tied to the email.

    4. Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.

    This is Facebook's bug bounty program. If their OAuth was really as cracked as to require a second email validation, it would have been patched almost immediately by this incentive.

    0 讨论(0)
  • 2021-02-06 18:23

    Really the best way I can think of to make your OAuth accessToken and 'code' value less prone to brute-forcing is using a Cryptographic Number Generator to create a 128-bit length string of random data and encoding it with base 64 to use as your code. It's extremely unlikely that it would be guessed by a computer or by someone redirecting to and from the authorization endpoint and the redirect-uri with query parameters.

    Another method of fortification is limiting the rate of authorizations by IP address (which you can do instead of email through Node.js) but that is usually not a problem for most well-equipped hackers. I highly advise the first method for creating a more secure service.

    0 讨论(0)
提交回复
热议问题