The previous blogs led up to situation where the user is able to authenticate with Facebook thus receiving a Facebook authentication token. Authentication with Facebook results in a request being sent to our REST service. The intent of that request is to authenticate with our Rest service. The request contains the Facebook authentication token and the users Facebook email address (from their Facebook profile). The Rest Service will receive the Facebook authentication token from the client, it then invokes Facebook itself using RestFB to retrieve the users profile. The email address received from the client is now compared with the email address taken from the Facebook profile just retrieved via RestFB.

If the email addresses match, the user is authentic. (Now the REST service generates a token for the client which identifies that client. Any time the client wants to invoke the service, it supplies that token).

If the email addresses do not match, the client supplied a valid Facebook authentication token but for a different account; reject this user.

If the profile cannot be retrieved, the client may have supplied an invalid Facebook authentication token; reject this user.

If the email addresses match, the user is authentic. At this point in the previous blog, the server just responds to the client with an email address, i.e. the matched email address. The client stores this and passes it to the service in a request-header on each request. Our REST service will use this each time to extract the user from persistence.

There are a couple of problems with this approach.

The email address in transit is exposed unless HTTPS is used. HTTPS should be used so this is not such a big issue.

The email address alone may not be sufficient information. Date/Time issued or Date/Time expires may be of use so that the token can be expired after a defined idle period.

Data other than the email address may be required, i.e. a bunch of key-value pairs.