{"id":6486,"date":"2018-11-19T11:09:19","date_gmt":"2018-11-19T11:09:19","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=6486"},"modified":"2022-11-24T10:37:35","modified_gmt":"2022-11-24T10:37:35","slug":"token-management-best-practices","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/token-management-best-practices\/","title":{"rendered":"Token Management Security Best Practices"},"content":{"rendered":"

We recently participated to the DZone mobile apps development guide to highlights some of the key best practices when dealing with API keys and tokens. Below is an excerpt, the full article is available<\/a> on DZone!<\/p>\n

Modern applications, both \u00a0web-based and native, rely on APIs on the backend to access protected resources. To authorise access those APIs, a request must include some kind of access token or key. This article focuses on security best practices for access token management, for the API providers and application developers alike.<\/span><\/p>\n

Let\u2019s talk about trust first!<\/b><\/span><\/h2>\n

When dealing with security, a single rule prevails: trust no one. If you\u2019re an API provider, you can\u2019t trust that the application invoking the APIs is the one you expect, that the token you received has not been stolen, or that the communication between client and the server has not been intercepted.<\/span><\/a> On the client side, you can\u2019t trust that the application will not be decompiled, exposing embedded secrets, that the application storage will not be compromised through an XSS<\/span><\/a> attack, or that your users are not being fooled into submitting forged requests<\/span><\/a>.<\/span><\/p>\n

This implies that you must put in place proper measures to securely obtain, store and manage the security tokens required to invoke backend APIs.<\/span><\/p>\n

Additionally, you may think your APIs are safe if you have never publicly advertised them. To you, they feel private, because they are only used by your enterprise applications. However, if they can be used from a mobile application, they are on the public internet, and thus public. Any API exposed outside your enterprise network must<\/span><\/a><\/span> be considered public.<\/span><\/p>\n

Obtaining tokens and API keys<\/b><\/span><\/h2>\n

When it comes to using an API, you are usually offered two choices: \u00a0pass a static piece of information together with the API call, or obtain that piece of information dynamically prior to invoking the API. This piece of information is usually an access token or API key. BasicAuth is still used for some APIs for legacy reasons, but is deprecated as a mainstream solution.<\/span><\/p>\n

When designing the security aspects of your API, you must choose wisely how your API consumers access it. Like usually with security measures, the induced risk is the key factor to take in account. Securing an API which only allows to consult weather data is very different from securing a banking payments API. <\/span><\/p>\n

While using an API key is easier for the developer, it does not give the same level of security as an access token obtained with two-factor user authentication and the proper identification of the client application. Moreover, an API key does not carry any information about the user and can\u2019t be used at the backend level to decide which operations the API consumer is allowed to invoke. Finally, API keys never expire, unless revoked by the API provider.<\/span><\/p>\n

OAuth was created to address these drawbacks: the application accessing the resource is known (using client application credentials), the API provider can define scopes to limit the access to certain operations (you can GET a catalog entry, but you can\u2019t PUT a new catalog entry, even with a valid token), and tokens have a limited lifetime. <\/span><\/p>\n

Token management recommendations<\/b><\/span><\/h2>\n

Beware of OAuth app credentials leaks<\/span><\/p>\n

Storing your application code in Github? Are your OAuth app credentials stored there as well, and in particular the client secret? This is the <\/span>number one source <\/b><\/span>of credentials leaks today. If those credentials are stolen, anybody can pretend to be you. If you believe credentials could have been compromised, regenerate them immediately. <\/span><\/p>\n

Additionally, never put your client secret<\/b> in distributed code, such as apps downloaded through an app store or client-side JavaScript.<\/span><\/p>\n

Don\u2019t hardcode tokens in applications <\/span><\/h3>\n

It can be tempting to simplify code to obtain a token for a long period of time and store it in your application. Don\u2019t. Do. That.<\/span><\/p>\n

Treat tokens as you would treat passwords. <\/span><\/h3>\n

They are the door key!\u00a0<\/span>Tokens and API keys allow anybody who has them to access a resource. As such, they are as critical as passwords. Treat them the same way!<\/span><\/p>\n

OAuth is not an authentication protocol!<\/span><\/h3>\n

OAuth is about delegating access to a resource. It is not an authentication protocol (despite the name, mind you). <\/span>Think of tokens as hotel cards: you need to authenticate yourself to obtain the hotel key, but once you have it, in no way does it prove who you are. API providers must not rely on token possession as a proof of identity, as proven by this recent user information leakage<\/span><\/a>.<\/span><\/p>\n

You really should look at OpenID Connect<\/span><\/a> (OIDC), a complementary specification, rather than trying to implement authentication on top of OAuth yourself. OIDC allows a user to share some aspects of their profile with an application, with no need to share their credentials.<\/span><\/p>\n

Beware of what you store in JWTs and who has access to them<\/span><\/h3>\n

JWTs can store plenty of information in the form of claims, and can easily be parsed if captured (unless they are encrypted). If you are using JWTs to carry information that is only useful to the backend services, you can take a different approach, which is provided by many API security gateways OOTB:<\/span><\/p>\n