Not sure the title is appropriate, but here is the problem
1) I have REST API developed using Jersey (Java)
2) I want to use Facebook login to authenticate users
3) Now Once user has logged in to my website using FB, and API are beings accessed from my website using Ajax calls, how do I make sure requests are from already logged in user and also how to get the user identity(profile id etc.)
What would be best approach to address such API usage?
The user's 'profile' should be stored and accessed from the HttpSession. Which your web container should manage for you and most likely will use cookies. For example tomcat sets a cookie called jsessionid and uses that cookie for managing with session to use and therefore which user is making the request.
Generally for a 'REST' service, the end user should be validated every call.
I would recommend looking into Basic Authentication (over ssl only) and/or O-Auth2.
Related
I have my html basic form and java server(REST) side and MYSQL as my database.
I want to implement a secured authentication login form plus after login every rest api's must be called by the valid users only.
What are the points to consider for developing secure login page? One thing i know is login api must be an POST method. What are the other points needs to be taken care?
Where to save the state of the logged in user so that immediate calls can be verified using that state. Is it to be client side or server side? If on server side then that violets the RESTlet principles
Am i require to store the encrypted password in the database? If yes then which encryption algorithm is best?
Thanks,
I have two web applications, app-A and app-B (both will be hosted on different servers). Now for a particular event in app-A, I need to call an URL to app-B so that app-B can do some processing. Inside app-A, I am following login/logout for authorizing users. So at app-A, everything is secure.
But if the URL is exposed to someone, they can play with my app-B. So how I can validate in app-B, that the request is coming from an authorized user of app-A ?
I am using Java (Spring MVC). Thanks in advance for your time.
UPDATE :
app-A and app-B both will be hosted and exposed to public.
app-A and app-B have different set of users (tables) in database and login mechanism.
the scenario is with app-A the admin logs in, and does some activity. This fires a call to an unprotected url of app-B. Question is - how do I make sure in app-B that the call is coming form the admin of app-A only, not from any outside users.
You need single sign on server, like CAS is the good one .
You have to create link that will have included specify request and, some custom text (for example: session id) and digital signature of this text signed with private key that will be shared for both your aplication. app-B can validate the signature, and if its pass, then fire the request.
[edit]: You have to remember that that passing token have to have limited live time, otherwise if someone caught the link he will be able to use it later. So you can add to your 'custom text' (mentioned above) date and time of token creation and let app-B do not fire request that where created more than 5 min ago.
I am writing an additional service for a website, which utilises the existing login behaviour, while requiring some additional signup details from the user. The new service runs in a different subdomain.
The user will be able to create resources on my data web app, which must be saved against that user's data collection.
I expect that this user identifier will be passed to the webapp in the body of the http request. However, I am concerned that a malicious attack could rewrite the user name in the body to make requests appear as if from another user.
What can I do to make this safer? (And does this count as a CSRF attack?)
The new service is written in Java, with Spring 3.
You can never ensure an http request comes from a specific user, you can only attempt to validate a user and a request. Usually this is done by creating a ticket during the login or authentication process, then requiring that ticket on subsequent requests. You can then match the ticket with the user and accept that as valid. The ticket expires after a period of inactivity, requiring the user to login again.
You should pass the requests through the same security stack that the main website uses if at all possible.
If it isn't possible, I would use Spring Security to handle the authentication. I'm not sure what plugins already exist for Spring Security for authenticating service requests like that, but you could always require that a cookie be used for the session, and then it's just a matter of the client dealing with the authentication steps.
So, you could use a "normal" form logon, or you could put together a token request setup, but that is much more involved.
What is the best way to have a session between a Restlet Java API and GWT? In my app the user will login with a username and password and if it successfully authenticates the userID is returned. This is then stored in a cookie and used in calls to the API. This is obviously completely insecure because someone could just change the userID and start updating and retrieving another user.
Is the best way to also hand a token back with the userID and the API calls must contain that token?
The token is a good way and I've seen it in a lot of implementations. Usually, this is handed over as a simple parameter for each request. Following the RESTful idea you can also just include the credentials in the HTTP request each time.
I am in the middle of developing a PHP social media web application which will be supported by various web services each operating a REST API. Web services will probably be implemented in Java with MySQL data layer but the whole point of what I am trying to do is make it really easy to implement modules in different languages/data stores depending on what is approriate.
So for example when the user logs into the application via a login form the PHP code connects to a web service and POSTs the username and password to check if they should be authenticated. I would normally at this point start a session and store it in a session data store.
Another example could be if a user sends a private message to another user. The message would be POSTed to the private messaging web service which would take care of all the storage. Similarly the web service could be contacted to retrieve messages for a user.
Although I understand how to implement the REST web service in Java and make the connection to it in PHP I am totally unsure as to how to secure the data being passed and make sure that it is the users data being returned. If for example I want to get all of user As private messages how does the web service know to return that users. I could pass that users identifier as part of the GET url but then surely any old user could just figure out the GET url and use it to look up other peoples messages. I thought maybe I could pass over the session identifier and IP address which would allow me to check the session data store and make sure it is the correct user?
To secure the data that is important - like the username/password I thought I would just pass it over SSL.
Hope this explains my problem better.
Thanks
Take a look at HTTP Digest authentication. Most clients should support it, and it means the auth details can be passed securely with each request as part of the headers without interfering with the payload of the request itself.
I think requiring OAuth is a good choice. Your end users should appreciate that other websites don't need to ask usernames and passwords to access their data. As far as SSL, it's clearly worth doing if you can. You'll have to see if the performance trade-off is acceptable.
Keep in mind that your api must mimic the HTTP protocol.
Http is stateless, and by adding any Sessions or so, you're trying to fake an "Alwaysconnected" method.
With a LoginForm, it's like I'll have to send two requests for each calls ;)
These are basically 2 questions.
When privacy is a concern I'd go for the safest option: Serve data over SSL (via HTTPS).
As far as authentication is concerned, there are several possibilities. Basic over SSL is one of them, but a simple login form with a cookie can be another one. (ASP.Net Forms Authentication for example.) This all depends on how you want to implement your authentication mechanism.