User Authentication

API calls that view non-public data, or modify data, are protected by OAuth 2.0.

Use the OAuth 2.0 Implicit Grant flow to request an authorization token, and supply this as a .

We recommend you get things working first with a local ABE instance, or on the development server.

Development

1. Redirect the user to /oauth/authorize, with the query parameters response_type=token, and redirect_uri. for example, http://abe.instance/ouath/authorize?response_type=token&redirect_uri=http://localhost:3000/oauth/callback. (The production instance also requires a client_id parameter.)
2. The user signs in and authorizes the app.
3. ABE redirects the user agent to the URL specified as the value of redirect_uri, with a hash that specifies the access token and a token type of bearer. For example, http://localhost:3000/oauth/callback#access_token=…&token_type=bearer. (The hash will contain additional parameters, so you need to extract the access token in a general way, for example using the regular expression [#&]access_token=([^&]+).)
4. Supply this token in subsequent API calls: Authorization: Bearer {access_token}.

ABE also tries to set a cookie, so you may not need to present the bearer token. This hasn't been fully tested with cross-origin applications.

Production

Ask the ABE development team to create an ABE App for you. You will need to supply a list of redirect URI prefixes. (For the example above, you could supply either http://localhost:3000/oauth/callback or just http://localhost:3000/.) You will receive a client id, for use in the /oauth/authorize call above.

Account Information

/user gives information about the currently-authorized user.