<p>Just wanted to introduce our new Go package for handling authentication for web applications. It'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's in a beta state, hence the .v0 in the import path we're suggesting. Looking for users, feedback, pull requests and everything to help us get to a solid version 1!</p>
<p>edit: formatting & 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'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("/admin", 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'll do our best to support you. We'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 "I wish I had devise."</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've looked at and don't understand the advantages or why it can'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's any friction in this approach let me know, I'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's my understanding.</p>
<p>As far as replay goes, for certain tokens (e.g. password reset) the JWT ID claim "jti" can be "spent" 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're passing these over TLS than the attack surface is somewhat limited. I wouldn't say it's bulletproof, but it'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't been tampered with.</p>
<p>Here'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>
