Usability and Security

Objective

The objective of this activity is to give you practice with developing a user interface where both usability and security are major concerns. You will need to iterate on your design to provide the most usable and intuitive interface, while also maintaining the security of the application.

OAuth: Background

OAuth is “an open protocol to allow secure authorization in a simple and standard method from web, mobile, and desktop applications”. OAuth is the industry standard protocol today for connecting two services. For example, a smartphone app that records sound on your phone and uploads it to Dropbox must be authorized to connect to your Dropbox account - and OAuth is the protocol that establishes that connection.

OAuth has a lot of transactions. A quick search on the Internet for a sequence diagram will show a LOT of different results. Not everyone gets their OAuth implementation correct - probably because of poor usability of OAuth APIs.

Activity

In this activity, you will play the role of a development team who created Cloudy, a simple storage service for files that works primarily through an API. You provide the ability to store files in the cloud in safe and reliable way. You want more people to use you, so you are providing an API for future developers to connect their app to your service. Thus, you are releasing your own set of libraries that are wrappers around OAuth to make it easier for client apps. You are also in touch with the Cloudy Web team so you can request enhancements to the web interface for managing API tokens.

Note Your users are other developers, however their users will also be interacting with your Web app so you really have two sets of users to think about.

  1. Find a group of 3-5 people to work with.
  2. Create a GoogleDoc and share it with your instructor and teaching assistant.
  3. Research the OAuth protocol. Be sure to study roles, tokens, and scopes. Know what each token does in the context of Cloudy. (Hint: Cloudy will own the servers that do Resource Owner, Authorization Server, and Resource Server.)
  4. Develop an API that abstracts away the complexities of OAuth for a “Client” (i.e. someone who is connecting their app to Cloudy).
  • The API will be a series of methods and parameters. Think of it like a Python library, or just a series of methods in any programming language. You can be language-agnostic in your syntax - this activity is about planning.
  • Provide internal docs for each method of what it does regarding OAuth. Think of this like a design spec for Cloudy developers who make this API. Use the language of OAuth like “resource owner” that references the spec.
  • Provide user docs for each method for Client app developers to be able to use. Do not use OAuth terminology, but instead choose useful terminology.
  • Document any enhancements you need from the Cloudy Web team.
  • Remember, OAuth allows us to establish connections so that users do not have to share their Cloudy password with anyone who wants to “Connect with Cloudy”. Thus, you should not have a method like login(user, password) as that would mean that users of the Cloudy library would have to disclose their password. Instead, you’re setting up an exchange of tokens, but simplifying the process for ease of use.
  1. Once you make your API, have a discussion with your team:
  • Is this a usable API? How can we improve it?
  • Can we simplify this API more?
  • Will this API satisfy the OAuth protocol? e.g. What happens if the Access Token gets leaked? What happens if the Authorization Grant credential gets leaked?

When you believe your API is usable and secure, notify your instructor and they will tell you what to do next.

Submission

Nothing is due beyond your participation. We reserve the right to ask questions about this activity on the exam, including basic questions about OAuth.