I'm building a REST API with Laravel and now I have an URL like
api.example.com/posts/3/comments
Now I'm wondering how to secure this API because as it's done now, anyone trying to make a GET, POST, ... request on this URL will get positive results.
I want this API to be available to authorized apps only (like Facebook API). For now, those apps are just my website and my iOS app.
I'm thinking about creating a table applications to store application's keys. But I don't know how to authenticate an app without publishing it key (which is obviously insecure).
Any suggestion? Thank you.
I would recommend that you use something like JWT. Using it, you create and store a token locally on the device, then every time someone makes a call to the server, you check the token and make sure that they are who they claim to be. You can store tokens for expiration if you like. They're typically used in stateless apps, so you will need to move away from the concept of a server session. You can use Middlewares to filter HTTP requests entering your application.
Related
I've got a web app that currently allows users to login via Facebook. This is the only login mechanism at present. I make use of the user id and the users friends to perform certain actions. Now I want to create an api that I can use to create a native mobile app. To do this, I would need to authenticate users against the api. I've looked at this question
Possible approach to secure a Rest API endpoints using Facebook OAuth
but I don't actually have a "user" table as I only pull the facebook info when I need it. In iOS or something similar I could obviously make use of the native facebook sdk and then call my api, passing in the required user id and friend ids etc. however I'm not sure then how I could specifically secure my api so that if a user got hold of another's user_id they could in theory retrieve info via the api or in theory any resource that only specific users should be able to see
I thought about creating an app_id and app_secret for all the separate apps consuming the api. I would then use the appropriate secret to encrypt the data being sent and returned. The api and native app would know the secret and be able to decrypt it and validate that a user can view the requested resource. Does this sounds like a valid approach? In theory only the native apps would then be able to decrypt what is returned from the api. Or should this really be done on a user by user basis as recommended in the linked post?
All of this would be done over https
Thanks
Not familiar with the Facebook API nor iOS so I am speaking completely in theoretical terms.
Could you not:
Ask the user to login with Facebook on the iOS app
Send the login data over a secure channel to your web application to handle the actual processing of the data
Send the iOS app a secure hash for authentication
Use your web application as needed; using the hash for authentication, make HTTPS requests as you would your web application and use the responses from the webserver to populate the iOS app
If you make a user_hash column a complex salted hash like a SHA-256 (or greater) hash, the user_hash will become invalid before anybody is able to guess the hash. You could save the user's Facebook credentials locally on the iOS device and then renew the hash every so often, as to invalidate old hashes and lock out perpetrators (like how a cookie expires). If the user hash somehow becomes invalidated while using the iOS app, the app will send the locally stored credentials and retrieve a new one.
If Apple offers cookies for apps, you could send the hash in a cookie from your webpage and give it a reasonable expiry time (e.g. 1 day). You'd be resending the locally stored Facebook credentials every day and be effectively locking out anybody trying to bruteforce your hashes. Use that instead of trying to implement cookies from scratch (if the iOS API offers that), but as I said, I'm unfamiliar with iOS.
From an SQL standpoint, your webpage would validate a user's Facebook credentials, create a new row with a randomly generated user_hash, expires timestamp, user_id, friends_id, etc. Every user that uses the webpage will have to send the user_hash either from their web-client or the iOS app and will be checked against the database. If the present timestamp exceeds the expires timestamp, the session is ruled invalid and the user cannot operate your application.
Of course, you'd need to encrypt the communication. Do you pass credentials everytime the user loads a page on your web app? Or do you store them in a session?
Hope this helps at least somewhat!
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSHTTPCookieStorage_Class/Reference/Reference.html
Using app access token had previously been asked in this question (How to use Facebook appAccessToken with Spring Social) and Craig Walls gave a good explanation why the spring-social API should be user-based for most cases.
I have a scenario, however where I would like our server-side application to make a couple of queries that should not require user-specific permissions. I picked a random public page for examples below
I would like to:
View details about a public page by alias/id
https://graph.facebook.com/v2.0/121727254549188
https://graph.facebook.com/v2.0/peterstevensmotorcycles
View posts for a public page by alias/id
https://graph.facebook.com/v2.0/121727254549188/posts
https://graph.facebook.com/v2.0/peterstevensmotorcycles/posts
Search for pages
https://graph.facebook.com/v2.0/search?q=Peter%20Stevens%20Motorcycles&type=page
When I test these in the Graph API explorer (https://developers.facebook.com/tools/explorer) using an App Access Token they work fine. App Access Token is obtained by hitting https://graph.facebook.com/v2.0/oauth/access_token?client_id={app-id}&client_secret={app-secret}&grant_type=client_credentials and replacing client_id and client_secret with my Facebook client credentials.
Our application would like to have the ability to make these for any given name so we can make queries about a company's presence.
We will have similar requirements for Twitter, LinkedIn and others so I just wanted to check if there are any means to do this in the current API or whether it will not suit our requirements.
You do not need to fetch an app access token - you can actually use the app id and secret separated by "|" as the access token. - You can see it at the bottom of the app access token section in the documentation: https://developers.facebook.com/docs/facebook-login/access-tokens#apptokens
Spring Social's Facebook API binding does not (yet) support v2.0, but that's something I'm working on right now...so hopefully soon. Once that's complete, there'll certainly be some operations that work only with user access tokens and some that only work with app access tokens, and some that will work with either (FWIW, Twitter's API has a similar set of circumstances).
Keep an eye on the project in GitHub or follow #SpringSocial on Twitter to know when the v2.0 stuff is available. (I'd appreciate any help I can get in testing it.)
Although it makes no sense at all to obtain your FacebookTemplate via the connection framework for app token requests (connections are, by nature, a user-oriented concept), you can always construct a FacebookTemplate wherever you need it, giving it an app access token obtained via OAuth2Template's authenticateClient(). You can certainly do that now with the v1.0 API binding, but I'm uncertain what ops an app token would work with.
FWIW, as I'm working on the v2.0 API binding, I'm starting to sense an opportunity for FacebookTemplate to carry two tokens: A user token and an app token. This way you can perform app-centric requests even from a FacebookTemplate obtained from the connection framework. Then the only time you'd ever want to construct a FacebookTemplate manually is if there are some operations for which either kind of token will work, but the results would be different depending on what type of token is used.
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'm writing an API for our product and I'm trying to understand how some basic OAuth works with regards to mobile apps that might leverage our (to be created) api.
Lets imagine that our website currently allows a person to LogIn to our site via Twitter OAuth.
On the callback from Twitter, our server retrieves the twitter OAuth result and if all good, then checks to see
if this user already exists in our DB (eg. lets assume the Email is the unique key). If they don't exist, we
create a new user.
Of course, we then log the user 'in', which means we create a cookie for them, for their browser.
So far - nothing new here. All normal stuff.
Now .. if we want to do this via an iPhone or Windows phone using their native language and the app's use our API, i'm not sure of the point where OAuth ends and our API takes over?
For example, lets pretend it's an iPhone app that takes advantage of our API.
The iPhone app will try to authenticate the user against their Twitter cred's. Ok, fine. But when it callsback, it's back in the phone, right? Not our servers. So then the app needs to try and create a new user? So then the iPhone might try and call /api/CreateAccount. But this means -anyone- can call this api? And how does the website really know they have authenticated? Only because the app says so? What's to stop the person from creating a malicious app and calling our API by flooding it with new account creations? And what about authentication to api resources? Forms Authentication isn't available here. So do people use querystring authentication over SSL for api calls? How does the iphone authenticate with -our- server?
I'm so confused.
Can anyone please explain the differences and common practices people are doing these days when they have a website and an api .. and use OAuth as the authentication mechanism, please?
The naive app would call not CreateAccount, but VerifyAccount with twitter's oauth set of data so you site and API could verify it. The site would respond with a unique userID and your iOS app would use that as it's internal user id. More info.
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.