Access and refresh tokens are a critical component of modern web applications, allowing developers to consume APIs on behalf of their users. However, storing access tokens in the browser can create serious security risks. However, the practice of storing access tokens in the browser can create serious security risks.
The first problem with storing access tokens in a browser is the susceptibility of the transmission of tokens from the authentication server to the application. When tokens are transmitted from the authentication server, they can be intercepted in a variety of ways. This is especially true when ingress controllers or load balancers with TLS termination or SSL bridging sit in front of the authentication server. In such a scenario, administrators with access to the device could easily sniff the tokens off the wire.
Another possible interception mechanism is by legitimate users on a corporate network that monitors HTTPS traffic using a proxy server with “trusted” certificates on domain workstations. In this case, corporate administrators have access to network traffic between the single-page application and the authentication server.
If access tokens are sent in the URL, browser history inspection becomes yet another potential attack vector. This is common when using OAuth’s implicit grant type. In this scenario, network administrators may have access to the browser history of workstations on their network.
Ben Botto wrote a great blog post on this topic: Secure Access Token Storage with Single-Page Applications: Part 1
These examples highlight how any “man in the middle” with access to plain-text network traffic can easily access the tokens. Even worse, in some cases, anyone with access to the legitimate user’s browser history can potentially steal tokens as well. All these interception mechanisms illustrate the risks involved in storing access tokens in a browser.
So, what is the alternative to storing access tokens in a browser?
-
One approach is to use server-side sessions. When the user logs in, the server generates a session ID and stores it in a cookie. This cookie is sent with every request, and the server uses the session ID to look up the user’s token in a database. This approach ensures that the token is never stored in the browser, making it much more secure.
-
Another approach is to use HTTP-only cookies to store the token. This type of cookie can only be accessed by the server, so it is not vulnerable to cross-site scripting (XSS) attacks. However, careful implementation is necessary to ensure that the token is not vulnerable to other types of attacks, such as cross-site request forgery (CSRF).
You may also want to check out these dedicated authentications platforms but if you are looking at Aurinko for your API integration needs already know that it also provides secure token storage. Authentication flows for Google, Office 365, and CRM accounts are native to Aurinko and naturally Openid scope is supported by those API providers. You can potentially implement authentication using Salesforce or Hubspot Ids. Microsoft’s idTokens are also supported (issued by Outlook to its addins). Access and refresh tokens are obtained by Aurinko servers and stored security. An HTTP-only user session cookie is set for your app and the app not have to handle the tokens in browser.
Moreover, Aurinko is designed to be a backend API for single page apps and various kinds of addons. Which means that after obtaining the session cookie the app can send API requests to multiple APIs through Aurinko as if Aurinko was its backend/proxy. Check out the details of how you use Aurinko’s auth flow to initialize a user session and call APIs without storing tokens in a browser: Microsoft Teams apps, Outlook addons.
In conclusion, storing access tokens in the browser can create significant security risks for web applications. While server-side sessions and HTTP-only cookies can provide a solution, a dedicated API platform like Aurinko can offer a more secure and scalable option. By using Aurinko, developers can ensure that their users’ data is protected and that their applications are secure from potential token interception attacks.