Authentication model - acodeguy/acebook-rails-gang-of-four GitHub Wiki

Authentication works in the app by using two main gems - Devise and Devise Token Auth.

There were two main elements to the authentication in our app.

First was the frontend preventing the user accessing pages they were not authorised to. It does this by, when a user goes to a protected page, the frontend app will check if a user object (with their access token) exists in the session. If not, it will redirect them to the login page. If they have not registered, they can select to go to the registration page.

When the user enters their registration details and submits, the frontend app posts these to the Rails api. Devise Token Auth would create the user / log the user in (this was handled without us needing to write any backend code), and then return various authentication details (a special string of characters known as a 'token', a user ID (always the same as the user email), and a client ID (to uniquely identify the client)).

The frontend stores these details in the session and redirects them to the timeline page - logging them in. As the user details are now stored in the session, it will display that page and any other protected pages the user goes to.

Second was the backend preventing the user from calling endpoints they were not authorised for. When the frontend calls the rails api to save a post or retrieve a list of posts, it MUST pass the access token, UID, and the client ID (stored in the session) in the header. If so, the api recognises the user and allows them to complete the action. Additionally, there will be logic to check that, for example, a user is updating a post they created.

Here is a diagram of how the frontend is calling the api to login, register, and access other endpoints: https://photos.app.goo.gl/hWg6vSVuxju5qvw58