Facebook oAuth Authentication Security - facebook

Using the JavaScript SDK and making a login request, once I receive the request response from Facebook that states the user is "Connected" ho can I be assured that this request was not hijacked?
Facebook provides an app secret for use in validating the response, but in the examples for authentication the app secret is never requested.
I am looking for further examples of using the JavaScript SDK or C# SDK to securely authenticate facebook users.
If I don't understand the app secret or oAuth correctly, please feel free to advise and explain why the app secret is not needed, but from the documentation I've read it sounds necessary.

The app secret is only used server-side to very that a response is authentic. It can't be used client-side (ie: in JavaScript) because that would require storing the app secret itself in your JavaScript code which would entirely defeat the purpose of the secret (ie., it would no longer be a secret).
So, yes, your JavaScript requests can be hijacked, but it doesn't really matter. As long as you use your secret for server-side requests (for example, updating a MySQL database) you should be fine.

Related

Sign In With Apple - App Access Token Support?

I'm just looking at migrating an existing Login with Facebook flow over to Sign in with Apple with the hope of eliminating FB Login entirely from our iOS app.
The client side seems straight forward enough, however there's one topic I can't seem to see any documentation or discussion on Stack Overflow about - a Sign In with Apple equivalent for FB App Access Tokens.
Facebook Login supports different token types (https://developers.facebook.com/docs/facebook-login/access-tokens/) and currently our app back end supports 2 authentication flows.
From End App Users, they Login with Facebook, send the provided client User Access Token to the app backend which validates the token against Facebook and then issues an app specific JWT token to the app client that is used in further app API calls until expiry.
From backend server components. These request an App Access Token from Facebook e.g.
curl -X GET "https://graph.facebook.com/oauth/access_token
?client_id={your-app-id}
&client_secret={your-app-secret}
&grant_type=client_credentials"
The App Access Token is then send to the app backend which validates the token against Facebook and then issue an app specific JWT token that is used in further server to server API calls until expiry.
Replacing 1 above seems straightforward but what about 2? Is there a mechanism for achieving the same flow with Sign In with Apple?
It seems like the https://developer.apple.com/documentation/signinwithapplerestapi would be the API to use for validation but is there a way to generate an App Access Token equivalent for Sign In with Apple in the first place to validate using this REST API?
Thanks
I think it's possible
I'm not exactly sure how to really use it or validate it yet, but you get an access_token in the response from https://appleid.apple.com/auth/token when Generating and Validating Tokens
Getting an access_token from Apple
This example assumes you have an Authorization Grant Code, but the same is possible if you have a refresh_token, etc. instead.
Prepare a POST request to https://appleid.apple.com/auth/token
Fill out the following key-values as x-www-form-urlencoded:
client_id
client_secret
code
grant_type
redirect_uri
If successfull, this will return:
**access_token**
token_type
expires_in
id_token
I'm not sure if this is the type of access_token you're looking for, but I wanted to bring it to your attention.
It may be useless for now
After writing this, I came across this thread in the forums where Apple said:
Currently, the access token only indicates a successful refresh token validation. There are currently no endpoints where it can be used and it is reserved for future use. So, it can be ignored for now.

Why Facebook encrypts an app secret code when access_token api are returned?

Why Facebook encrypts an app secret code when access_token api are returned?
Is there any something special purpose?
Currently, according to my tests, access token required apis can use both two types.
(raw app secret code and app secret code encrypted via bearer)
Even though I following a guideline that the code used in server side only, do I need to get encrypted access_token using the api?
Or don't care to use it just by assembling (client_id|app_secret_code) ?
Thank you first for your reply.

Doesn't Xamarin.Auth 1.3 work securely with Facebook OAuth?

Facebook documentation states that
the App Secret or an App Access token should never be included in any
code that could be accessed by anyone other than a developer of the
app. This applies to all methods of code that are not secured like
client-side code (such as HTML or Javascript) or native apps (such as
iOS, Android or Windows desktop apps) that could be decompiled. https://developers.facebook.com/docs/facebook-login/security#appsecret
For this reason, if your 'App Type' under Advanced Settings in the App
Dashboard is set to Native/Desktop we assume that your native app
contains the App Secret or an App Access Token in the binary, and we
do not allow calls signed with an App Access Token to proceed. The API
will behave as though no access token was provided.
Therefore if you embed App Secret in your app and tell Facebook about it, it will simply stop working with OAuth (I have also tested this, when you check that option, Facebook stops validating the secret).
but Xamarin.Auth 1.3 (latest stable) requires clientSecret (in OAuth2Authenticator class clientSecret is the required parameter) and uses it to obtain Facebook access token when user successfully logs in.
So is it a bug, is there a workaround, or Xamarin.Auth is useless with Facebook for now?
OAuth2Authenticator contains multiple constructors and there is one that does not require ClientSecret:
public OAuth2Authenticator (string clientId, string scope, Uri authorizeUrl, Uri redirectUrl, GetUsernameAsyncFunc getUsernameAsync = null)
This one will allow OAuth2 Implicit flow and thus does not need a client secret to be stored within your application's code.
Ref: https://github.com/xamarin/Xamarin.Auth/blob/9c19d90e52994188def9e12e0bbc981a3943a752/src/Xamarin.Auth/OAuth2Authenticator.cs#L110
Let's not confuse things. This has nothing to do with Xamarin.Auth.
There are two major options for OAuth2:
Implicit flow
Authorization code flow
The implicit flow does not require a client secret. The implicit flow is typically used with mobile apps, since they cannot keep a secret (you could disassemble the app binary and find the secret). Same goes with Javascript or desktop apps. The only way to protect the secret is if it is stored on a server which cannot be accessed by third parties (=the users).
The authorization code flow uses the client secret as an additional protection, the secret identifies a specific party, like a server.
So what does Facebook state? They say, if you configure your app to be a native/desktop app in Facebook's dashboard, they assume (!) that you store the secret in the binary, because: where else would it go? As a consequence, the secret is no longer a real secret, hence the Facebook API acts as if the secret was not there.
Two solutions:
Either you configure your app as not native/desktop (I don't know which term Facebook uses, maybe "Server")
or you use the implicit flow which was designed for mobile clients.
And to answer your initial question: yes, Xamarin.Auth supports Facebook's OAuth2, because it is just like any other OAuth2.

Is it possible to send a request to the Facebook Graph API from client side without exposing our access token to the public?

My question is related to, but not exactly, this question.
I am currently working on a business directory Web site (similar to Yelp), in which businesses have their own pages. Let's call this app DIRECTORY_APP.
Businesses might want to have their latest Facebook status update shown on their pages hosted on our directory. Let's pretend we have a business named BIZ_1. The assumption is that those pages are public pages.
Apparently the Facebook Graph API can be used for this purpose. So I can send a request to Facebook to retrieve the latest status updates for BIZ_1:
https://graph.facebook.com/BIZ_1_PROFILE_ID/posts?
access_token=DIRECTORY_APP_ACCESS_TOKEN
&callback=callbackName
However, if I use this from the client side, our Web site's access token will be exposed to the public, so this is not a reasonable solution.
Now in the aforementioned question, Anatoly mentions that we can retrieve the access token by sending this request first:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET
&grant_type=client_credentials
However if someone inspects the Network log, this will also expose our Web site's access token (is this correct or is this a different type of access token?). This solution also exposes our web site's app secret (is this safe?).
So to summarize, what's a safe way in which I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook?
I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook
You cant do that without login.
And I guess access token is not exposed.
Maybe the smart trick here is to use a social plugin. The Like Box will do what you want, without any issues. But, it's not greatly customizable. Even so, it's possible to get it looking nice on a page!
It also skips any login issues you mentioned.
I found the answer after some Googling. In short, the answer is no.
And here's an excerpt from Facebook:
Security Best Practices
App Secret and App Access Token
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
Therefore the App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app. This applies to all methods of code that are not secured like client-side code (such as HTML or Javascript) or native apps (such as iOS, Android or Windows desktop apps) that could be decompiled.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard.

REST API for website which uses Facebook for authentication

We have a website where the only way to login and authenticate yourself with the site is with Facebook (this was not my choice). The first time you login with Facebook, an account gets automatically created for you.
We now want to create an iPhone application for our site and also a public API for others to use our service.
This question is about how to authenticate with our website from the app/API and is broken into 2 parts:
What is the correct way to handle REST authentication from an API to a website which only uses Facebook OAuth as an authentication method?
I have read and researched a lot about standard methods of authentication for REST API. We can't use such methods as Basic Auth over HTTPS, as there are no credentials for a user as such. Something like this seems to be only for authenticating applications using the API.
Currently, the best way I can think is you hit an /authorize end-point on our API, it redirects to Facebook OAuth, then redirects back to the site and provides a 'token' which the user of the API can use to authenticate subsequent requests.
For an official application that we create, we wouldn't necessarily need to use the public API in the same way. What would be the best way then to talk to our website and authenticate users?
I understand (I think) how to authenticate 3rd-party applications that are using our API, using API (public) keys and secret (private) keys. However, when it comes to authenticating the user who is using the app, I am getting rather confused about how to go about it when the only way we have to authenticate a user is Facebook.
I feel like I'm missing something very obvious, or don't fully understand how public REST APIs should work, so any advice and help would be greatly appreciated.
UPDATE: see below
I've been thinking hard about this question too. It's not entirely clear to me yet but here's the route I am thinking of going. I am creating a REST API an my users only auth with Facebook connect.
On the CLIENT:
Use the Facebook API to login and get an OAUTH2 code.
Exchange this code for an access token.
In every call to my custom API I'll include the Facebook user id and the access token.
On the API (for every method that requires user authentication):
Make a request to the /me Facebook graph using the access token from above.
Verify that the Facebook user id returned matches the user id passed to my API from above.
If the access token has expired additional communication is required.
I have yet to test this. How does it sound?
--- Update: July 27th, 2014 to answer question ---
I only use the above exchange once upon login. Once I determine which user is logging in, I create my own access token, and that token is used from that point going forward. So the new flow looks like this...
On the CLIENT:
Use the Facebook API to login and get an OAUTH2 code.
Exchange this code for an access token.
Request an access token from my API, including the Facebook token as a parameter
On the API
Receive access token request.
Make a request to the /me Facebook graph using the facebook access token
Verify that the Facebook user exists and match to a user in my database
Create my own access token, save it and return it to the client to be used from this point forward
This is my implementation using JWTs (JSON Web Tokens), basically similar to Chris' updated answer. I have used Facebook JS SDK and JWT.
Here's my implementation.
Client: Use Facebook JS SDK to log in and get the access token.
Client: Request JWT from my API by calling /verify-access-token endpoint.
MyAPI: Receives access token, verify it by calling /me endpoint of Facebook API.
MyAPI: If access token is valid, finds the user from database, logs in the user if exist. Create a JWT with required fields as payload, set an expiry, sign with the secret key and send back to the client.
Client: Stores the JWT in local storage.
Client: Sends the token (the JWT from step 5) along with the request for the next API call.
MyAPI: validate the token with the secret key, if token is valid, exchange the token for a new one, send it back to the client along with the API response. (No external API calls for verification of the token here after) [if the token is invalid/expired request client to authenticate again and repeat from 1]
Client Replaces the stored token with the new one and use it for the next API call. Once the token expiry is met, the token expires revoking access to API.
Every token is used once.
Read more answers about security and JWT
How secure is JWT
If you can decode JWT how are they secure?
JSON Web Tokens (JWT) as user identification and authentication tokens
I am trying to answer the same question and have been going through a lot of reading recently...
I won't have "the" answer but things are getting a little clearer for me. Have you read the comments in the article you mentioned? I found them really interesting and helpful.
As a result, and in the light of how things have evolved since the first article has been written, here's what I think I'll do:
HTTPS everywhere — this allows you to forget about HMAC, signing, nonce, ...
Use OAuth2:
When authentication requests come from my own apps/website, use this 'trick' (or a variation of it) described in a reply to the article mentioned before.
In my case, I have two types of users: those with classic login/password credentials and those who have signed up with Facebook Connect.
So I'd provide a regular login form with a "Login with Facebook" button. If the user logs in with his "classic" credentials, I'd just send these to my OAuth2 endpoint with a grant_type=password.
If he chooses to log in via Facebook, I think that would be a two-steps process:
First, use Facebook iOS SDK to open an FBSession
When that's done and the app is given back control, there should be a way to get a Facebook ID for that user. I'd send this ID alone to my OAuth2 endpoint with an extension grant understood by my server as "using an FB User ID".
Please note that I am still heavily researching on all this stuff, so that might not be a perfect answer... maybe not even a correct one! But I think that would make for a good starting point.
The idea of using an "extension grant" for the Facebook authentication might involve having to register it to do things properly? I'm not quite sure.
Anyway, I hope I was able to help you even a bit, and that at least it can start a discussion to find the best solution to this problem :)
Update
The Facebook login is not a solution as pointed in the comments: anybody could send an arbitrary user ID and log in as this user on the API.
What about doing it like this:
Show a login form with a "Facebook login" button
If this login method is chosen, act kinda like the Facebook SDK: open a web page from your authentication server, which will initiate the Facebook login.
Once the user has logged in, Facebook will use your redirect URL to confirm; make that URL point to another endpoint of your authentication server (possibly with an extra parameter indicating the call came from an app?)
When the authentication endpoint is hit, the authentication can securely identify the user, retain its FB User ID/FB Session and return an access token to your app using a custom URL scheme, just like the Facebook SDK would do
Looks better?