Access Token Protection: Secure Connectivity for Mobile Apps

In this article, we introduce the role that access tokens play in mobile banking applications and provide recommendations on how to secure these access tokens. We will also explain why such security measures are important.

What is an Access Token?

Access tokens are largely used in the context of mobile banking, to connect between the application and third-party APIs and, as such, they must be treated as a critical security parameter.

Web applications usually require authentication from the user. The authentication may consist of submitting passwords, either static or dynamic (one-time passwords), biometric data, certificates, or even answering questions. In all cases, a secret is shared by the user and the remote server. Once the authorization is performed, the client application will need to stay authorized for a certain amount of time so that it may perform the operations that are needed.

Since the application will obviously not require the user to submit their secrets for each network request, there must be a mechanism that silently grants the application the right to stay connected to the remote server, and which will be authenticated as the user. Usually, this consists of a file that is created at the client-side and which holds the authentication information. It will usually have an expiration date after which the user will have to re-authenticate himself. 

Almost everyone has heard of browser cookies. These are usually the basic form of such a passive authentication mechanism. The username and password are stored in the cookie. Of course, it is usually a bad idea to store a username and password locally because, even encrypted, there are many attacks that can be achieved with stolen cookies. 

There are generally two different kinds of stronger passive authentication mechanisms: identity tokens and access tokens. Both are sent by the server to the client. In general, this is not the end-server (“resource” server) that sends the tokens. Instead, it is an intermediary server such as the authentication server (e.g. an OAuth 2.0 server). 

Additionally, both tokens are usually JWT tokens (JSON Web Token). These are tokens which are URL safe, compact and used in SSO context (Single-Sign-On). The JWT tokens assert a certain amount of claims. These claims are verified because they are signed by a private key on the remote side. So, each time they are sent back by the client, the server can verify the claims by checking the authenticity of the signature.

Identity tokens by themselves do not grant access to resources. However, they identify the user, confirm the user has authenticated, and retrieve information about his/her profile.

Access tokens, on the contrary, do not bear identification marks but grant access to a given resource. They are designed to have a short lifespan and can embed several other information like IP address or client’s signature for example. 

Risks with Access Tokens in the Context of Mobile Banking Applications

Stealing access tokens obviously gives access to authentication. Access tokens are not one-time passwords. Having knowledge of the token value, acting as a cryptographic key, will provide access to the API for the duration of the token lifespan. For example, a third-party application trojan acting as a fake app, could steal the tokens and use them to do requests on behalf of the legitimate client, therefore performing fraudulent financial operations.

Most authentication service providers and mobile banking application integrators choose to implement the OAuth 2.0 authorization grant flow which, without further protections, presents certain risks for the whole security of the application.

While the flow occurs inside TLS channels, there are certain ways to intercept the values of the access token that are granted:

• Hackers can reverse-engineer the legitimate banking application then extract its client id, redirection URLs, client secrets, etc. Then, they recreate a fake application by recompiling a modified application with those values that look perfectly valid to the OAuth 2.0 server and granting access tokens;
• Hackers can tamper with the URL redirection, for example, running a server on the mobile phone and tampering with the host file to intercept the authorization code. They can then use it to get access tokens from the OAuth 2.0 server and use them in lieu of the legitimate application.

There are other risks involved with access tokens in mobile banking that are beyond the scope of this article.

How to Protect Access Tokens

The application should:

• Use Proof Key for Code Exchange (PKCE) when dealing with authorization grant flows;
• Use Dynamic Attestation Protection with a secure authorization middleman service when dealing with authorization grant flow;
• Not store the OAuth app credentials in the source code or elsewhere;
• Not hardcode access tokens in the banking application;
• Use a protocol such as OpenID connect to deal with OAuth authentication rather than using a homebrew system;
• Protect the JWT tokens;
• Store the tokens in secure cookies or in an encrypted file;
• Use TLS1.2+ to transport the tokens and not use GET but only POST requests.

References and Further Reading

• Read more articles about Runtime Application Self-Protection (RASP) for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more