tag:blogger.com,1999:blog-6432484966567158349.post4993838097704473129..comments2023-10-23T17:45:24.408-07:00Comments on Learn REST: A Tutorial: 14.3. How do I handle authentication in REST?Dr. M. Elksteinhttp://www.blogger.com/profile/01086047572579338522noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-6432484966567158349.post-82925935836469397682014-11-20T20:09:20.640-08:002014-11-20T20:09:20.640-08:00Thanks, nice tutorialThanks, nice tutorialBinh Nguyenhttps://www.blogger.com/profile/02069417158952884749noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-66077565038670734372014-06-16T10:41:03.984-07:002014-06-16T10:41:03.984-07:00The reason cookies are not recommended is precisel...The reason cookies are not recommended is precisely because the browser sends cookies automatically with each request. So this allows some kinds of attacks (CSRF) where someone takes advantage of this fact to access secure information or perform actions on behalf of the user.<br /><br />Unfortunately, the same applies to the Authorization header, if the login method is supported by the browser, Dobeshttps://www.blogger.com/profile/09392777569321223496noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-5274351729136582332014-01-08T04:32:08.971-08:002014-01-08T04:32:08.971-08:00Please guide me the details step to configure soap...Please guide me the details step to configure soapui with ALM 11.<br />For example how to do a Post/Get request for defect entity, i am getting authentication error as "HTTP Status 401 - An Authentication object was not found in the SecurityContext" even though i am passing all the authentication parameters with the soap request.<br /><br /><br />Anonymoushttps://www.blogger.com/profile/11894290096195991483noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-77123529150491764972013-05-06T11:01:53.381-07:002013-05-06T11:01:53.381-07:00Hi Gilly,
the server is still stateless. Once crea...Hi Gilly,<br />the server is still stateless. Once created, the token encodes its own state (ip address, expiry date, etc). The server is only validating the token when a request is sent.<br /><br />As discussed earlier, you're right, there is no functional difference between tokens and cookies. Only as Elkstein points out, cookies are effectively browser only and so don't lend themselvesUnknownhttps://www.blogger.com/profile/01242302211329388613noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-74505907267193230072013-01-29T17:28:12.641-08:002013-01-29T17:28:12.641-08:00If the server is managing token expiration, then t...If the server is managing token expiration, then the server is no longer stateless. It is unrealistic to re-authenticate a user with each request, so this aspect of maintaining state must be the exception for a RESTful service that requires authentication.<br /><br />It is inaccurate to imply that storing data in a cookie means that the data is not sent with each request. With HTTP, the entire gilly3https://www.blogger.com/profile/07796900417240447744noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-10948940918446309492012-12-28T04:39:40.106-08:002012-12-28T04:39:40.106-08:00Hi DR. M. ELKSTEIN,
We are developing a REST api ...Hi DR. M. ELKSTEIN, <br />We are developing a REST api and we have doubts about send a GET like this<br />https://server/api/login.json?email=test@test.com&password=test<br /><br />This is clearly wrong, I know... but unless do it like a POST over SSL and encrypt the password (maybe this is the way we must do it), we don't know any other way to make the login.<br /><br />We are a litte Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-91923504140117726952012-11-19T01:17:36.208-08:002012-11-19T01:17:36.208-08:00Hi Julien, Gunawan,
This really depends on your a...Hi Julien, Gunawan,<br /><br />This really depends on your application: if it's browser-based, then cookies are indeed easier and make more sense. But if you have HLL code generating the requests, adding tokens to the URL makes it easier to generate the request and to log things; there's nothing "automatic" about cookies if you generate the HTTP request in code, rather than Dr. M. Elksteinhttps://www.blogger.com/profile/01086047572579338522noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-69002620922919196072012-11-18T06:55:28.483-08:002012-11-18T06:55:28.483-08:00Hi,
I agree with Paul DeMarco and Julien Montenoi...Hi,<br /><br />I agree with Paul DeMarco and Julien Montenoise. While cookies can be manipulated, parameters in URL is even more so.<br /><br />I always thought the "Stateless" rule means on the server side (no sessions), not on the client side (no cookies). Because no matter how the client side keeps the token, whether in a cookie or variable, it's still some kind of (client-side) Anonymoushttps://www.blogger.com/profile/14205948829388687892noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-90593751345452156302012-10-19T07:19:13.278-07:002012-10-19T07:19:13.278-07:00Hello,
As Paul DeMarco said, it's equivalent...Hello, <br /><br />As Paul DeMarco said, it's equivalent to store the token in a cookie or to send it in the URL. In both cases, your client application have to keep the token somewhere...<br />The drawback to add it in the url is that you must force to add it for every queries whereas it's automatic with the cookie!<br />Moreover, the url is "polluted" by the token that is Anonymoushttps://www.blogger.com/profile/07214450171716275903noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-89579896192519044782012-10-04T04:29:59.814-07:002012-10-04T04:29:59.814-07:00Hi Paul,
The main difference is that the cookie i...Hi Paul,<br /><br />The main difference is that the cookie is not passed in the URL, as opposed to the token I've mentioned. Other than that, you're obviously right, and the mechanism can be implemented using cookies; but cookies tend to be abused, with too much state stored there. The solution I'm suggesting explicitly limits the state to log-in status.Dr. M. Elksteinhttps://www.blogger.com/profile/01086047572579338522noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-22427249206272511492012-09-08T18:20:07.546-07:002012-09-08T18:20:07.546-07:00Isn't your second approach just the same as a ...Isn't your second approach just the same as a cookie approach?<br /> "here client, keep this data for later"<br />Either as a variable in the code or cookie on disk...<br /><br />I have to ask, why not cookies?Anonymoushttps://www.blogger.com/profile/14646942320787835828noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-16849429239469659072011-10-17T12:01:30.504-07:002011-10-17T12:01:30.504-07:00Passing an authkey in the url is basically the sam...Passing an authkey in the url is basically the same as using normal sessions, since the server has to verify the authkey serverside.Håvard Pedersenhttps://www.blogger.com/profile/12127077720576900654noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-91094344338855667822011-09-23T13:41:24.806-07:002011-09-23T13:41:24.806-07:00Hello TechnicalPhilosopher,
There is no added sec...Hello TechnicalPhilosopher,<br /><br />There is no added security in using POST over GET, unless your main worry is people peeking over the user's shoulder. As for using tokens, the token can be bound, for example, to a specific IP, and created with an expiration time. This makes tokens more secure, in fact, than simple resends of the username and password (even if hashed, as in the case of Dr. M. Elksteinhttps://www.blogger.com/profile/01086047572579338522noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-74335361513937213112011-08-29T07:36:35.924-07:002011-08-29T07:36:35.924-07:00Dr Elkstein
If we are indeed using GET, wouldn'...Dr Elkstein<br />If we are indeed using GET, wouldn't having a server token to the user be a security hazard of sorts (I am assuming here that it has to be included in all the url requests after), should we use POST when we are using the token architecture?<br />Also wouldn't a static token be a security hazard of sorts in itself, especially if we are using GET?<br />Sorry if I sound likeTechnicalPhilosopherhttps://www.blogger.com/profile/15733718382081911983noreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-57503490483160801852011-08-09T21:06:02.645-07:002011-08-09T21:06:02.645-07:00@SRIRAM You should always use SSL/TLS to encrypt t...@SRIRAM You should always use SSL/TLS to encrypt the connection as it will all be easily intercepted otherwise.<br /><br />Also, I would use a public/private key on the application level and encrypt all POST data on the client using the server public key before sending it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6432484966567158349.post-36302881553142996932011-07-01T06:12:19.892-07:002011-07-01T06:12:19.892-07:00Hi I understood the concept. If I want to pass any...Hi I understood the concept. If I want to pass any sensitive data (ex: credit card information) through browser, how to authenticate that URI? can you provide me small example to understood easily.SRIRAMhttps://www.blogger.com/profile/00535305402749512638noreply@blogger.com