I'm struggling with an issue here. I've searched repeatedly for answers, but have been unable to find the exact answer I'm looking for. I'm attempting to build a secure authentication method for a REST api. My question is, how do we handle a login for a REST api?
Since a REST api is meant to be stateless every time, does that mean we need to store the client's username/password on the client's end (perhaps hashed), and send it in with every request? I'd be much more comfortable using a system like authentication tokens that are created upon logging in the first time, but does that go against the basic rules of REST, since this technically creates a "state" on the server?
What is the best and most practical method to handle this? As I wrote earlier, I'm struggling to come up with an answer to this; maybe that is due to this problem not having a clear answer, but I honestly don't know.
Thanks in advance.
That's also my understanding of REST: clients send login/password to the server along with every request. The server has to authenticate the client based on this information only. With regard to the Hypermedia principle of REST, having a user logged in is not an application state, in my understanding.
Related
I am currently learning to make DRF APIs for something I am working on. I was wondering how exactly I would secure the API POST requests I send via the client side?
For example, let's say I have a log in form where the user can enter their information, this information needs to be send to (or POST-ed to) my API for verification. I do not want just anyone sending requests to the server and so, I would want to use an API key but since this is being done on a website, anyone could see the API key if they wanted to, and then exploit the server by sending a ton of requests.
My current idea is to use serializes in DRF to check if the API POST request has everything it needs but I am fairly certain this can be easily found by checking what sort of JSON my code sends to the server, so how exactly do I go about securing this such that I can send the information to the bare domain (like http://127.0.0.1:8000) and then have code which can accept that information?
I apologize for any confusion, if it is confusing. Let me know if you need any clarification.
If you are creating API any one can send request to server. same goes for website and webpage. Their is no way you can avoid this. But their are ways to handle possible misuse.
like using CAPTCHA for login form which can be filled by one on the web. though wrong CAPTCHA text can be send by anyone you must check it on server for their correctness. or use google reCAPTCHA like services for outsourcing this task.
API key should be given after login NOT before login. and if it is given after successful login then the key is obtained by legitimate user which can obviously do whatever he is allowed to do on website. their should not be problem in that.
further explanation to the question will lead to details of denial-of-service i.e DOS attack. you should consult expert on that field if your application requires to handle DOS attack.
I want to create a custom API that behind the scenes, call number of other APIs which use OAuth 2.0 for authentication. I want to manage this internally so that my custom endpoint somewhat abstract this.
Or to begin with I want to do what app like buffer (https://buffer.com) do - where you connect to different social services and than post your status.
How can I achieve this in .NetCore ?? I don't want to login with these (a lot of samples are catering this scenario), user login is different than this. I just want to establish these connections (like API Connections if you look at Azure API Management) and then perform some operations against those endpoints.
I hope i convey my point. please let me know if this isn't clear.
Thanks
Sanjay
OAuth2 systems are all based on the same workflow.
here's an authorization url, you pass some ids in an authorization header, if everything is correct you get a token, you then use the token to do whatever you are allowed to do. What changes are the credentials you use for authentication and the urls you hit for the various parts of this workflow.
You could write your own OAuth2 library which deals with all this, that's pretty much what I did and simply changed the details for every specific system I had to interact with.
This being said you can always use one of the existing implementations to connect to the various systems you care about, they all have an API you could use, all you have to do is make sure you follow the OAuth2 flow correctly.
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
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/