After going throught lot of comments from different people about session management for Rest supported applications, here what I have thought of doing.
My application can be accessed from Browser (as a normal web app) and Mobile devices as well. Application was written with the http session management in server at first for browser based app. Now while getting Mobile client, we have implemented Rest web services, with same service layer for mobile device and browser client as well.
When user logs in with mobile device, we are creating a unique auth token, generate a http session and we store the http session with this token ID as key, value map in app. Later on we expect every user request from mobile device to return this token, and using this token get the session from map and continue.
Can somebody review my approach and confirm if it is fine?
Now, I have a second question - We are using JsonPRequestBuilder from GWT to invoke my back end REST services with jersey-guice. How do I send this token in http header during jsonp call from GWT?
"Session in REST" is an oxymoron.
When user logs in with mobile device, we are creating a unique auth token
Seems fine, though it looks a bit like you reinvented OAuth.
generate a http session and we store the http session with this token ID as key, value map in app.
Keeping some cache on the server-side for faster access is fine, but don't call it a session, and don't bind it to a specific token (you can bind it to a user if the data is user-specific; the user ID would simply be part of the cache key if it makes sense).
You don't talk about expiration of that cache, or how/when you clean it up and free memory.
Now, I have a second question - We are using JsonPRequestBuilder from GWT to invoke my back end REST services with jersey-guice. How do I send this token in http header during jsonp call from GWT?
As #Arcadien said, JSONP is just about inserting a <script> element in the page, so you only have control of the URL, and thus this is where you should/can pass the authentication token (albeit not being really secure).
May I question the reason you use JSONP from a mobile "native" app? AFAIK there's no SOP issue from UIWebViews or similar, so a RequestBuilder or XMLHttprequest would Just Work™.
For the second : with JSONP, you have to add your token as plain http parameter, you have no access to an object like Request when using regular XMLHttpRequest. So you can't set any kind of headers, everything should go in the query string.
Related
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
I want to develop a java application with REST web services, as it will have browser client and mobile client. My concern is session management, could anyone suggest me what is the best and recommended way to manage the session. Scenario: An employee will login and then he will call for other services like salary details, work hour details, permanent address etc. Here all these details will be exposed as individual REST web service. After login of employee any further request like request to see the permanent address will be REST service call. Please provide me the best and recommended solution.
In scenario where you want to support mobile as well as web application, token based authentication and session handling can be a good approach you can follow.
You can either go with existing token based third party API's like (OAuth2) or you can create your own token based session management system.
Proposed Solution :
Whenever your application get's first hit create and save the random token (say 64 bit random generated string).
Mobile and Web Application will save this token in it's memory and send this token in headers every time it makes a webservice call.
You will need one web service which will accept all your request and redirect request to your application only when token is valid. If token is invalid it deny access to the applicaton service. (Gateway7 works in same way)
You can pass a key for every webservice url. say app.xyz is my identifier. Which points to xyz url of my application 'app'. So your url's will be maintained at server and client will only have identifiers and one URL of your token validator application say 'Token Handler'.
So in this 'Token Handler' application you can set your session time. This will be time for which your token will be valid. So if you don't get any hit from that particular user for say 15 minutes then you will mark it as invalid token for next request.
Please let me know we can have discussion if you need any additional help on it.
I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).
I am creating my first webapi project using ExtJS for the client-side and trying to understand login procedures. I'm trying to understand what SESSION is used for and if I use REST, SESSION should not be part of it.
REST by design is stateless. By adding session (or anything else of that kind) you are making it stateful and defeating any purpose of having a RESTful API.
The whole idea of RESTful service is that every resource is uniquely addressable using a universal syntax for use in hypermedia links and each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP".
I'm a bit confused on session... normally, when a user logs in the sessionID is recorded somewhere on server? Then when user makes another request, url sends this sessionID back to server and if the ID is valid proceed with request.
Do I have this right?
On the other hand with rest the request message basically sends the username/password everytime a request is sent.
Do I have this right? Using REST on my webapi, can I skip the whole concept of SESSION and just keep sending username/password... or is there a better way?
can I skip the whole concept of SESSION and just keep sending
username/password... or is there a better way?
Yes, Web API has Token based Authorization - Bearer token. By using it, you can totally avoid using Session State.
Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2
In a nut shell, when a user is successfully authenticated, server issues a token instead of session state. Then every request, the user sends the same token along with the payload.
I am creating a solution that will contains a website and mobile apps. I will use Zend-Framework 2 for the website.
So, to make it good, I am wondering if it would be a good idea to build :
A REST web service (using zf2)
Another website that will call the REST ws (using zf2)
The mobile apps that will call the REST ws
I will use OAuth for the autentication and security.
My question is, if my website gets the data by calling the REST ws, it will have to make a database request at each call to check the token whereas if I do a "normal" website, my app will be able to use session to store the information of the connected user.
Because, for what I have read, there is no such thing as session with OAuth/REST so for each call, I have one more sql request to check the token validity.
Is it still a good idea to make a full REST service, even for the website or to have a "normal" website and also a REST service API just for the mobile apps ?
Thanks
Oauth is a server to server authentication framework. Like it is between mobile app and your API server , website vs your API server etc. You can adopt an approach where , you generate only one access token for your website client instead of multiple access token for each user from the website. This access token is stored in your webserver vs user cookie in website.Ultimately the aim is to identify all the clients of your REST WS and your website is one of its client and a very trusted one.
This way you can cache the access token to avoid db calls (typically cache time can be equal to or less than token expiry time). Do explore the multiple grant types specified in the oauth spec for this
Regarding maintaining session for user in your website, it is not dependent on whether the back end is a REST WS or not, it can be handled in your website