Today’s applications use a great many login and authentication methods and workflows. Here, I’ll share the most relevant and proven authentication workflows, which you can use as a basis for architecting and designing an authentication system for traditional web applications, single-page applications and native mobile applications.
Authentication Workflows for Traditional Web Applications
Traditional web applications load a web page and provide user functionality using a message-based model where a browser makes an HTTP request to a web server based on the URL in the address bar. The server responds to this request with HTML, CSS and JavaScript and then displays a resource in the browser. Along with traditional web apps, new web apps often still provide functionality in this manner.
When a user submits a form or clicks a link or button, the browser sends a new HTTP request to the web server and changes the URL in the address bar. The server again responds by returning HTML, CSS and JavaScript and then displaying a resource in the browser.
Browsers support only two HTTP methods for traditional web apps: GET and POST. GET is used to request data from a specified resource and POST is used to send data to a server to create or update a resource.
Below are several workflows you can use for traditional web app login and authentication. Note that the application backend is the backend of the application (not the identity provider, or IdP) and native login form is a form built directly into the application instead of an external login form.
Native login form to the application backend using … | |
OAuth 2 authorization code grant using … | |
JWTs and refresh tokens stored in cookies (RECOMMENDED) | |
Sessions (RECOMMENDED) | |
OAuth 2 resource owner password credentials grant using … | |
Authentication Workflows for Single-Page Applications
A single-page web app (SPA, pronounced as “spa” or “S-P-A”) runs entirely in the browser after loading the HTML, CSS and JavaScript source code from a web page. After retrieving the HTML, CSS and JavaScript that make up the application, the browser invokes a JavaScript framework that bootstraps and then renders the application.
SPAs call APIs to handle user interactions and input. For example, if a user clicks a link or submits a form, the SPA might render a different page or form.
APIs are invoked using XMLHttpRequest, a built-in browser object that can make HTTP requests in JavaScript. When the server responds, the JavaScript running in the browser updates the data dynamically without performing a full page refresh.
SPAs use a single request and response model. Since the browser uses XMLHttpRequest, it can support GET and POST, as well as other standard HTTP methods, such as PUT and DELETE. (PUT is used to replace all current representations of the specified resource and DELETE is used to, well, delete the specified resource.) The HTTP method chosen tells the server how to handle the request.
Here are some workflows you can use for SPA login and authentication.
Native login form to the application backend using … | |
Native login form to FusionAuth using … | |
JWTs stored in local storage and refresh tokens stored in cookies | |
OAuth 2 authorization code grant using … | |
OAuth 2 implicit grant using … | |
OAuth 2 resource owner password credentials grant using … | |
When using OAuth for SPAs, note that the browser navigates away from the SPA to the OAuth provider. Once the OAuth workflow is complete, the browser is sent back to the SPA page where it quickly restarts the SPA with cached assets.
Authentication Workflows for Native Mobile Applications
Native mobile applications are usually installed on a mobile device or any smart device through an online marketplace like App Store and Google Play Store. Clicking the application icon on the device launches the device operating system, which starts the application and its user interface.
Almost all native applications call APIs on the server to handle user interactions and input, such as button clicks and form submissions. Native applications often use libraries designed to directly access all of the classes, objects, functions and methods of the source code to communicate quickly with APIs and simplify API calls.
Here are a few workflows you can use for native mobile application login and authentication:
Note that native mobile applications can also use the OAuth authorization code grant to exchange an authorization code for an access token. This workflow works with many IdPs and is essentially the same as described in the preceding traditional web application and single-page application sections. The main difference is that the native application pulls the JWT and refresh tokens from the web view at the end of the OAuth workflow.
Authentication System Best Practices
The workflows listed above should give you a baseline for following authentication system best practices and architecting a sound login and authentication system for your applications. While these examples use FusionAuth as the IdP, any IdP can be used. Most IdPs are capable of a wide variety of login and authentication workflows, and the examples here are not meant to be exhaustive.
As you’re designing an authentication system for traditional web applications, single-page applications or native mobile applications, keep in mind that some IdP login workflows can pose serious security risks. As with all things having to do with digital identities and user and data security, it’s important to choose both your IdP and your authentication workflow wisely.
