Go Web Authentication Framework

blov · · 2441 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>Just wanted to introduce our new Go package for handling authentication for web applications. It&#39;s reminiscent of Devise from rails or Passport from node.js</p> <p>Repo: <a href="https://github.com/go-authboss/authboss">https://github.com/go-authboss/authboss</a></p> <p>Import: <a href="https://gopkg.in/authboss.v0">https://gopkg.in/authboss.v0</a></p> <p>Sample Repo: <a href="https://github.com/go-authboss/authboss-sample">https://github.com/go-authboss/authboss-sample</a></p> <p>It&#39;s in a beta state, hence the .v0 in the import path we&#39;re suggesting. Looking for users, feedback, pull requests and everything to help us get to a solid version 1!</p> <p>edit: formatting &amp; sample repo inclusion</p> <hr/>**评论:**<br/><br/>IQue: <pre><p>I have been looking around for a solid auth package for a few days now and this is exactly what I was looking for, will be digging into this for real in the coming week.</p> <p>I&#39;d love to see some sample code of using the authentication middleware with something like Negroni.</p> <p>For instance taken from the Negroni documentation you can have middleware declared for specific routes like this:</p> <pre><code>// Create a new negroni for the admin middleware router.Handle(&#34;/admin&#34;, negroni.New( Middleware1, Middleware2, negroni.Wrap(adminRoutes), )) </code></pre> <p>Where Middleware1 or Middleware2 could theoretically be some authboss function to authenticate before proceeding to a route?</p></pre>aarondl: <pre><p>We&#39;ll do our best to support you. We&#39;re really trying to make it easy to do web based authentication in Go. It feels like a stumbling block every time I want to start a Go web app and I feel like &#34;I wish I had devise.&#34;</p> <p>In terms of sample code for a middleware that would defend your routes from unauthenticated users. Simply roll your own negroni middleware and use authboss.CurrentUser to determine if a user exists for the request. If he does exist, call the next handler, if not, handle that situation.</p> <p>It might look like this: <a href="https://gist.github.com/aarondl/6a10db3e1966194bbaf1" rel="nofollow">https://gist.github.com/aarondl/6a10db3e1966194bbaf1</a></p></pre>bmo111: <pre><p>Nice. I was just thinking about this. Will check out more.</p></pre>ChugalugHouse: <pre><p>I know it hews closely to devise, but what do you think about supporting JSON Web Token based auth? There are some distinct advantages over cookie sessions.</p></pre>aarondl: <pre><p>There is an issue about this. <a href="https://github.com/go-authboss/authboss/issues/53" rel="nofollow">https://github.com/go-authboss/authboss/issues/53</a></p> <p>The hold up is my understanding of JWT to be honest. I&#39;ve looked at and don&#39;t understand the advantages or why it can&#39;t easily be used in replay attacks since it includes all of your claims or authentication or what have you.</p> <p>However, Since we make no assumptions how or where you store your cookies (session OR remember me cookies; see the ClientStorer interface) you could implement this as a JWT I do believe without any help at all from Authboss (maybe with help from this: <a href="https://github.com/dgrijalva/jwt-go" rel="nofollow">https://github.com/dgrijalva/jwt-go</a>)</p> <p>If there&#39;s any friction in this approach let me know, I&#39;d like to find out if we can get rid of this issue, or exactly what Authboss needs to do to support it.</p></pre>ChugalugHouse: <pre><p>This library is nicer to use in my opinion: <a href="https://github.com/zhevron/jwt" rel="nofollow">https://github.com/zhevron/jwt</a></p> <p>I am not an expert, but here&#39;s my understanding.</p> <p>As far as replay goes, for certain tokens (e.g. password reset) the JWT ID claim &#34;jti&#34; can be &#34;spent&#34; to enforce one time use, though of course this requires data storage.</p> <p>For general tokens replay is possible but only for the duration of the token. If you implement reasonable expirations and have a flow to easily refresh tokens it mitigates it somewhat. Also assuming you&#39;re passing these over TLS than the attack surface is somewhat limited. I wouldn&#39;t say it&#39;s bulletproof, but it&#39;s comparable to session ID security with the added benefit of not needing a backing data store. All one needs to store is the signing key to verify tokens haven&#39;t been tampered with.</p> <p>Here&#39;s are some good writeups on JSOn Web Tokens: - <a href="https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/" rel="nofollow">https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/</a> - <a href="https://auth0.com/blog/2015/03/10/blacklist-json-web-token-api-keys/" rel="nofollow">https://auth0.com/blog/2015/03/10/blacklist-json-web-token-api-keys/</a></p></pre>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

2441 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传