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.
Related
I am working on a solution to read log files from the GCP for an internal process. However, i am having a difficult time trying to generate an Auth Token for the request to grab the logs needed. This is more of a flow\context question rather than a whats wrong with my code one
The key issues i am having is that i do not want to prompt for web-browser authentication. I want to be able to do this all through API request and have no user interaction. Everywhere i have looked and all implementations i have tried, i am prompt for user interaction in some way and that is just not feasible for this solution.
How can this be achieved?
We do not have IAM enabled, so i cannot generate a JWT token.
I am trying to do this through using a Service Account created using client id and client secret.
I have tried getting a "code" to pass into a request to generate an authorization token, but that has been prompting me for user authorization in the browser which will not work, even when I add the query parameter 'prompt' or 'approval_prompt' to none or force.
I feel like i am missing one crucial piece to be able to achieve this flow and any help/guidance will be greatly appreciated.
There are several ways to authenticate API calls. If you want to do it without user interaction, you will need to use a Service Account (more info here). The process would be the following:
You use the client ID and one private key to create a signed JWT and construct an access-token request in the appropriate format. Your application then sends the token request to the Google OAuth 2.0 Authorization Server, which returns an access token. The application uses the token to access a Google API. When the token expires, the application repeats the process.
For this, you can use Client Libraries or you can do it manually with HTTP requests directly. In the docs there is a guide to do so.
I get a token from an autorization server that should be called only if the token expires. So I have to store that token somewhere on my client side. the problem is, I don't have a database to put it into, and I don't know if using system files is a good idea. I need your help to tell me what is the best way to store this token ?
You can save authentication information in the browser using cookies.
Many modern websites using cookies to store token.
If you use cookies the browser will automatically send the authentication information with every request to the API. This can be convenient so long as you know it's happening.
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.
I would like to know what is the best practice on how to work with authorized RESTful server.
Say that after login the server provides me a token, and then for each request I will have to provide it as well. My question is: should I save this token in my server's session? or should I do authentication against the data base for each request?
There are several ways. You could only keep it in memory, but then if you have multiple servers in a cluster, you'll have to make sure a request for a given token always goes to the same server, or to distribute the token among all the servers.
You could also cryptographically sign the token data, include the data and the signature in the token, and verify the signature at each request. That way you can be certain that the token has been issued by you, and you can be completely stateless.
Note that, if you're using HTTP sessions already, the token is redundant, since the session mechanism already uses a token in a cookie to track sessions.
Use a session cookie to track an authenticated session instead of hitting the database 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.