Been googling for a couple of days and haven't really come across any answers as to how facebook / google plus or other websites authenticates their applications (maybe it's because it may be a risk, not sure but still can't find any answers.)
I'm looking to run a website where users can 'install' web applications - Like facebook / google plus does.
E.g: User visits a stack overflow application, it requests permission and get's authenticated.
How would I go about doing this?
I.e how to cross check whether the application is authenticated to the user and the application ID matches the actual application being used to prevent rogue applications using the same ID which is known to be authenticated.
The only way I can think of is checking whether the user has allowed the application or not.
Pseudo: "SELECT * FROM authorised_applications WHERE user_id = '123' AND app_id = '234'"
If they have, allow the application to access some data (i.e user name etc).
if(mysql_num_rows(pseudo_above)=="1") { allow }
However, what if a rogue application uses the same application ID (which, if we presume, is authenticated) and thus can access the data.
I may be over thinking things and confusing myself but I can't really think of how to do this.
To authenticate with those services, they use OAuth. I suggest reading this great article:
http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/
From what I understand you are looking to set up something similar to that for your web application. I have not used OAuth in conjuction with PHP but I am positive that there are lots of resources out there for using it.
Related
I know this is a pretty discussed topic but i'm struggling in finding a solution for my case.
I have done an already working API service in ASP.NET (c# 4.5.1). My clients uses php pages to call a page.aspx on my server and sending via POST a string. This string contains an ID and a cypher message. Every user have a different key (AES 256) and, since i have the ID i get from my DB the correct key to decypher the message and do what its request contains. I also check the IP, every client have only a list of approved IPs (when they are not using the debug mode for testing)
I like this method but now i have to let my users do some purchases. I already implemented it (thank you PayPal) and it works, but i feel my security weak.
So i wanted to add some already known and already wrapped authentication system, without re-writing any of the already working and debugged code.
Since is used from lot of big internet services i thought about OAuth 2.0 (and i know nothing about it), but looks like everyone who talks about it is for creating a login that uses services like Facebook, Google, Twitter and go on.. not my case. I have my own database with my user list and i need to know with 100% security who is calling my API service.
I tried creating a new Web API 2 project (MVC.. damn) but i cannot understand if i can use for my service without rewriting the logic for API calling (and from what i saw looks like no is the answer)
So the question is: What authentication method can i use that is easy to implement without rewriting the already working code and can be usable from clients with PHP?
I was watching "ASP.NET MVC 5 Fundamentals" tutorial on Pluralsight by Scott Allen where he explains it quite nicely. But before watching that tutorial, for one App I worked on, we had a table in the database with tokens that were issues at Login. Then the client would send the token with their request. At server side, I did a custom attribute called [CheckToken] inside which I would check if the token exists in the database and if it is stil valid (not expired, etc.) I went a step further and sometimes swap the token so that even if the token gets stolen, it would not be valid for long. That way, the user does not have to keep login in all the time.
I had a scenario and want opinion by you people.
I have different web applications developed in Django, Rails, PHP , I want all of them to share the same session data every time. Means if a use is logged in to a PHP app, it can automatically be logged in to Rails app and vise versa.
I know its some kind of Central Authentication Server. Some of these are cas, josso.
What do you people have opinion for it. I want the behavior like Google Apps, when i am logged into Gmail, i can automatically logged into GoogleDocs as well.
Please share your thoughts, that how to implement this scenario?
Google runs entirely off the .google.com domain, which is why they have absolutely no problem using a single cookie to identify you across applications. If your applications all run on the same domain, I'd say go ahead and write a custom implementation to authorize users with a shared session cookie.
However, in the more likely event that this is not the case, you're better off implementing one of the more popular and wide-spread SSO methodologies like OAuth or OpenID seperately in your applications and either giving your users a centralized application at which to authenticate, or let them authenticate via external providers (like Facebook or Google, which supports authenticating via OpenID)
You can run your own OAuth or OpenID endpoint at which your users register and then auth via this endpoint on any of your applications.
In PHP, you can use session_set_save_handler to specify how the session is persistent and restored. I guess Django and Ruby On Rails provide similar means
just store the sessions in the db ore handle them yourself completely
the best approach would be to create a special table for this
watch out as php want to store this data sialized so unserialize before storing in the appropiate field as serialized data is too hard to handle
in php you have
$_SESSION
and session_set_save_handler()
but i think it is better for you to make it yourself
make sure all sites use a single cookie domain(ajax onload(to try getting this coockie), or keep the same domain)
In my apps I use SESSION to store a value of logged in user. For example $_SESSION['site1']['bakcend']['loggedin']=1; Than put a session check on other places. They of course are all under same domain.tld If you use above example $_SESSION['site1']['bakcend']['loggedin']=1; you will need a lot of checks if you have many sections. But this is only an opinion, there is a place for much more flexibility.
You can use cookies too.
Preamble: This is very close to this question, and I have read this article on how the system works, and the flaws in the current implementation.
We are developing a Wordpress plugin (PHP) that requires read-only access to a user's account, (to access the statuses/home_timeline API method). This plugin will be openly distributed for people to use, and should be as easy to install as possible hence the desire to embed the application keys for a pre-existing application within the plugin code.
I understand that another application could be developed using the keys, but since we are not writing to the account, the risk must be large enough to be worried about when the only alternative is to require every user of the plugin to generate their own application.
Given the above, in what way could our comsumer_key/consumer_secret be used other than as intended, and what could the possible outcomes be, (outside of Twitter-related smackdowns)?
In general minimal.
Consumer token pairs ure useless by themselves and the only way to get a users access token pair is to have the user go through the authorization flow on twitter.com. It will be your brand the user sees on the authorization page so if the origin page is presented in to mimic your own brand users will think they are actually giving you access to their account not the actual owner of the origin site. Once a third-party gets ahold of a users access token pair and the app is read only then there are two dangerous actions that can happen. One all private information from their friends protected statuses to their DMs will be accessible through the API. Two they can perform a sort of DOS attack and eat up the users rate limit leaving the API essential useless to them for all non whitelisted third-party applications.
If the consumer token is used to build a spam farm that is putting a significant drain on Twitter's resources they might disable or reset the key. At which point all copies of your code would stop working until you get a new key and everybody updates to the new version.
Let me know if any of this is not clear.
i have 2 sites (example.com, ex2.com). Fisical is a 1 site with 1 db. When user sing in ex2.com, he was sing in example.com too. How do this?
P.S. Can do this with ZF?
I found a very interesting article on this topic. The author gives some ideas how to implement Multidomain authentication.
http://codeutopia.net/blog/2008/09/25/sharing-authentication-over-multiple-sites-single-sign-on/
Have you looked into OpenID? You could lock OpenID consumer "ex2" to allow logins only from your "example.com" OpenID provider.
I am also digging the subject. Some time ago, I already did my own implementation and got it terribly wrong.
At the moment I am wondering whether to setup an own OpenID provider and locking consumer sites to accept only it. Another alternative would be yet another own implementation with a CAS style setup, where only a hash is passed via the browser, and the user verification is done server-to-server in the background using the hash as a disposable key.
I am not yet sure which one to pick or would some third alternative be better.
You could take a look into something like http://cosign.sourceforge.net/. Cosign enables you to create a single point of login for multiple sites. It's not specific to Zend but should work.
We have developed a B2B Web portal for Graphics Job Work which is similar to Camera Ready Art (www.camerareadyart.com). It is targeted for people wanting to convert bitmap to vector Graphics, Logo Designing and general image processing like coloring B/W images to color,etc.
We want to add facility so that people (our clients) can use a set of API that we provide to post their work from their site directly without having to visit our site literally to post their work.
I have never done anything like this till date so I have no ideas as to how I can implement something like this. I also want to know about how we can implement security so that only those who are authorized can post their work?
Can anyone give me ideas as to how we can do something like this.
This question covers a very large area and I doubt any single answer could cover matters in detail. What I can do is offer some starting points based on the mistakes I have made.
Build on top of your own API
Don't add-in API features to an existing system. Doing so will:
lead to additional testing load (you'll have to test both your app and the API independently)
result in an increase in overall maintenance costs
result in a poorer quality API than what you want to offer
Your overall goal should be to build the API first and then build your app on top of your own API. Doing so has the following benefits:
testing of the API is inherently performed whilst testing your app
you won't 'forget' to add any required API methods
Your app and your application logic (the API) will be logically separated - there will be a clear separation between them in terms of what each side of the equation does and what it is responsible for. This will help guide development. This will also allow you to very very easily put the app and the API on different machines as and when this is needed.
Using your own API is a very important point. The design of your API will initially be sub-optimal and only through using it yourself will you be able to make it offer to people the features that are actually needed in a way that is efficient.
You will end up with a system that roughly looks like this:
------------- -------------
| | | |
| Your APP | <= HTTP communication => | Your API |
| | | |
------------- -------------
This highlights some further benefits: you can replace 'Your APP' with any other app, allowing customers of yours to create apps to deal with things in ways that work with them best. You can also create new versions of your app on top of the existing API - moving to a new version of your public web site can be much easier.
Designing your URLs: mapping to classes and methods
Choosing sensible URLs is as much of a problem as choosing sensible class and method names. Deriving URLs from classes and their methods is a good approach. If there is no sensible correlation between URLs and classes/methods, you will find things harder to maintain in the long run.
I personally prefer to associate URLs to classes and methods in the following ways:
map classes to top-level directories
map methods to sub-directories of the top-level directories
Example:
The URL of your API is https://api.camerareadyart.com.
You have an image object with toColour() and toBlackAndWhite() methods.
This may map to:
https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/
Similarly for bitmap to vector conversion:
https://api.camerareadyart.com/bitmap/toVector/
Designing responses
When someone GETs data from, or POSTs data to, one of your URLs, what happens? How are errors handled, how are exceptions dealt with? What form do responses take?
I can't tell you what to do here. Personally I prefer to map things as closely to HTTP as possible and then only go beyond this when needed.
For example, if an incoming request is accepted and is processed but runs into an error internally I would issue a 500 status response. Likewise if a given API method requires authentication that has not been provided I might issue a 403. Taking advantage of existing HTTP features prevents you from having to re-invent certain things.
Use existing aspects of HTTP
As well as using HTTP status codes sensibly, make sure to look around for an HTTP-only method for doing something before rolling your own solution.
Want the user to specify whether the response format should by XML or JSON? Use the HTTP Accept header.
Want to re-direct a client to a different URL to grab the result of a request? Use the HTTP Location header.
There are many features to HTTP that already handle many things you might want to do. Use them!
Security
There are two general problems to tackle here: authenticating the user, and determining what actions a given user can perform.
Security: authentication
The user will need to specify in their request who they are.
The first solution to spring to mind is to allow the user to specify a username and password, possibly the same as the username and password they use to access your app. This seems on the surface to be a good idea but it is not ideal.
Users will end up baking their username and password into their own apps. Inevitably one user will forget their password and will change it so that they can happily access your app, breaking their own app in the process.
A better choice would be for the user to supply an authentication token, which is essentially a single value unique to a user much like a username and password rolled into one.
This allows you to logically separate a username and password from access to the API. A user can change their username and/or password for your app as often as they like without breaking their access to the API.
A user can also have multiple API tokens, each with different levels of access, allowing a user to safely give out an API token to a third-party service.
Security: access control
As far as the outside world is concerned, your API is a set of URLs. Each URL is, by definition, unique and performs a unique task. Basing your access control mechanisms around these concepts is a good starting point.
I prefer to keep a list, per token, of the URLs that token is permitted to access. When a given token is used to access a URL it is trivial to tell which URL is being accessed and whether it is in the token's list of allowed URLs.
If you choose a set of URLs wisely, where each URL performs one unique action, this process provides you with about the finest level of access control as you're going to get.
To give a finer level of control you may also want to specify, per URL that a token is allowed to access, what query arguments they are allowed to use.
You obviously need to have your backend webservices designed and working. However, all additional features (security, throttling, OAuth key management, subscriber portal, interactive console to try the APIs, etc.) are a fairly standard set of features that you probably should not be developing yourself.
There are commercial API Management solutions on the market. I work for WSO2, which has a 100% open-source (Apache License) WSO2 API Manager, that you can download for free here or use as a cloud hosted version in WSO2 API Cloud.