Logo / Articles

Login & Auth Workflows

Single-Page Application OAuth Login Using Implicit Grant With Session

By Brian Pontarelli

This workflow is used by single-page applications using the FusionAuth OAuth login interface. The single-page application navigates away from its interface and over to FusionAuth’s OAuth interface. Once the user completes their login, FusionAuth redirects back to the single-page application. This requires that the single-page application re-initialize itself, but the browser should cache the application files and be able to restart it quickly. 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 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
BrowserStoreForumsFusionAuthHackerInitializeLogin (browser navigates away from SPA)Start sessionShopping cart loadSession expiresShopping cart loadAutomatic re-login (since session exists)Start sessionShopping cart loadSSO login to forumsInitializeLogin (browser navigates away from SPA but auto-logs-in since the session exists)Start sessionForum loadAttack vectorsStolen session idGET /1(SPA HTML, CSS & JavaScript)2AJAX GET /api/user[No cookies]3404 Missing4GET /oauth2/authorize {response_type=token}5(Login form HTML)6POST /oauth2/authorize (response_type=token)7302 Location: {redirect_uri w/ JWT in redirect URI and no refresh token}[SessionId HttpOnly w/ domain: example.fusionauth.io]8GET {redirect_uri w/o JWT in URI}9(SPA HTML, CSS & JavaScript)10AJAX POST /api/start-session(JWT from redirect_uri)11Optionally store JWTin session12[SessionId HttpOnly w/ domain: store.example.com]13AJAX GET /api/load-shopping-cart[SessionId HttpOnly w/ domain: store.example.com]14Session extended15(Shopping cart contents)16AJAX GET /api/load-shopping-cart[SessionId HttpOnly w/ domain: store.example.com]17401 Not Authorized18GET /oauth2/authorize {response_type=token}[SessionId HttpOnly w/ domain: example.fusionauth.io]19302 Location: {redirect_uri w/ JWT in redirect URI and no refresh token}[SessionId HttpOnly w/ domain: example.fusionauth.io]20GET {redirect_uri w/o JWT in URI}21(SPA HTML, CSS & JavaScript)22AJAX POST /api/start-session(JWT from redirect_uri)23Optionally store JWTin session24[SessionId HttpOnly w/ domain: store.example.com]25AJAX GET /api/load-shopping-cart[SessionId HttpOnly w/ domain: store.example.com]26Session extended27(Shopping cart contents)28GET /[No cookies]29(SPA HTML, CSS & JavaScript)30GET /api/user[No cookies]31404 Missing32GET /oauth2/authorize {response_type=token}[SessionId HttpOnly w/ domain: example.fusionauth.io]33302 Location: {redirect_uri w/ JWT in redirect URI and no refresh token}[SessionId HttpOnly w/ domain: example.fusionauth.io]34GET {redirect_uri w/o JWT in URI}35(SPA HTML, CSS & JavaScript)36AJAX POST /api/start-session(JWT from redirect_uri)37Optionally store JWTin session38[SessionId HttpOnly w/ domain: forums.example.com]39AJAX GET /api/load-posts[SessionId HttpOnly w/ domain: forums.example.com]40Session extended41(Forum posts)42GET /api/load-shopping-cart[SessionId HttpOnly w/ domain: store.example.com]43Session extended44(Shopping cart contents)45BrowserStoreForumsFusionAuthHacker

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 user clicks the login link and the browser navigates away from the single-page application to FusionAuth's OAuth 2 interface. The browser requests the OAuth 2 login page from FusionAuth with a response_type of token indicating that it is using the implicit grant
  6. FusionAuth responds with the HTML, CSS & JavaScript of the login page (including the form)
  7. The user inputs their credentials and clicks the submit button. The browser POSTs the form data to FusionAuth
  8. FusionAuth returns a redirect to the application backend's OAuth 2 redirect_uri. This redirect includes the access token (in our case a JWT) from FusionAuth. Also, this response includes a session id for the FusionAuth OAuth 2 interface as an HTTP cookie. This cookie is HttpOnly, which prevents JavaScript from accessing it, making it less vulnerable to theft
  9. The browser requests the application backend's OAuth redirect_uri. This request does not include the JWT because it is after the # in the URL, which means the browser will not send it in the HTTP request to the application backend
  10. The application backend responds with the HTML, CSS & JavaScript of the application. During this step, the browser will initialize the single-page application. As part of the initialization of the application, the JWT will be pulled from the current URL of the browser
  11. The browser extracts the JWT from the current URL and then sends it via an AJAX POST to the Start Session API in application backend
  12. The application backend creates a server-side session and stores the JWT in it
  13. The application backend responds with a 200 and an HttpOnly cookie that contains the session id of the server-side session
  14. The browser requests the user's shopping cart from the application backend via AJAX and includes the session cookie
  15. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  16. 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 (usually as JSON)
  17. 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 via AJAX and sends the session cookie to the application backend
  18. The application backend attempts to load the server-side session associated with session cookie and realizes it is expired and returns a 401 indicating the user is no longer logged in
  19. The application might automatically redirect the browser back to FusionAuth's OAuth 2 interface or wait until the user clicks the login link. Regardless, the browser requests the OAuth 2 login page from FusionAuth with a response_type of token indicating that it is using the implicit grant
  20. FusionAuth realizes that the user already has a session and is already logged in. Therefore, it returns a redirect to the application backend's OAuth 2 redirect_uri. This redirect includes a new JWT from FusionAuth in the URI
  21. The browser requests the application backend's OAuth redirect_uri. This request does not include the JWT because it is after the # in the URL, which means the browser will not send it in the HTTP request to the application backend
  22. The application backend responds with the HTML, CSS & JavaScript of the application. During this step, the browser will initialize the single-page application. As part of the initialization of the application, the JWT will be pulled from the current URL of the browser
  23. The browser extracts the JWT from the current URL and then sends it via an AJAX POST to the Start Session API in application backend
  24. The application backend creates a server-side session and stores the JWT in it
  25. The application backend responds with a 200 and an HttpOnly cookie that contains the session id of the server-side session
  26. The browser requests the user's shopping cart from the application backend via AJAX and includes the session cookie
  27. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  28. 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 (usually as JSON)
  29. The browser requests the forums single-page application from the application backend. This is a standard SSO login that is fully supported by FusionAuth
  30. The application backend responds with the HTML, CSS & JavaScript of the application
  31. 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
  32. The application backend responds with a 404 indicating the user is not logged in
  33. The application might automatically redirect the browser back to FusionAuth's OAuth 2 interface or wait until the user clicks the login link. Regardless, the browser requests the OAuth 2 login page from FusionAuth with a response_type of token indicating that it is using the implicit grant
  34. FusionAuth realizes that the user already has a session and is already logged in. Therefore, it returns a redirect to the application backend's OAuth 2 redirect_uri. This redirect includes a new JWT from FusionAuth in the URI
  35. The browser requests the application backend's OAuth redirect_uri. This request does not include the JWT because it is after the # in the URL, which means the browser will not send it in the HTTP request to the application backend
  36. The application backend responds with the HTML, CSS & JavaScript of the application. During this step, the browser will initialize the single-page application. As part of the initialization of the application, the JWT will be pulled from the current URL of the browser
  37. The browser extracts the JWT from the current URL and then sends it via an AJAX POST to the Start Session API in application backend
  38. The application backend creates a server-side session and stores the JWT in it
  39. The application backend responds with a 200 and an HttpOnly cookie that contains the session id of the server-side session
  40. The browser requests the user's forum posts from the application backend via AJAX and includes the session cookie
  41. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  42. 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 (usually as JSON)
  43. 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
  44. The application backend looks up the server-side session associated with the session cookie and extends the expiration date
  45. 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 contents (usually as JSON)

Security considerations

This workflow is less secure than other workflows because the JWT is available to JavaScript during the start session 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.

Additionally, since this workflow does not use refresh tokens (and cannot use refresh tokens according to the specification). Therefore, when the user’s session expires, they will need to log into the application again. This could be an automatic login, but it still requires the browser to take the user to the FusionAuth OAuth interface.

APIs used

Here are the FusionAuth APIs used in this example: