I'm practicing my Symfony 2 skills and would like to set up a simple REST API for a tiny application of mine.
I've set up REST Api with FOSRestBundle in few minutes. Perfectly. After setting it up, I've decided to secure it with OAuth. I've decided to go with FOSOAuthServerBundle. The stuff is working perfectly.
I've readed tons of materials and I'm wondering if I understand all of the stuff correctly. I understand how OAuth works, I'm just not sure if it was a good choice for my problem.
In fact, there will be many consumers available: users will be able to create their own apps based on the data fetched from API, there might be CMS plugin.
I suppose I misunderstood OAuth protocol in few ways: does OAuth always require end user action (giving a client app a permission)? Does users always have to re-authorize an app after access_token has expired?
Let's say an user want to fetch his content within my API - just to fetch some non-sensitive data. Does it require authorizing an app by the end user? I think I'm a bit lost here.
To avoid questions, yes I've read this few times and reading it all the time ;) I just think it's better to ask instead of copying terrible solutions, practices and false knowledge.
Related
I have a JSON REST API written in Symfony 2.7, and I want to authenticate & authorize users. This is my first time doing this, so I have some doubts/questions.
For that, I thought several methods:
User & password, and then save a session in the back end
Same as 1), but add an "apiToken" (randomly generate when user register) and then sending back & forth the apiToken in every single request to check user identity.
Use OAuth (which I'm currently reading about it).
I read that using OAuth for a simple API is like an "overkill", but on the safe side it sticks to standards and also allows me to use it when using my API with mobile devices and different platforms.
Also, I don't know too much about security flaws of using method 1) or 2).
I know this is maybe based on opinions, but I don't know any other site to post this question, as Symfony official mailing was shut down and migrate here it seems.
As you seems to know, your question is too opinion based.
If I can give you some advices (too long for a 600chars comment),
OAuth is powerful, but so much free.
I mean that you can easily implement it sort as everything works well while having a set of potential security issues without being aware of their existence.
Libraries and bundles providing OAuth are hard to maintain because of the new security issues regularly found.
On the other hand, if you need the benefits of OAuth (be a client and/or a server, compatible with the most part of social networks), go learn OAuth and do your experience with it.
Otherwise, use a simple credentials/request token two-step authentication.
See the JWT Authentication tutorial by KnpLabs,
Symfony Guard Authentication by Ryan Weaver,
and the great LexikJWTAuthenticationBundle, easy to implement and to use.
I'm building a single-page web application, fully based on RESTful API. I've seen several topics in that matter, but some things remain unclear for me.
I will need users to log in. Here are some of my ideas:
I can send e-mail and password to API and use basic auth. I'm not sure where should I keep password, should it be encrypted and if so: how?
Can I use built-in session system instead? Is it wrong to use cookies directly in the RESTful API? Why is it so popular to send credentials/keys to API itself instead of using cookies?
I thought about having one API key per user, return it in login action and keep it in localStorage. I guess it's not the greatest idea to have just one key per user?
Then, I came up with idea to have separate keys table and add random keys each time somebody logs in. On logout, the key would go away and no longer be valid. This is more secure than previous idea.
How is it solved in simple projects? I'd like to make it simple but not ridiculously inserure.
Please help.
The commonly approach is to use the header Authorization in REST. The state of the application must be on the client side with REST and shouldn'a be tied to a particularly client kind (browser with cookies)
I think that this link could be helpful:
Implementing authentication with tokens for RESTful applications : https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
There is also à great question to à similar question here : https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api
Hope it helps,
Thierry
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.
Not sure if the title of the question expresses good my problem, so I'm going to do my best to explain it here:
I'm writing a RESTful api using php and Restler. Now here comes the problem:
There are some services that I'd like to protect, that is, know if the user requesting that service has enough privileges.
All the services that I'm implementing have to be consumed using javascript, so the traditional method user/password won't work beacause everyone will see that!
I'd also like to limit the amount of requests an anonymous user can do, like twitter does with the search service.
What can I do to expose my api to everyone, but only let users with priveleges complete their requests?
I stumble with this post: REST authentication and exposing the API key but at the end, no solution was provided.
I'm very open to any alternative: like OAuth. I would like to use something that integrates well with restler though, but if that is not the possible, then its ok.
I've seen a lot of info, saying that an api key would do the work, but since I'm using javascript, how can I protect those keys from being used by other users?
Update: Restler 3 is released with hybrid access support using #access hybrid comment and is available here!
Just in time with the right question :)
Your question has two parts
1. How do I do hybrid access (both public and protected access) with Restler
Restler 2 does not support hybrid access, but Restler 3, which will be released in August 2012 (this week) will support hybrid access, exactly built for your use case
You can follow the development at twitter and/or facebook
2. How can I protect my API when the primary consumer is JavaScript
For simplicity you may use HTTPS with Basic Authentication or HTTP with Digest Authentication
Another alternative is described in this article. It is not written specifically for Restler but it is easy to adapt to Restler. Let us know if you need help on that
Assuming I want to create an app that allows users to login. The accounts are stored securely in a server. Some pages are also not visible to users who haven't logged in yet. Can someone guide me on how to do so? So like how to deal with "sessions" and all that. How would I do that if the database online is MySQL?
On another note, to implement "OAuth" the database has to be OAuth-compatible, am I right on this? And if so, how would I use OAuth on iOS? Is there an Apple API for that?
I appreciate any help / guidance
Thank you,
Let's do this part by part:
It doesn't matter what is powering
the server-side of things. Be it
MySQL, Oracle, SQLite, if you have a
dynamic language that connects to
that DB and outputs XML or JSON
data, you're set.
Dealing with sessions is easy. You
can use NSHTTPCookieStorage to
have that handled automatically for
you. Because sessions are set via a
cookie, any HTTP request will set
that cookie locally and send it in
future requests.
As far as permissions go, I would do
that validation server-side. Because
you have the session, and you should
know server-side wether the user is
logged in or not, just send a list
of pages the user can see.
There are a few OAuth libraries you
can use. The OAuth project lists a
couple that seem straightforward
enough to use. If you're looking for
Twitter integration however, a
question has been asked here
with pretty good answers.
Returning to the server-side of
things, this can be easily achieved
using a dynamic language such as PHP
or using the Ruby on Rails
framework. RoR is really good in
that aspect in the sense that you
can quickly bring an API up by using
its gems (Devise, OAuth2,
etc)