Brivo Labs - OAuth Server Provider

Project Overview

BrivoLabs has a beta version of a node.js/coffeescript application that is called Social Access Management (SAM) API. It uses postgres database, runs on heroku, consists of both a web and a worker process, and uses a redis-based message queue to communicate between them.

The next step of building the API is exposing it to developers, in order to achieve that we need to manage developers access to the API. The first step is to build OAuth 2.0 Sever provider with basic API management functionality, in the future we will integrate with Mashery API Management to issue developer keys.

The goal of this contest is to implement Coffeescript OAuth 2.0 server provider that uses 3rd party identity providers to authenticate users.

Task Requirements

OAuth Server Module

The OAuth Server should run as standalone application and will be used as a Passport starategy for authorizing api calls in SAM API.

Workflow

General Workflow Overview :

• When request comes, the application will route the request to the corresponding controller functions according to the routing definition.
• Controller functions handle the request, and delegate the model manipulation logic (like CRUD) using ORM module.
• The ORM module will communicate to the database to perform the tasks.
• Return the response to the caller

Specific notes about the workflow :

• The server should use
• Identity Provider is handled by 3rd Party Providers, in this version a Login controller is requied to support authentication with Google, and Salesforce.com. Passport and concrete strategy modules should be used for working with those external providers. For Salesforce.com SessionID authentication, nforce module or any salesforce.com authentication module can be used to verify user is logged in.
• OAuth2 Server controller is needed to implement the core OAuth2 server using oauth2orize module (This module is recommended by Passport, you can use any other module that implement the requirements), the controller should define and use proper Models for accessing OAuth2 authorization codes, access tokens and clients information persisted in DB.
• DomainID must be passed when exchanging/validating user Access Token. Please refer to existing Salesforce.com authorization logic in SAM API (salesforce-controller) for more information how domainID is used during authorizing the user.
• Move OAuth token from SAM API model (DomainAccount) to a new entity model defined as part of this OAuth Server Module. We also need models for OAuth 2.0 Client, and OAuth 2.0 Grant access codes.

Authorization Grants

The OAuth 2.0 server should address the below Authorization Grants :

• Authorization Code
  • SAM API should use Salesforce.com and Google+ as Identity Provider. We don't have registration logic, the OAuth flow should create new user if the user does not exist in the system.
  • Use cases for this grant type :
    • Web application
      Consider a web application ("app") that stores and graphs events associated with a "beacon" device in a building.  A user grants access to this app to poll SAM nightly.  During initial setup, the user is asked to authenticate to SAM to grant OAuth access.  The app provides two options: "sign in with google" or "sign in with salesforce".  The user chooses google, and is presented with a google login screen.  They enter their correct credentials, and are then asked to grant "basic" access to SAM so that SAM can validate their google identity.  Now the user is authenticated to SAM, and she is then asked to grant access to SAM to our app.  This latter access will have some scope that allows querying event data.  SAM now issues access and refresh tokens to our app, and the app can now submit requests to SAM on the user's behalf.
    • Mobile application
      Consider a mobile app ("app") that allows users to open their office's parking garage.  When the application first starts, it asks the user to authenticate to SAM using either google or salesforce.  The user chooses salesforce, and is presented with a salesforce login screen.  They enter their correct credentials, and are then asked to grant "basic" access to SAM so that SAM can validate their salesforce identity.  Now the user is authenticated to SAM, and she is then asked to grant access to SAM to this mobile app.  This latter access will have some scope that allows creation of events.  SAM now issues an access token to our app, and the app can now submit requests to SAM.
• Extended Credentials Grant
  • We are not sure if the use case we have here fall exactly under this grant type, we need your thoughts about the best approach to address it, here is the use case :
    • Brivo Labs has a salesforce applications, these apps make direct calls to Salesforce.com API so the user of the apps will need to login to salesforce.com.
    • After successful login to these apps, the apps obtain session ID and can execute calls to Salesforce.com API.
    • We want to use Session ID Authorization in order to give these apps access to SAM API without asking users to grant them permission to do that, click here for a cURL example, the OAuth server should use the session ID to authenticate user, if user is valid then OAuth sends back a valid access token.
  • Please note the authorization via Session ID already exist in SAM API (refer to salesforce controller), you will need to move that code from there to OAuth server.

General Notes

• OAuth 2.0 Client Controller is required to be implemented with all CRUD operations to manage Client application's API keys.
• The architecture should be flexible to allow adding more identity providers in future.
• The authorization UI pages should be simple page with no design/look-and-feel.
• Basic documentation of the code is required.
• Configuration structure should follow SAM API application.
• Validation must be implemented in all operations.
• Consist/Unified error handling should be implemented.
• Naming of all files should use camelCase naming convention.
• This module should update SAM API so that it will always verify if the API requests from Clients are properly authorized by end user. Passport and concrete strategy modules are used for working with OAuth2 authentication.
• Update Postman with the new OAuth 2.0 api calls.
• Cleanup SAM API by removing the existing Authorization flow that will be replaced by this OAuth server.
• Please use same node.js modules dependencies used by SAM API as much as possible. i.e. same ORM module to interact with DB.
• The OAuth server application should still run within the same attached SAM application but with different end point, and it should run on Heruko.

Final Submission Guidelines