Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

This document describes a method of providing client applications the ability to authenticate to our APIs. These APIs are Web APIs; clients use simple HTTP requests and responses to send and receive data.

We use a client applciation application "username", a shared secret and a derived hash value to authenticate the requests, to determine which client application is talking to our API. The shared secret will be a string known to both the client application and the API back end. Typically, IS&T determines the value of the secret and communicates the value to the client application developer through a secure channel: a phone conversation, perhaps.

...

For example, let’s say the shared secret is “September”, the assigned user is "gravytrain",  and that the following data is being sent in the GET request:

Code Block
GET /esapis/v1.0/classlist?term=2015SP&subject=8.011



Before sending the request, the client will add a timestamp to the data in the request, so now the request will be something like:

...

Code Block
GET /esapis/v1.0/classlist?term=2015SP&subject=8.011&timestamp=20140715113137&user=gravytrain&hash=275607e4db71e75ba9a3d5e091efaf0f5e550cbbcf0a8a3b4502a960bdcebc85&user=gravytrain

When this request is received by the API backend, the API will use the same procedure to derive a SHA-256 hash value, using the data from the incoming request. If the API's derived hash matches the incoming hash, the request will be deemed to be valid. If not, the request will be rejected.

...