Making great mobile applications with the IBM Object Storage service

Share this post:

Update 06/26/18: As of August 1, 2018, no new instances of Object Storage OpenStack Swift (PaaS) can be created. This does not apply to Object Storage OpenStack Swift (Infrastructure) that is offered through the IBM Cloud Infrastructure. Migrate to the latest generation of IBM Cloud Object Storage to take advantage of all the new features and integrations with IBM Cloud services. Learn more.

Building a great mobile application is not an easy task. You need to consider security, user engagement, user experience, and many other aspects. Luckily you can reduce the overhead of managing and maintaining various server-side components by using ready-made cloud services that provide authentication, notifications, analytics, data storage capabilities, and more. Let’s focus on how your mobile application stores binary data.

Binary data is everywhere

JSON has become the data format standard for mobile applications, mainly because it’s lightweight and simple to use. But while it works great for textual data, binary data is everywhere — JPG or PNG files for images, PDF files for official forms or even movie tickets, ZIP files with backups, MP3 files for sound recordings, and many more. Storing these binary formats is essential for many mobile applications.

Persisting binary data is something many application developers take for granted. What could be simpler? You just upload a file to some storage and retrieve it whenever you need it, right? But binary data is still data, so you need to ask yourself all the standard data-management questions to ensure that your application does not expose data to unauthorized users:

  • How do you secure this data? How do you ensure users can access only their own data?
  • How do you ensure that some data is public, but other data is private?
  • How do you access data from mobile phones with limited bandwidth?
  • How do you access data from a backend server?
  • How do you get analytics for data access?

Enter IBM Object Storage service

IBM Object Storage service provides an unstructured cloud data store that you can use to build and deliver cloud applications with lowered cost, reliability, and speed to market. You and the application users can access and store binary data content and interactively compose and connect to applications and services. The Object Storage service also provides programmatic access via API, SDKs, and a consumable UI for object management.

An essential consideration for mobile applications is the way you treat your service credentials. Ordinarily, when you provision an instance of the Object Storage service, you get a set of credentials you can use to obtain an authToken. It is considered a good practice to keep your credentials safe, which means never exposing them beyond your backend server. However, in mobile scenarios, you might need to communicate with Object Storage directly from your mobile application. This is where the authToken comes in handy: You can obtain the Object Storage authToken on a backend server and send it to a mobile application so it can communicate with an Object Storage service instance.

That said, an authToken gives its possessor full access to everything stored in the particular Object Storage instance. Basically once you have an authToken, you can see everyone’s files. This might not be a problem if you’re building, say, a shared photo album application. However, this might be a serious limitation if you’re building an Instagram-style application, where users manage their personal photos only.

Client-side and server-side SDKs

The following SDKs will help you easily consume the Object Storage service. They’re packed with unit tests and built/tested automatically by Travis. And they’re open-sourced, so you’re welcome to use them as is or extend them to meet your needs. The API is simple and intuitive.

You can easily connect to Object Storage with either your service credentials or authToken by creating a new instance of ObjectStorage and using various methods to manage containers, objects, and metadata:

    // Connect to ObjectStorage
let objstorage = ObjectStorage(projectId:"your-project-id")
objstorage.connect( authToken: "your-auth-token", region: ObjectStorage.REGION_DALLAS) { (error) in
if let error = error {
print("connect error :: \(error)")
} else {
print("connect success")

// Retrieve container
objstorage.retrieveContainer(name: "container-name") { (error, container) in
if let error = error {
print("retrieveContainer error :: \(error)")
} else {
print("retrieveContainer success :: \(container?.name)")

// Retrieve object
object.load(shouldCache: false) { (error, data) in
if let error = error {
print("load error :: \(error)")
} else {
print("load success :: \(data)")

Sample flow #1: Delivering user credentials to the mobile app

As mentioned previously, it’s a good practice to keep your credentials safe and not expose them beyond the backend server. So whenever the mobile application needs to communicate with Object Storage directly, it should use the authToken instead. The flow below demonstrates how to use the Mobile Client Access service to retrieve an Object Storage authToken and return it to the mobile application after successful user authentication: (Click to the images to enlarge them.)



The mobile application is instrumented with the Mobile Client Access SDK as well as the Object Storage SDK. We’ve configured the Mobile Client Access service to use a custom identity provider, which will validate supplied user credentials against a hard-coded user repository (for the sake of simplicity) and then retrieve an authToken from Identity Service. The authToken will be returned to the mobile application and used in the Object Storage SDK to make requests to the Object Storage service.

As described previously, this flow is good for creating applications with shared content. Having an Object Storage authToken allows access to any container and any object even if they were uploaded by different users. To overcome this potential limitation, the authToken should never be returned directly to the mobile application. Instead, you should create a backend server responsible for serving files and enforcing security policies. Creating a backend server is easy with the server-side SDKs, and the Mobile Client Access service provides server-side authorization filters that allow you to protect Node.js, Swift, and Java servers from unauthorized access.

You can download this sample from GitHub, including mobile application and custom identity provider code.

See the file for usage instructions.

Sample flow #2: Using the Object Storage SDK in a Node.js backend server

This flow demonstrates how to use the Object Storage SDK in a Node.js backend server to easily retrieve data from the Object Storage service and provide it to mobile clients, as well as how to use the Mobile Client Access service to protect a Node.js backend from unauthorized access, which forces users to authenticate before they can access their content.

The backend server exposes two endpoints: /public and /private. Requests sent to a /public endpoint do not require authorization. Whenever a mobile client sends a request to the /public endpoint, the backend server looks for an object in the public container (literally, the container name is “public”). Requests sent to the /private endpoint require the mobile client to be authorized. In case the mobile client is not authorized yet, it will be redirected to the Mobile Client Access service to authenticate. After successful authentication, the mobile client is then able to make a request to the /private endpoint and receive data. In case of the /private endpoint, the backend server looks for an object in the container with the user’s userId.

This implementation uses a common cloud storage approach: a shared public container that is accessible by all users, as well as a private container for every user that no other user can access: (Click to the images to enlarge them.)



Note that for the sake of simplicity, the sample retrieves the authToken from Identity service on startup. But this doesn’t have to be the case. You can lazily retrieve and refresh the authToken whenever it is required, but remember that it’s valid for only 60 minutes.

You can download this sample from GitHub, including mobile application and custom identity provider code.

See the file for usage instructions.


Object Storage is a handy service you might want to use in your next mobile application. We hope the SDKs we’ve created and the reference samples will help you make your applications even more amazing!

Learn more about the IBM Object Storage service and see how it’s being used in a mobile application to assist animal-rescue agencies.

STSM, IBM Cloud Developer Services

More How-tos stories
April 25, 2019

What is Object Storage?

In our latest lightboarding video, Anirup Dutta explains how object storage works, lists some of the benefits, and give you some use cases for when object storage may be your best option.

Continue reading

April 18, 2019

Using Fio to Tell Whether Your Storage is Fast Enough for Etcd

We're going to show you how to use fio—a very popular I/O tester—to evaluate whether your intended storage for etcd is fast enough to support good etcd performance.

Continue reading

April 5, 2019

IBM Cloud App ID: Updated Runtime APIs Provide Tighter Interoperability for Your Cloud-Native Apps

As part of our efforts to tighten interoperability and broaden the frameworks that are able to use IBM Cloud App ID, we've updated the runtime APIs.

Continue reading