Following up on the design outlined in Design for Facebook authentication in an iOS app that also accesses a secured web service, and specifically the concern listed in https://stackoverflow.com/a/12912616/5154090: what would be the mitigation?
Specifically, I have a web server that exposes a REST API which is consumed by a mobile app. I'd like users to authenticate to the server (via the app) using Facebook.
Now, an apparently common flow is for the app to redirect the user to Facebook, where they will login with their credentials. The app will then get a token which it will send to the server, and the server will validate the token using the graph API.
But how can the server make sure that the token really came from the app? Specifically, what's to prevent a malicious app vendor from re-using my app ID? After all, the app ID is hardcoded into the app and can therefore be extracted and used by a malicious app. If users log into that malicious app with Facebook, then the malicious vendor can get tokens with my app ID and can impersonate users of my service.
How can one protect against this?
To summarize for anyone else who happens to contemplate this - there is indeed no way to prevent the client ID from being spoofed. This is one reason that developers are discouraged from using the OAuth implicit flow in native apps as pointed out by Andre D in https://stackoverflow.com/a/17439317/5154090:
the use of the Implicit Flow with native apps is NOT
RECOMMENDED.
(see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-09#section-8.5).
In practice, if anyone mounts this attack, then the user will download App A (a malicious app) and will then be asked to authorize App B to make actions on their behalf. As far as I can tell, this is generally the only indication that an attack is taking place.
Related
I'm building a web service for use as an api component in web sites or apps built by others.
I am building a set of functionality that my clients can use on their sites for their users, but which are served by my application.
One of these services is user login. I intend to support multiple types of logins, and provide the client application a user token once the user is logged in. So the client application only has to implement one login interface, but they get a variety of oauth2 strategies for it.
To make this work with their google or facebook accounts, they would have to provide my app with their application id and secret key. Entering a secret key on someone else's site, even for integrating with your own site seems dangerous. They call it a "secret" key for a reason.
I have found one web service which seems to be doing something similar to what I am planning to do:
https://www.authic.com/documentation/google_oauth2
They have a configuration page for client accounts where the user enters oauth2 credentials to enable the Authic oauth2 login pages on behalf of the client app.
What are the security concerns to be aware of with this kind of service, and can the client app use a service like this safely? If it can be used safely, what is required for safe use? I think the app doing the oauth2 interface would be able to do other things on behalf of the client app, since it has an app secret, and the client app owners would have to trust that this was not happening.
The alternative to this strategy seems to be using my own application id with oauth2, and having the client apps redirect to my app's login page. Then the user will see the oauth2 permissions page with my app's logo instead of the app they were intending to log in to.
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
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.
I would like to implement an iOS app with Facebook login. I would like the users of my app to be able to interact with their social graph (i.e. post to their stream). For that purpose I would use the Facebook iOS SDK.
When the users are already authenticated with Facebook, they also should be able to use some services on the server side of my application. How can I verify a user against the services on my server?
In my iOS app I can query the access token (for my Facebook application) using the iOS Facebook SDK. Should I send that access token together with the facebook user ID to my server? Can the server verify whether the access token is valid? Or should only my iOS App communicate with the Facebook API? Can the server post to my Facebook wall, or should this be done exclusively throught the iOS app?
UPDATE:
Facebook now provides a security documentation / checklist:
https://developers.facebook.com/docs/facebook-login/security/
You have at least two options:
Send the access token to your Server and handle all requests to Facebook
using that token (if the token is invalid you get an error and just
pass it on to the client). => Safe but (a little) complicated.
Separate the communication between
your client (iOS App) and the Facebook API and
your Client and your Server.
Your app would handle all requests to the Facebook API through the Facebook iOS SDK and then communicate the resulting data, like all kind of Facebook ids, to your Server. This approach is totally insecure without some sort of encryption; you could send some cryptographic hash function to your server and validate it with a key stored on your server and the iOS App. => This method is (a little) easier to implement however less secure since the key can be stolen through reverse engineering. Moreover you would have to check the "I'm using encryption" check mark when submitting your app to the app store.
It actually depends on how much risk you are willing to take, what kind of requests you make, what kind of services you have and so on.
Can the server verify whether the access token is valid?
Yes, look here: Facebook access token server-side validation for iPhone app
Is OAuth sensible to use when the user account info (user id's, passwords, roles, etc) is going to be maintained in our own back-end and when there will not be any sharing of resources with other sites? Or is sharing the whole point of using OAuth?
Background:
I'm working on developing an enterprise SaaS product and we are creating a RESTful API to be used by our front-end applications. Consumers of the API will be browser and native smartphone (iOS & Android) applications that we develop. Since we'll be supporting multiple client types, it makes sense to create a RESTful API that all our client apps can consume.
Naturally we need to secure this RESTful API. We are considering authenticating using HTTPS / Basic Auth but we are aware of some of the well known drawbacks to this approach.
Some quick research shows OAuth is highly recommended. But most of what I find with OAuth is in the context of authorizing web sites to share information on behalf of the user.
Any info if most welcome.
Good question, and we're having a good discussion on this over at API Craft:
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
Here's the answer that I posted there:
I think this is a good use case for OAuth, actually.
First of all, with OAuth your mobile app can store an OAuth token on the client rather than the user's "real" password. So, you can have the app automatically "log the user in" by getting an OAuth token without having to store the actual password on the device. If the user loses the device or if it's compromised somehow they (or you) can wipe the OAuth token without requiring that the user change the password and blow away other things that they might be doing with your API. There are similar examples for an Ajax-style web app but it depends more on the specific way that you build the client.
Second, the OAuth token is associated with a unique key that identifies the app that is making the API call, and that in turn identifies which developer built the app. That gives you options like tracking usage by application, turning off an application that might have been compromised without disabling the whole API, and if you ever want to open access to third parties or partners who build apps for your API, you can offer different levels of service to other customers.
Third, your IT security people will be happy if you tell them that you never store a password on the user's mobile device or stash it somewhere in their browser.
Fourth, you have the option of browser-based login for the mobile app. That means that the mobile app will never see the user's password, and also that if you want to implement two-factor security or something like that, you can do it in the login screen without changing the mobile apps. Now, the downside is that the user sees a browser window pop up. That's why OAuth gives you a few different ways to get an access token for an app, so you can choose whether you need to have browser-based login or have the user enter their password directly in the app.
Fifth, how do you know that your API will only ever be used by your own apps? If you use OAuth now then you will have an easier time making that transition later.
Yes, this is a very good fit for OAuth. You can still use HTTP Basic over SSL during the handshake for authentication. The output of the OAuth handshake will be a token which can then be used to consume the API. This way, the application does not need to store the credentials and tokens can easily be revokes with minimal user impact.
OAuth 2.0 defines a number of different grant types for accommodating different situations. It sounds to me like the 'implicit' or the 'resource owner password credentials' are the most appropriate but you may want to consider each carefully.
You should not implement this directly in your API but use infrastructure to delegate the OAuth support and token management on behalf of your SaaS API instead.
Take a look at
http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/
and
http://www.layer7tech.com/products/oauth-toolkit
Hope this help,
-fl
I implemented an OAuth for Django nonrel with piston to expose my APIs to consumer. There are a number of kind in OAuth(2-legs 3legs).
Generally, supporting OAuth is quite a bit challenge. You have to obtain the request token, authorize it, store the access token to sign every request you want to authenticate.
Advantages
- You don't have to send username and password everytime, secure.
- Enable third party to consume your app.
Disadvantages
- Make 2,3 round trips to authenticate.
- Complicated to implement it by yourself.
I'm pretty sure that you can find a number of library that allow you to:
- Expose your Api and support OAuth. E.g Django piston.
- Sign your requests by adding headers to them. E.g Oauth-signpost.
OAuth is only a token and the requesting App will issue one. You can read more in pingidentity.com where there are several webinars on this topic(cloud identity and user provisioning) as well.