This way, the Secret is never present in the communication channel. Even if an attacker was listening to the conversation, they could not change the request and use the authentication information to properly sign it, as this would change the digest and the attacker does not have the Secret that both the server and client has. As it stands, an attacker can still deny or replay the request, but cannot alter it.
Now we have two secrets to keep safe in the client, the shared API secret and the client’s private key used for mTLS. Which brings us to next topic, secure secrets in mobile devices.
Secure Secrets in Mobile Devices
Poorly hidden API keys and secrets inside mobile apps, are a common source of security breaks. Often, developers will spend time trying to obfuscate secrets in the app, to authenticate their app to their server. Trying to obfuscate secrets in mobile apps is a futile effort as the secrets can always be recovered using the abundance of reverse-engineering and debugging tools available. Unfortunately, for a secret held on mobile apps, it is not a question of if secret can be stolen, but when, and with how much effort. So, where to store secrets?
Many mobile apps needs to handle passwords and others kinds of sensitive data, such as keys and login tokens. The Keychain Services for iOS and SharedPreferences for Android provides a secure way to store these items. Those are encrypted containers that securely stores sensitive data on behalf of apps in the users' devices. You access those containers using the iOS and Android APIs.
Ok, so lets store our API Secret and TLS private key on this secure storage. Problem solved, right? No. You have the keys, but you do not have access to the user device. One way to do it would be on first launch of the app, call a endpoint over TLS in your API provider to download the credentials you need for the app. Then store those keys in the iOS or Android secured containers. This way the keys are not embedded in your code.
That's it. We are good to go. Wait a minute… what if your application is installed on jailbroken device? A hacker will be able to get your keys from the Keychain. Ok, so for extra protection you could also keep the keys info in an encrypted format, but then you would need to embed decryption keys in your binary. This is how you end up down the rabbit-hole of the key exchange problem.
Don't worry, we are getting there. Let me introduce two other concepts that will help you to improve the security of your app in the next section.
Overview of OAuth 2.0 and OpenID Connect
OAuth 2.0 and OpenID Connect (OIDC) are two complementary open standard protocols that are used to facilitate authentication (or authorization) to a mobile app and its associated API.
OAuth 2.0 is an open standard framework designed specifically to work with HTTP protocol. It essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner without sharing their credentials. The client itself does not receive any information about the user, it just gets a token that it can pass along to the API. This mechanism is used by many companies such as Facebook, Google and Twitter to permit the users to share information about their accounts with third-party applications or websites.
OpenID Connect is an open standard authentication layer that sits on top of the OAuth 2.0 authorization framework. It includes an ID token which provides details around the identity and the authentication of that identity to the application. This allows an application to identify the user, the context of their authentication, and retrieve additional profile information about the identity.
Depending on the requirements of the application, one or both of these protocols can be put in use. For example, an application may not care about the identity of the user; if the app cares only that the user is authorized to make an API call, OAuth 2.0 may be sufficient. However, another application may want to know details about the authenticating identity so that it can render content in an appropriate language and welcome the user by name. This application may leverage OpenID Connect for that personalization.
Let's discuss OAuth and OpenID Connect in more detail, and introduce some new concepts in Part 2.