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.
Related
I am trying to understand statelessness in restful APIs in the context of authentication. Here's the scenario:
The user logs in.
The server verifies the username and the password, and generates an opaque access token. It caches some information related to this token - for example, the expiration time, the userId, whether this token was explicitly invalidated before it expired, etc.
The token is sent to the client, and the client sends it with every future request.
List item
Fielding's dissertation defines statelessness as:
"...such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client."
In my example, the client is sending the token with every request, so the first condition is satisfied. However, my server has a context associated with this session that is stored in the sessions cache.
Does this make my application stateful?
If yes, then is it that true statelessness be achieved only if we are using JWTs? I am pondering upon this as JWTs are quite new, so how were architects building truly stateless services before they were invented?
That's right. If you you maintaining the session you are keeping the state in server which makes the application hard to scale. True stateless applications can be scaled out and any server should be able to handle the request.
JWT is popular way to avoid sessions and everything is encapsulated inside the token for any server to auth/Authorize the request and help us achieve stateless application, they come with their own challenges however OpenID connect is the new way for Auth/Authorization.
Before jwt to make application stateless we used to keep session in DB (or Shared Cache) , and any server would like to check the session would have to contact DB.
Hope that Helps!
Briefly: No, such usage of token does not make your application stateful.
Detailed: When we talk about stateless/stateful, we consider usually only the data that affect business logic. Business logic does not usually depend on authentication data. For example, a user sends a request that contains all data needed to place some order. Normally creating an order does not depend on when this user has logged in, on his user ID, etc.
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.
Does using tokens for authentication break REST principles, which is supposed to be stateless.
I have an application which is required to be REST and I stored some tokens in a database. Each time a user wants to do an action, they should get a token (by sending a username and a password) and send it to the server with every request.
No they, don't.
A key aspect of something like the authentication header is the fact that it's orthogonal to the request itself. It's a property of the request in the same way that a Content-Type header is.
How Authentication is implemented on the back end is not germane to the discussion as long as results of the requests that submit the header are consistent. There's no reason the process of validating an authentication header can't be a stateless process in and of itself.
The presence and content of the Authentication can certainly impact what a client receives from a request, from a 403 Unauthorized response, to a limited amount of content based on whether the client is, perhaps, using an "admin" token vs. a non-privileged user.
It's also in contrast to a Cookie, which represent Session state (which is not RESTful). This is because the two headers serve different purposes and offer up different application semantics.
Authentication Tokens are a standard way of authenticating REST Clients.
Authentication token themselves do not beak REST principles as long as your API doesn't behave differently based on the Auth token passed to the API.
i.e. if 2 consumers place the same request with different auth token, and they are both allowed to perform that operation, the result should be the same.
You can find more info on REST API authentication here: https://dzone.com/articles/api-security-ways-to-authenticate-and-authorize
No it does not break the rule of being stateless.
Why?
Because the server is not maintaining any session w.r.t the client. It is just validating the token provided by client and returning results based on that.
If its client that has to maintain any data related to the session (which happens in case of tokens since they are sent with every request) then it is not breaking the REST principle, it is still stateless since the server is not maintaining the session or data related to the session.
Hope that helped.
It does break Rest principles because once the service generates a temporary token based on login credentials, the service is no longer stateless. The service has to check with itself if the token has expired yet (the token is part of the system state now), for each call made using that token.
One can't say the session at any point is independent of all the client's previous actions, because if they did not log in correctly, they could not even use the system.
But you should use logins and tokens, and break the Restfulness in this small way for security.
I am building a RESTful web service using ASP.NET web API. I've read that it isn't very RESTful to use session authentication since a "login" request is required before any other request can be successfully made. In addition, it requires the client to maintain state.
My original design was to have the client call a "login" request using basic HTTP authentication over SSL. The web service would then verify the credentials and respond with a session key. The client then uses that session key to sign all subsequent requests. When the web service receives any of these requests it looks up the session key, signs the request in the same way, and checks if the two signatures are equal.
Is it possible to avoid this session authentication without having to send the username/password with each request? The credential verification does not happen within the web service (it is routed to another server that maintains users). I'm concerned that performance will be affected if I need to validate each request.
It's not possible. You either store the state or get the credentials with each request. The second option is what you would want with your HTTP API.
Depends what you mean with "validate"
you could e.g. cache the hash(username+password) in your application. And on subsequest requests check if the cached entry still exists. This way you can save roundtrips to your backend store.
We have a REST application that is utilized mostly by applications that dont need to maintain their state, so till date we have been quiet "RESTFUL" without maintaining a state. We use the Private/Public (similar to Amazon) for authentication.Currently the client passes the credentials for every request
Now we have a new requirement where we have to maintain the state (or conversation).The client can be a Rich application or a hand held device .I am trying to comeup with the best way to implement the state .Should we pass on a session Id and maintain that ID ..is that the best and the only solution ?
Passing on a session ID is not the only way and not the best way to maintain conversational state. The best way, if you have a RIA is to maintain the state on the client itself, where it belongs, as some of the comments suggest. This means still sending the credentials every request.
Re-authentication on every request is the only way, and if you feel that there's a performance hit on the server, the server can (as suggested) cache the result of an authentication request for a period of time. Digest authentication could help avoid caching responses by cryptograpically signing the tokens going over the wire.
If that's not good enough you could use something akin to Google ClientLogin, and giving the client an encrypted token that can be verified without needing to ask an authorization, and without passing the user's real credentials over the wire. Google themselves this by doing the login over https, and then using the generated tokens over http. It's open for replay attacks for the lifetime of the token.