Archived | Develop protected serverless web applications

Archived content

Archive date: 2020-05-28

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.


IBM Cloud Functions, based on Apache OpenWhisk, is a Function-as-a-Service (FaaS) platform, which executes functions in response to incoming events and costs nothing when not in use. It kicks up when the code is run, and it goes away when not needed. In this developer code pattern, we demonstrate how to utilize IBM Cloud Functions with OAuth 2.0 to enable the authentication and authorization in a web app.


Web apps need authentication and authorization. This seems redundant, yet for so many years, there has been no reusable solution. OAuth definitely took a big step forward by introducing third-party authentication and authorization. Still, authentication and authorization takes up a lot of deployment packaging and hosting resources, considering users only log in once for a relatively long time.

In this code pattern, we have a web app written in Angular. We will set up the Google OAuth API so users can log in to their Google accounts via OAuth. Of course, in the web app, the code already exists to invoke IBM Cloud Functions. We still need to define the actions via the IBM CLI. After we wire everything up, we can see how the login process invokes the IBM Cloud Functions action to fire the OAuth request to the Google API and return the token to the Angular web app. Note that the web app doesn’t have to be hosted in a specific environment; it just needs to reach the serverless APIs.



  1. User opens Angular via web browser and clicks login.
  2. Angular app opens Google OAuth web page, where users authenticate and grant application access.
  3. Google page redirects to OpenWhisk sequence oauth-login-and-redirect with a code parameter in the URL.
  4. The sequence is triggered. The first OpenWhisk function oauth-login reads the code and invokes a Google API endpoint to exchange the code against a token.
  5. The same oauth-login function invokes with the token another Google API endpoint to read user profile information, such as the user name.
  6. The sequence invokes the next OpenWhisk function redirect, which invokes the Angular app with the token and the user name in the URL.
  7. When users click on invoke protected action in the Angular app, a REST API to the API management is invoked. The request contains the token.
  8. API management validates the token. If valid, the OpenWhisk function protected-action is invoked.
  9. The response from protected-action is displayed in the Angular app.


Ready to put this code pattern to use? Complete details on how to get started running and using this application are in the README.