How do I authenticate a user on a mobile app using a Go REST API?

<p>I&#39;ve created a web backend in Golang, with a database and REST API, but I would like users to actually login to their accounts from a hybrid mobile app (using javascript). All the data and information is communicated to the app via the json API. What should I do to authenticate my users? Also, is this the best architecture for doing this? What would you do if you had created a Go backend but all the data is accessed on a remote mobile app?</p> <p>Thanks in advance.</p> <hr/>**评论：**<br/><br/>nerdwaller: <pre><p>I&#39;ve recently been using <a href="https://github.com/dgrijalva/jwt-go" rel="nofollow">JWT</a> (json web tokens). Essentially on login the user gets a signed token (you can validate the payload hasn&#39;t been altered) that has whatever info you want stored in it (I usually just have &#34;sub&#34; which is the subject/user ID). All subsequent requests validate the token which is provided as a header: &#34;Authorization: Bearer &lt;token content&gt;&#34;.</p> <p>These tokens require no server storage and have expirations built in. Though I still cache them in redis in case I need to force an early expiration for whatever reason.</p> <p>Edit 1:</p> <p>I should note that there is a spec for JWE, which is essentially the same thing but encrypted content. With JWT the data is just base64 encoded, so everything is visible but is signed to check validity. I&#39;ve not seen any libs really for JWE for go, but you can probably implement it. I&#39;ve been considering doing one but haven&#39;t had the time.</p></pre>AnimalMachine: <pre><p>Seconded. If you need some help with this, I can dig up some code I have.</p></pre>mcouturier: <pre><p>I also use JWT it&#39;s fantastic. Regarding expiration, I use 2 hours for access tokens and infinity for refresh tokens. So to revoke access I invalidate the refresh token and the user won&#39;t have access after 2 hours. It&#39;s a compromise between storing something and nothing...</p></pre>nerdwaller: <pre><p>Not a bad approach. Our requirements are a bit more strict so I store a &#34;jti&#34; header (a unique token ID, jti is used because it&#39;s reserved for this usage per the spec). I invalidate those and publish an event in the system (websocket) to ensure anyone that cached the acceptable tokens they have seen stop accepting them (this is in a distributed app).</p></pre>mvpmvh: <pre><p>This is the correct answer</p></pre>thermokarst: <pre><p>Shameless plug: I wrote a little middleware for working with JWT in Go webapps --- <a href="https://github.com/thermokarst/jwt" rel="nofollow">https://github.com/thermokarst/jwt</a>. It is fairly flexible, and pretty straightforward to use.</p></pre>nerdwaller: <pre><p>Thanks for sharing! I&#39;ll try to break mine out of some business rules and post a gist as well, I like to see various approaches. </p></pre>kelbyludwig: <pre><p>Personally, I am a fan of session tokens (i.e. Exchange a username and password for a long, secure-random token which is passed in subsequent request). They are not RESTful, but they are simple.</p></pre>playa_1: <pre><p>This can be done with JWT using an expiration date. On each request you verify it is a valid token and hasn&#39;t expired. All of the state is in the request so it is RESTful.</p></pre>mvpmvh: <pre><p>Guy asks for a solution for his restful architecture, top answer is non-restful approach lol.</p></pre>boydatw: <pre><p>Seconded. I wish someone could explain to me what I can achieve with JWT that I cannot achieve with a session token. I had similar conversations about OAuth2 a couple of years ago.</p></pre>--Mister--j: <pre><p>I&#39;ve used <a href="https://github.com/dgrijalva/jwt-go" rel="nofollow">https://github.com/dgrijalva/jwt-go</a> for JWT based authentication.</p></pre>shuwatto: <pre><p>Seconded.</p> <p>I make a middleware for Echo with this library.</p> <p>It is well documented and easy to use.</p></pre>anoland: <pre><p>JWT is a good choice. </p> <p>Security is still hard to do. Here is an article that breaks it down really well. <a href="http://web.archive.org/web/20150917192938/http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication" rel="nofollow">http://web.archive.org/web/20150917192938/http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication</a> Sadly, The original site seems to be gone.</p> <p>The toughest nut to crack, after you have chosen which method to verify your end users credentials, is how to store their individual identifier.</p></pre>