Single-Page Application Native Login To FusionAuth With JWTs And Refresh Tokens

This workflow example is used by single-page applications using a native login form inside the webapp. This login form uses an AJAX

For all of our examples, we use a store and a forum for the same company. The store requires a user to login to view their shopping cart and the forum requires the user to login to view forum posts. We also provide a couple of example attack vectors that hackers could use if portions of the system are compromised. These cases might be theoretical or based on known exploits such as XSS (cross-site scripting).

Diagram

Legend

() --> request/response bodies
{} --> request parameters
[] --> cookies

Explanation

1. The browser requests the shopping cart single-page application from the application backend
2. The application backend responds with the HTML, CSS & JavaScript of the application
3. The browser loads the application and as part of the initialization process, it makes a request to the application backend to see if the user is logged in
4. The application backend responds with a 404 indicating the user is not logged in
5. The application renders the login form
6. The user inputs their credentials and clicks the submit button. The browser AJAX POSTs the form data directly to the Login API in FusionAuth
7. FusionAuth returns a 200 status code stating that the credentials were okay. It also returns a JWT in JSON and a refresh token cookie with the domain of the FusionAuth server (which could be different than the application backend)
8. The application calls the cookie drop API in the application backend and sends it the JWT in the request body
9. The application backend responds with a 200 and an HttpOnly cookie that contains the JWT
10. The browser requests the user's shopping cart via AJAX from the application backend and includes the JWT
11. The application backend verifies the JWT and then uses the JWT to identify the user. Once the user is identified, the backend looks up the user's shopping cart from the database (or similar location). Finally, the application backend returns the user's shopping cart contents (usually as JSON)
12. A while later, the user's JWT expires and the user clicks on their shopping cart again. The browser requests the user's shopping cart via AJAX from the application backend and includes the JWT cookie
13. The application backend responds with a 401, indicating that the JWT has expired
14. The application recognizes that the JWT has expired and makes a request directly to the JWT refresh API in FusionAuth. This request includes the refresh token cookie
15. FusionAuth looks up the refresh token and returns a new JWT (either in the body or as an HttpOnly cookie depending on the workflow)
16. The application calls the cookie drop API in the application backend and sends it the JWT in the request body
17. The application backend responds with a 200 and an HttpOnly cookie that contains the JWT
18. The browser requests the user's shopping cart via AJAX from the application backend and includes the JWT
19. The application backend verifies the JWT and then uses the JWT to identify the user. Once the user is identified, the backend looks up the user's shopping cart from the database (or similar location). Finally, the application backend returns the user's shopping cart contents (usually as JSON)
20. A while later, the user's JWT expires and the user clicks on their shopping cart again. The browser requests the user's shopping cart via AJAX from the application backend and includes the JWT cookie
21. The application backend responds with a 401, indicating that the JWT has expired
22. The application recognizes that the JWT has expired and makes a request directly to the JWT refresh API in FusionAuth. This request includes the refresh token cookie
23. Since the refresh token has expired, FusionAuth returns a 404 status code
24. At this point, the application can allow the user to log in the same way they did above
25. The browser requests the forums single-page application from the application backend. This is a standard SSO login, but because of the way this workflow manages cookies and identities, FusionAuth does not provide SSO capabilities automatically
26. The application backend responds with the HTML, CSS & JavaScript of the application
27. The browser loads the application and as part of the initialization process, it makes a request to the application backend to see if the user is logged in
28. The application backend responds with a 404 indicating the user is not logged in
29. The application renders the login form
30. The user inputs their credentials and clicks the submit button. The browser AJAX POSTs the form data directly to the Login API in FusionAuth. The refresh token cookie from the Store application is sent to FusionAuth here as well. **NOTE** this refresh token cookie is for the wrong application
31. FusionAuth returns a 200 status code stating that the credentials were okay. It also returns a JWT in JSON and a refresh token cookie with the domain of the FusionAuth server (which could be different than the application backend)
32. The browser updates the cookie that stores the refresh token to the new cookie value for the forums. This clobbers the refresh token for the store and will force the user to log into the store next time they open that application
33. The application calls the cookie drop API in the application backend and sends it the JWT in the request body
34. The application backend responds with a 200 and an HttpOnly cookie that contains the JWT
35. The browser requests the user's forum posts from the application backend via AJAX and includes the JWT cookie
36. The application backend verifies the JWT and then uses the JWT to identify the user. Once the user is identified, the backend looks up the user's forum posts from the database (or similar location). Finally, the application backend returns the user's forum posts that the browser renders (usually as JSON)
37. This is an attack vector where the attacker has stolen the user's refresh token. Here, the attacker can request directly to the JWT refresh API in FusionAuth since it is the same request the browser is making. The attacker includes the refresh token cookie in the request
38. FusionAuth looks up the refresh token and returns a new JWT
39. The attacker requests the user's shopping cart with the JWT
40. The application backend uses the JWT to look up the user's shopping cart. It responds to the attacker with the user's shopping cart (usually as JSON)
41. This is an attack vector where the attacker has stolen the user's JWT. Here, the attacker requests the user's shopping cart with the stolen JWT
42. The application backend verifies the JWT and then uses the JWT to identify the user. Once the user is identified, the backend looks up the user's shopping cart from the database (or similar location). Finally, the application backend returns the user's shopping cart to the attacker (usually as JSON)

Security considerations

This workflow is less secure than other workflows because the JWT is available to JavaScript during the cookie drop process. While this is a small window of time, it is still possible that malicious JavaScript running in the application could gain access to the JWT. If an attacker can inject JavaScript into the page, they can begin stealing user’s JWTs. The attacker might introduce JavaScript into an open source project through obfuscated code or through a backend exploit of some kind. Many platforms like Wordpress also allow plugins to add JavaScript includes to websites as well. Therefore, ensuring that your JavaScript is secure can be extremely difficult.

This workflow might still be a good solution for some applications. Developers should just weigh the risks associated with JWTs accessible to JavaScript versus the other workflows we have documented.

APIs used

Here are the FusionAuth APIs used in this example:

• /api/login
• /api/jwt/refresh
• /oauth2/token