TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

My take on RESTful authentication

45 点作者 facundo_olano超过 11 年前

10 条评论

SanderMak超过 11 年前
One thing I discovered last week is OpenID Connect [1]. It layers an authentication standard upon oAuth2, without any of the cruft of &#x27;legacy&#x27; OpenID it seems. Does anybody here have practical experience with OpenID connect?<p>[1] <a href="http://openid.net/connect/" rel="nofollow">http:&#x2F;&#x2F;openid.net&#x2F;connect&#x2F;</a>
e12e超过 11 年前
Nice summary (even if I have some trouble accepting stateful auth as being RESTful...:)<p>One thing (perhaps rightfully) missing is auth in the tls&#x2F;ssl layer. Client certs do work, pre-shared keys sadly do not really work. And I don&#x27;t know what happened with tls-srp:<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=405155" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=405155</a>
czbond超过 11 年前
I&#x27;m glad to see someone addressing this. I&#x27;ve been thinking about howto do this with devise in a more proper manner.
nly超过 11 年前
Meteor.js is both impressive and terrifying. (I&#x27;ve only watched the screencast but, seemingly raw, database access from the user side is... eyebrow raising).<p>I&#x27;m not confident implementing SRP in Javascript provides any real advantage. From a trust standpoint, if you&#x27;re going to use authentication code pushed to you, you&#x27;re already all-in. The reason I advocate SRP on the web (via a browser implementation) is because 1) people reuse passwords and 2) I think it&#x27;s become clear we can&#x27;t trust web services, even big names, to handle passwords securely. We also can&#x27;t trust corporations, public access machines and schools etc. not to strip SSL wholesale. We also shouldn&#x27;t give bad actors the opportunity to put subtle backdoors in to authentication code of compromised servers.
sekm超过 11 年前
So basically OAuth2 Resource Password Owner is a formalization of Sessions...
feralmoan超过 11 年前
I don&#x27;t understand the problem mentioned with HTTP Basic, username&#x2F;password injection into the uri <a href="https://username:password@such-n-such.net" rel="nofollow">https:&#x2F;&#x2F;username:password@such-n-such.net</a> works just fine if for some reason you can&#x27;t set the header explicitly. <a href="http://tools.ietf.org/html/rfc3986#section-3.2" rel="nofollow">http:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc3986#section-3.2</a>
评论 #6959589 未加载
dirkk0超过 11 年前
Nice writeup indeed.<p>As far as I understood, the [MEAN.io](<a href="http://mean.io" rel="nofollow">http:&#x2F;&#x2F;mean.io</a>) stack implements OAuth2 like this - at the &#x27;cost&#x27; of having two MVCs: one on the server side to deal with the authentifiction, 404 and 500, and the AngularJS one on the client side.<p>I hoped that there was an easier way to deal with the whole scenario, but obviously that is a good one.
abengoam超过 11 年前
I am actually writing a REST authentication service right now. The idea is to do it well once, and then reuse it in my other projects. It uses HTTP basic auth; as it is going to be called from the backend of my other projects it will not have the issues described in the article regarding the browser dialog.
ak39超过 11 年前
What are the main reasons why a home brewed authentication solution is considered a bad idea?
评论 #6959978 未加载
评论 #6959024 未加载
basicallydan超过 11 年前
Nice, simple writeup and exploration of options :)