Secure your mobile serverless backend with App ID
Serverless is a good option for mobile application developers. Having no backend servers to manage is often cited as a reason why developers pick a serverless platform like IBM Cloud Functions. By removing infrastructure, developers can focus on the application code. And if we consider iOS and Android developers, with Cloud Functions, they have the option to implement their functions with Swift and Java.
The app uses these IBM Cloud products:
Its architecture is serverless:
The user authenticates against App ID. App ID provides access and identification tokens.
Further calls to the backend API include the access token.
The backend is implemented with Cloud Functions. The serverless actions, exposed as Web Actions, expect the token to be sent in the request headers and verify its validity (signature and expiration date) before allowing access to the actual API.
When the user submits a feedback, the feedback is stored in Cloudant.
The feedback text is processed with Tone Analyzer.
Based on the analysis result, a notification is sent back to the user with Push Notifications.
The user receives the notification on the device.
Authenticate users with App ID
Implementing the authentication flow in the mobile app is straightforward with App ID. The service provides both client and server SDKs. The server SDKs give you the right tools to secure and protect your resources when you are building a backend with Node.js or Swift. The client SDKs ease the integration with App ID in your iOS / Swift or Android / Java mobile apps.
In its dashboard in the IBM Cloud console, the App ID service has options to generate a sample (native) mobile or web application. We’ve used this option to kick-start the tutorial. The generated app code is easy to understand and comes preconfigured for your service instance so you can immediately try the generated app.
Upon successful authentication with Google or Facebook, App ID generates access and identification tokens. The tokens are JSON Web Tokens. They are persisted by the client code (here for Android and there for iOS).
Protect resources with App ID
In the tutorial, once the user is authenticated, the mobile app registers the user with the backend. The app calls a web action passing the access and identification tokens, together with the mobile device identifier – used later for Push Notifications. It is not a simple action exposed through HTTP but a sequence of actions. The sequence is made of two actions, one to validate and decode the provided tokens and another action to register the user. A similar flow occurs when the user submits a feedback.
The validation will fail if the tokens are missing, malformed, expired or have an invalid signature. If the tokens are valid, the next action in the sequence is executed. You can read the source code for the token validation action in Java or in Swift. You will notice that the tokens are also decoded and their decoded form injected in the output result. This gives the next action access to information such as the user id (subject), or the user name, email and picture.
Try it today
There is more to discover in this sample application. We encourage you to go through the tutorial. It will guide you to provision the services, deploy the serverless backend and run the mobile application. It is one of several other mobile and serverless tutorials you’ll find in the IBM Cloud documentation.
The tutorials section has a feedback form on the side where you can comment on the content. If you have suggestions on the existing tutorials or ideas for future additions, please submit your feedback.