<p>What is the best way to setup a Golang backend to handle authentication for both web and mobile? I would like to use <a href="https://github.com/markbates/goth">https://github.com/markbates/goth</a> or some similar Oauth package, but it's not clear to me how to persist sessions for mobile users. From what I've read, it sounds like cookies don't work well with mobile so JWT is needed for mobile users to stay logged in. Is there an example of using Goth with JWT?</p>
<hr/>**评论：**<br/><br/>Tikiatua: <pre><p>JWT is certainly the way to go and we are using it extensively in web and mobile apps.</p>
<p>The gothic subpackage github.com/markbates/goth/gothic does the actual request to the Oauth provider and stores the information in a cookie using the github.com/gorilla/sessions package.</p>
<p>You could implement the functionality as provided by the gothic package and instead just use json web tokens to store the session information. Basically you just need to slightly modify the functions GetAuthUrl and CompleteUserAuth. </p>
<p>Personally I use github.com/dgrijalva/jwt-go to handle jwts.</p></pre>everdev: <pre><p>Thanks, any good tutorials or examples out there for JWT auth? Most examples I find come with a warning like: "Don't Do This.. Example Only..."</p></pre>metamatic: <pre><p>You could <a href="https://github.com/lpar/jwtauth" rel="nofollow">look at my code</a>. I haven't written up a tutorial yet, though.</p>
<p>Edit: <a href="http://dghubble.com/blog/posts/json-web-tokens-and-go/" rel="nofollow">This article</a> looks pretty good to me.</p></pre>syzo_: <pre><p>+1 for github.com/dgrijalva/jwt-go.</p>
<p>I was making myself a skeleton API server that i'd use for other projects later. Not 100% done yet (wish I had more time..) but it seemed easy enough to use from the part I did implement.</p></pre>surfhiker: <pre><p>The main downside of a JWT is that it cannot easily be revoked. If the users have te able to control (view or revoke) active sessions, it's much easier to use an accees token persisted in the database, which is verified per request. Then it's simply a matter of marking the token in db as revoked.</p></pre>daveddev: <pre><p>Just check the expiration when requested. It should be fairly easy.</p></pre>surfhiker: <pre><p>I don't see how this helps with revocation of the JWT tokens?</p></pre>metamatic: <pre><p>Sure, technically you can't revoke a token. However, you can make every token expire after a given time period, so you can basically revoke access after however long that time period is.</p></pre>surfhiker: <pre><p>You're right, and that's most probably what <a href="/u/daveddev" rel="nofollow">/u/daveddev</a> was referring to. However, if you want your user to be able to manage active sessions, like you can on Facebook or Gmail or Telegram, it's harder to do this with JWTs as those tokens cannot be revoked. Sure, you could keep a list of revoked tokens in the database, and then cross-reference that table on each request, but that would defeat the purpose of JWT (as it's signed so you don't have to do an extra call to the db).</p></pre>daveddev: <pre><p>I have little experience with JWT, so I apologize; I was/am confusing issues and shouldn't have chimed in on this.</p></pre>surfhiker: <pre><p>No need to apologize, just wanted to make sure we're on the same page! Here is a good read about <a href="https://www.dinochiesa.net/?p=1388" rel="nofollow">revoking JWTs</a>.</p></pre>metamatic: <pre><p>Well, if you want real security and defense against replay attacks you need to give your JWTs a <code>jti</code> value to prevent re-use, which means you have to have some server state, but you <em>can</em> revoke tokens. And at that point at least your server-side state is just a bunch of UUIDs rather than something more complicated.</p></pre>tscs37: <pre><p>A simple solution to revoke JWTs would be to maintain a small hashtable of revoked JWTs based on their hash and their expiry time.</p>
<p>The server can then regularly (cronjob) do a garbage collection of expired tokens from that list and is able to easily revoke tokens and lookup revoked JWTs.</p>
<p>If those hashtables are maintained per user, most perf loss can be hidden behing a for-loop over the key range, if no keys are present, it has almost zero impact for users not having revoked keys.</p></pre>metamatic: <pre><p>Cookies should work fine with mobile <em>web</em>, they just don't necessarily work well for mobile apps.</p></pre>everdev: <pre><p>I experience what's reported here: <a href="https://www.spotxchange.com/resources/blog/product-pulse/productpulse-why-we-must-move-past-cookies-on-mobile/" rel="nofollow">https://www.spotxchange.com/resources/blog/product-pulse/productpulse-why-we-must-move-past-cookies-on-mobile/</a></p>
<p>"Persistent cookies on the other hand remain in a user’s browser until the cookie expires or the user deletes the cookie. Mobile cookies, however, fail to persist and are deleted whenever a user shuts down the operation of their mobile browser or restarts, shuts down or switches their mobile device."</p>
<p>Every time I open the browser app I have to login with Oauth again. Is there a way to circumvent that and persist the session until it's expiration date or logout?</p></pre>metamatic: <pre><p>My mobile browser's persistent cookies persist. For example, when I go to Fuelly I remain logged in, even if it's several weeks since I last fueled up.</p>
<p>That article is talking about third party tracking cookies for advertising. Those probably do fail, but that's not relevant to web app development.</p>
<p>My guess would be that your OAuth service requires logging in again because that's how the OAuth service wants it. If that's how it's set up, using local storage instead of cookies won't necessarily help you -- it can just as easily make the issued OAuth token expire.</p></pre>
