Creating a sign-in for a SPA is fairly straightforward. Without using a crazy advanced encryption method one could make the app so you can: enter your name and password, save that to a database and get access to your account with your pictures, friends etc. But in order to safely pass data back to the database you might want some way to further authenticate that you are who you say you are and your data that you are passing is yours. There are some differences of opinion* online of best practices regarding authentication, but a common solution now is to create a JWT, a JSON Web Token. This is an alternative to, and possibly becoming more popular than, “sessions”. The token is basically just a string that is unique to a user. JWT is a gem by the way. The JSON web token object communicates with the client, browser, server and is stored client side. Another way to do this kind of auth is through OAuth 2.0 (which is a third party protocol) used to authenticate a user. OAuth 2.0, which now seems to be becoming the standard, is when you create an account in an application and they ask if you want to sign in using your google account, this is OAuth 2.0). I’m not really going to get into OAuth 2.0 now, but I thought it was cool.
The stretch goal for the project I’m involved with currently is to create a simple currency within our application that exists only on the application where users can get access to things in the application through spending currency. Users will be able to generate currency through making detailed guides to activities they have some kind of expertise in. Then they can spend their currency to get access to someone else’s detailed guide of their choice. We called this in-app currency tokens. This kind of exchange model, if we end up making it even, and if were trying to make it a somewhat more secure exchange, could be trickier than just creating Token, UserToken and User models and connecting them in the backend. There should be some kind of authorization to verify ownership of the tokens. My research lead me to authentication(which we are not doing yet) through JWT tokens which are Token Based Authorization. We are not going to use JWT tokens in this project, maybe in future versions we could, but not now.
A step-by-step description of the JWT authentication process, in english:
- A user passes in credentials (such as username and password) in the form of a client request to the API (backend). I heard we could use a hooks API for this.
- Then the API will authenticate the user request (“we could use a library for this such as devise”).
- Then the API will create a JWT which will include some data about the user (such as the user Id) and return that JWT in the response.
- The client can then use that JWT in the authentication header for all their subsequent requests. In each of these subsequent requests, The API can get the JWT, decode it and authenticate the user.
Why would I go through the trouble of setting up JWT when I can just authenticate a user with something like password_digest and has_secure_password? The reason is that even if my app thinks they know when a user is who they say they are, I don’t know if I can verify the authenticity of one of their tokens. Even if I can verify the authenticity of their identity by verifying their password, I still might not know. Therefore I need to authenticate their tokens. I could do that by passing a JSON web token in along with their other token to make a working transaction. Two different kinds of tokens together for access to one of the guide posts in the app.
To be clear, this is a stretch goal for my project its not something that I have implemented yet and will not be implementing this week. However, researching, as it is with all things googling about code in my opinion, has been equal parts fascinating and daunting. I’m looking forward to exploring the possibilities of using JWT for authentication.