Logo / Articles

Login & Auth Workflows

WebApp Native Login To Backend With Sessions

By Brian Pontarelli

This workflow is used by web applications using a native login form inside a webapp. This login form POSTs the user’s credentials (email and password) to the backend of the application. The application backend in turn calls to FusionAuth. Below is a diagram that describes the primary components of this workflow and how they interact. Keep in mind that not every interaction is covered here, just the primary login interactions. At the bottom of the diagram is a discussion of the key steps.

For all of our examples, we use a store and a forum for the same company. The store requires a user to log in to view their shopping cart and the forum requires the user to log in 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
BrowserStoreForumsFusionAuthHackerInitializeLogin (inside WebApp)Shopping cart loadSession expiresRe-loginSSO login to forums - not provided by FusionAuth for this workflowInitializeLogin (inside WebApp)Forum loadAttack vectorsStolen session idGET /1(HTML, CSS & JavaScript - with login link)2GET /login3(Login form HTML)4POST /login5POST /api/login6(User, Refresh Token and JWT)7Create session andstore User in it8302 Location: /shopping-cart[SessionId HttpOnly w/ domain: store.example.com]9GET /shopping-cart[SessionId HttpOnly w/ domain: store.example.com]10Session extended11(Shopping cart HTML)12GET /shopping-cart[SessionId HttpOnly w/ domain: store.example.com]13302 Location: /login14Login same as above15GET /[No cookies]16(HTML, CSS & JavaScript - with login link)17GET /login18(Login form HTML)19POST /login20POST /api/login21(User, Refresh Token and JWT)22Create session and putUser in it23302 Location: /posts[SessionId HttpOnly w/ domain: forums.example.com]24GET /posts[SessionId HttpOnly w/ domain: forums.example.com]25Session extended26(Forum posts HTML)27GET /shopping-cart[SessionId HttpOnly w/ domain: store.example.com]28Session extended29(Shopping cart HTML)30BrowserStoreForumsFusionAuthHacker

Explanation

  1. The browser requests the shopping cart webapp's homepage from the application backend
  2. The application backend responds with the HTML, CSS & JavaScript of the homepage
  3. The user clicks the login link and the browser requests the login page from the application backend
  4. The application backend responds with the HTML, CSS & JavaScript of the login page (including the form)
  5. The user inputs their credentials and clicks the submit button. The browser POSTs the form data to the application backend
  6. The application backend calls the Login API in FusionAuth by passing in the credentials it received
  7. FusionAuth returns a 200 status code stating that the credentials were okay. It also returns the User object, a JWT and a refresh token in JSON
  8. The application backend receives the 200 from FusionAuth and creates a server-side session and stores the User object (or JWT) in it
  9. The application backend returns a redirect to the browser instructing it to navigate to the user's shopping cart. The id of the server-side session is written back to the browser in an HTTP cookie. This cookie is HttpOnly, which prevents JavaScript from accessing it, making it less vulnerable to theft. Additionally, all requests from the browser to the application backend will include this cookie so that the backend can retrieve the User object from the server-side session
  10. The browser requests the user's shopping cart from the application backend and includes the session cookie
  11. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  12. The application backend loads the User object (or JWT) from the session associated with the session cookie. The backend then looks up the user's shopping cart from the database (or similar location). Finally, the application backend returns the user's shopping cart as HTML, CSS & JavaScript that the browser renders
  13. A while later, the user's server-side session expires and the user clicks on their shopping cart again. The browser requests the shopping cart from the application backend and sends the session cookie to the application backend
  14. The application backend attempts to load the server-side session associated with session cookie and realizes it is expired. The backend then returns a redirect to the browser that sends the user to the login page
  15. The user can log in the same way they did above
  16. The browser requests the forum webapp's homepage 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
  17. The application backend responds with the HTML, CSS & JavaScript of the homepage
  18. The user clicks the login link and the browser requests the login page from the application backend
  19. The application backend responds with the HTML, CSS & JavaScript of the login page (including the form)
  20. The user inputs their credentials and clicks the submit button. The browser POSTs the form data to the application backend
  21. The application backend calls the Login API in FusionAuth by passing in the credentials it received
  22. FusionAuth returns a 200 status code stating that the credentials were okay. It also returns the User object, a JWT and a refresh token in JSON
  23. The application backend receives the 200 from FusionAuth and creates a server-side session and stores the User object (or JWT) in it
  24. The application backend returns a redirect to the browser instructing it to navigate to the user's forum posts. The id of the server-side session is written back to the browser in an HTTP cookie. This cookie is HttpOnly, which prevents JavaScript from accessing it, making it less vulnerable to theft. Additionally, all requests from the browser to the application backend will include this cookie so that the backend can retrieve the User object from the server-side session
  25. The browser requests the user's forum posts from the application backend and includes the session cookie
  26. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  27. The application backend loads the User object (or JWT) from the session associated with the session cookie. 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 as HTML, CSS & JavaScript that the browser renders
  28. This is an attack vector where the attacker has stolen the user's session cookie. Here, the attacker requests the user's shopping cart with the stolen session cookie
  29. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  30. The application backend uses the session to look up the user's shopping cart. It responds to the attacker with the user's shopping cart HTML, CSS & JavaScript

Security considerations

This workflow is one of the more secure methods of authenticating users. One downside is that the application backend receives passwords from the browser. While this isn’t an issue if TLS is used and the passwords are not stored by the application backend, developers that do not want to be part of the password chain of responsibility should consider other workflows.

APIs used

Here are the FusionAuth APIs used in this example: