Slide 1

Slide 1 text

Implementing Authentication in Your React / React-Native Apps Prosper Otemuyiwa | Lagos React Dev Summit 2017

Slide 2

Slide 2 text

Who Am I? ❖ Software Developer ❖ Consultant at Auth0 ❖ Open Sourcerer ❖ Self-Acclaimed Developer Evangelist ❖ Community Builder ❖ Jollof Rice Ambassador ❖ Google Developer Expert @unicodeveloper

Slide 3

Slide 3 text

❖ One does not simply implement Authentication. ❖ Again, one does not simply implement Authentication. ❖ Once Again, one does not simply implement Authentication.

Slide 4

Slide 4 text

Traditional Authentication - How it Works Challenge 2 ❖ A user submits some credentials ❖ The credentials are checked against a database ❖ If the credentials are valid, a session is created for the user on the server. The session can be stored in files, a database, a cache store like Redis, et.c. ❖ A cookie with a session_id is sent back to the browser. ❖ Subsequent HTTP requests to the server carries the cookie. So, it’s verified against the session every time.

Slide 5

Slide 5 text

Traditional Authentication - How it Works Challenge 2 ❖ Once the cookie is deleted, the application logs me out.

Slide 6

Slide 6 text

Modern Architecture - How? What? ❖ John Doe, decouple all the things! ❖ Microservices everywhere. ❖ Backend exists as a REST API and they are stateless. ❖ Frontend exists as a Single Page Application (SPA) ❖ Mobile app needs to consume the REST API. ❖ Easy Scalability is needed. Using React === Building SPAs

Slide 7

Slide 7 text

❖ How do we simply authenticate users in the modern architecture realm?

Slide 8

Slide 8 text

Challenge 2 JSON WEB TOKEN Authentication to the rescue!

Slide 9

Slide 9 text

JWT Authentication - How it Works Challenge 2 ❖ A user submits some credentials ❖ The credentials are checked against a database ❖ If the credentials are valid, a token is created, signed for the user and returned to the client in the response. ❖ The token is saved on the client. ❖ Subsequent HTTP requests to the server carries the token as an Authorization header. ❖ The backend receives the token and verifies it against a secret on the server. ❖ If the token is valid, the requested resource is returned else a 401 status code is returned.

Slide 10

Slide 10 text

Challenge 2 Exploring a JWT

Slide 11

Slide 11 text

Challenge 2 Implementation ❖ Login Component

Slide 12

Slide 12 text

Implementation - LoginComponent Challenge 2 ❖ Grab the user details from the Login form ❖ Make a post request using axios or any http library to the backend API ❖ Backend API actually returns two tokens, an id_token and an access_token. ❖ Store both tokens in Local Storage.

Slide 13

Slide 13 text

Implementation - Backend API Challenge 2

Slide 14

Slide 14 text

Libraries for generating JWTs Challenge 2 https://jwt.io/#libraries-io

Slide 15

Slide 15 text

Implementation - Backend API Challenge 2 ❖ Create a signed id_token from the user’s details. ❖ Create a signed access_token from the user’s details.

Slide 16

Slide 16 text

Implementation - Why do we have two tokens? Challenge 2 ❖ Why do we have an id_token & an access_token? An id_token’s purpose is to authenticate the user to the client. An access_token’s purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the scope that has been granted). https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/

Slide 17

Slide 17 text

Client Session - Staying Authenticated. Challenge 2 ❖ We are using a stateless authentication mechanism. ❖ How do we ensure the user stays authenticated? ❖ An expiry date is attached to the tokens. If the JWT is expired, the user shouldn’t be logged in or able to access any protected resource. ❖ If the token expires, log the user out and redirect to the login route.

Slide 18

Slide 18 text

Protecting Routes and Resources Challenge 2 ❖ Authentication is mainly added to a system to restrict resource access to users who have proven they are allowed to access those resources. ❖ Your app can be publicly accessible ❖ Your app can be limited to authenticated users. ❖ Your app can be limited to a subset of authenticated users. ❖ We can create routes for resources that require an authentication check. ❖ To pass the check, a valid JWT must be present. ❖ When making HTTP requests, we can send the JWT as an Authorization header. ❖ If the JWT is valid, the resource will be accessible.

Slide 19

Slide 19 text

Protecting Routes and Resources - Frontend Challenge 2 ❖ Use the onEnter attribute of the Route path.

Slide 20

Slide 20 text

Protecting Routes and Resources - Frontend Challenge 2

Slide 21

Slide 21 text

Making Authenticated Requests - Frontend Challenge 2

Slide 22

Slide 22 text

Protecting Routes and Resources - Backend Challenge 2

Slide 23

Slide 23 text

Things to Note Challenge 2 ❖ Always serve your app and API over HTTPS ❖ Cross Site Request Forgery Attacks if using cookies ❖ Cross Site Scripting (XSS) if using local storage. ❖ Always escape user input and put CSRF protection in place.

Slide 24

Slide 24 text

Auth0 & Firebase can handle your Authentication easily Challenge 2 ❖ Social Authentication with many Providers - Facebook, Twitter, Google, LinkedIn etc ❖ Email and Password Authentication ❖ Single Sign On ❖ https://auth0.com/blog/reactjs-authentication-tutorial/ ❖ https://www.youtube.com/watch?v=mwNATxfUsgI ❖ https://auth0.com/blog/adding-authentication-to-react-native-using-jwt/ ❖ https://www.sitepoint.com/authentication-in-react-native-with-firebase/

Slide 25

Slide 25 text

Demo using Auth0

Slide 26

Slide 26 text

Thank You!