Welcome back to the Code-Monkey Corner! Put on your engineering hats and get ready for our latest installment of engineering exploits from two of our very own hard-working Monkeys, Chandra and Tuyen. They’re here to share how the Engineering team is continuing to improve the panelist experience for one of the members of our extended Monkey family–ZoomPanel.
ZoomPanel is made up of a community of consumers who share their opinions and insights about companies’ products and services by participating in market research studies. What does this mean for all you SurveyMonkey creators out there? Once you’ve finished making your survey and are ready to send it out into the world, you can send your surveys to the panelists who best fit your target audience in order to collect the most meaningful feedback for whatever your survey needs may be.
That’s just a taste of what you see front and center with ZoomPanel but behind-the-scenes, our Engineering Monkeys are hard at work at making all of this possible. Now, get ready for the “high-tech” talk, folks!
ZoomPanel communicates with third parties using a variety of APIs. Access to these APIs are managed primarily through a home-brew internal authentication, but we’re currently re-architecting key portions of our infrastructure. Why? For a snazzier panelist experience, performance that packs even more punch, better business flexibility and for a hassle-free maintenance experience. Our Engineering primates have decided to investigate industry-standard authentication solutions in order to get ‘er done and have decided on Open Authentication 2.0 (Open Auth) as their solution.
Here to break it down for us are Chandra and Tuyen!
We’re excited to be sharing with all of you our OAuth story and why we’ve decided to go with version 2.0 to make the ZoomPanel experience even more awesome for panelists! But first, some background might be helpful so we’ll start off talking a little bit about OAuth 1.0. Here we go and don’t forget to let us know if you have any questions in our Comments section below.
OAuth 1.0 has been in wide usage for a number of years though setup and administration of it, on both the service and the client side, can be pretty tricky and time-consuming as you can see. Check it out:
Clients and services need to exchange a client identifier, a client “token secret”, temporary credentials with specify a client key, specify the signature method (encryption protocol), the signature value, a callback URL, and a “nonce” which is a client-generated random string that must be uniquely generated for each request (allowing the service to verify the uniqueness of a request and prevent “replay attacks”) along with a timestamp that marks when the transaction takes place (the number of seconds since January 1, 1970, at midnight).
The client is then redirected to a request website where he or she must sign in using a login and password to grant the service authorization, and when confirmation is sent to the service, it finally requests a set of token credentials which are validated and then allows the service to access data. Many steps, many points of validations, but much security.
OAuth 2.0, while still not completely specified, was developed to simplify implementation by simplifying the authentication process, as well as to support alternative user flows. Some additional differences? Take a look:
- The elimination of the requirement for client credentials after the first token is obtained, allowing tokens to be unbounded from a particular instance or client type (and forcing supplemental security measures).
- A reliance upon bearer tokens, pushing security into the network transport layer.
- A forcing of token refresh.
- Supports a variety of user workflows based on the idea of “grants”, or an end-user approval that can take the place of a token.
OAuth 2.0 has been adopted by Facebook and is supported by Microsoft and Google, but is incomplete and has had some controversy attached to it in the engineering world because of both its incompleteness and because it places a greater onus for handling security on the implementor. But as these companies have shown, this is manageable!
Our implementation will follow Facebook’s server-side model, but once the authorization token is granted, the source of the final access request will be verified at the network level to ensure that this authorization token has not been shared or sent to an unauthorized user, a misuse of the bearer token.
Take a look at the case chart below for a visual on the whole workflow. Here, a ZoomPanel panelist is taking a survey on an external survey platform and is being redirected back to ZoomPanel at survey’s end, which in turns communicates with an incentive service that maintains reward information:
While client data, as in 1.0, must be passed to the API in order for the authorization token to be obtained, the additional client login step is eliminated, and the authorization token can server itself can serve as a passport, albeit a short-lived one. When it expires, a new access token must be obtained using a separate refresh token.
In developing our implementation of OAuth, we decided to go with the library found here because as compared to other implementations we found, the code is small and easy to follow, and allows us to tweak as needed. Also of major importance–it also abstracts the DB layer allowing us to database flexibility, if needed.
With secondary validation on the user authentication token, a security-savvy organization can gain the benefits of OAuth 2.0 without sacrifice, and use it as a foundation for maintaining login security as mobile and additional browser-based application are added over time.
As we work with internal and external security experts we may change certain parts of this workflow in response to potential intrusions. We’re very confident that the OAuth 2.0 approach will give us a solid basis for growth, and will ensure that both the internal and external applications that connect to us will be able to do so hassle-free and who doesn’t love that?
Questions, comments? Don’t be shy, let us know!