hongsudt
commented
12 years ago I am not sure we want to move to oauth2 though.. We talked about it briefly yesterday and I think Josh wants to stick to oauth1 which I agree...
On Thu, Aug 16, 2012 at 3:28 PM, Faisal notifications@github.com wrote:
(As a foreword, I'm considering developing this myself, but would like to document it someplace/get input about it, which is why I'm posting it here.)
Overview I think it would be useful to formalize data release through ohmage under the OAuth2 spec, which allows a user to grant permission to a third party to access their data without granting the third party their actual credentials. OAuth2-authorized requests would be a third method of authenticating requests to the existing API, joining the existing token-based and hashed-password based authentication methods.
In order to support OAuth2, the front-end must serve up a page with at least an "Accept" button, which I'll refer to as the "ohmage authorization request page". This page should ideally brief the user on what data they're going to be releasing (or better yet allow them to configure that), how long it's going to be released, and which party is performing the request.
Flow Overview
- (Pre-step) the third-party application applies for and receives an API key, which they'll use to identify themselves when making requests to release user data from ohmage.
- User visits third-party site, which prompts the user to connect to ohmage to release their data
- Upon choosing to release their data (generally by clicking a button/link), the user is redirected to the ohmage authorization request page, passing along the API key that the third-party site registered with ohmage when they requested access to use the API.
- User reviews what they're releasing/chooses what they're releasing and for how long the authorization will last.
- Upon clicking "Agree", user is redirected back to the original third-party page with an access token that allows the third-party app to access their data under the terms.
- The third-party application accesses the data under the contract established when the token was created.
- (Post-post step) Once the token expires, is potentially revoked, or if a resource is requested that was not authorized, ohmage returns an authentication error, which may prompt the third-party application to re-request authorization.
The actual process is slightly more complicated -- there's a pre-step to authorization where the application first requests permission to even request authorization, which may be denied if the application's API key is no longer valid.
Notes on Authorization Options I think it would be both useful and feasible for the user to be able to specify authorizations on a per-API-call basis. To simplify matters for the user, similar API calls could be grouped into sets (e.g. "My Location Information", "My Survey Data"), with the ability to drill down into the set to choose the individual calls. Additionally, the user should be able to specify the duration of the authorization, as well as list and deauthorize any access tokens they've previously authorized. Every option should be accompanied by a plain English description of what data will be released if it's chosen.
The calling application will be able to provide suggestions about what API calls it needs to function, but will be unable to require them -- if it fails to receive authorization for an API call it needs, it will have to re-request it.
Changes to ohmage to Support the Above
- As mentioned previously, the front-end must host an authorization page.
- The front-end should ideally host a page listing authorizations for that user, with the option to modify (or at least revoke) those authorizations.
- The front-end should ideally host a page where third-party application makers can apply for and receive an API key. This could also be handled through some channel (email, for instance.)
- The ohmage server must include a new table containing API keys and their associated third-party application.
- The ohmage server must include a new table containing existing access tokens for ohmage users, the terms of their use, and the duration before which they expire.
- The ohmage server must provide API calls accessible by only the front-end for adding a new authorization, listing existing authorizations for a user, and modifying/removing an existing authorization.
- The ohmage server may optionally provide an API call for adding an API key to the API keys/applications table, but again these could be manually managed.
- Each ohmage call that's exposed via this data release mechanism must support OAuth2 access tokens and verify them against the access token database before releasing data.
Thanks, and let me know what you all think. :) I realize that it's ambitious, but I think it would go a long way toward allowing ohmage to be useful to users and third-party collaborators who are not approaching the system from the perspective of conducting research studies.
— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/395.
falquaddoomi
jshslsky
(As a foreword, I'm considering developing this myself, but would like to document it someplace/get input about it, which is why I'm posting it here.)
Overview I think it would be useful to formalize data release through ohmage under the OAuth2 spec, which allows a user to grant permission to a third party to access their data without granting the third party their actual credentials. OAuth2-authorized requests would be a third method of authenticating requests to the existing API, joining the existing token-based and hashed-password based authentication methods.
In order to support OAuth2, the front-end must serve up a page with at least an "Accept" button, which I'll refer to as the "ohmage authorization request page". This page should ideally brief the user on what data they're going to be releasing (or better yet allow them to configure that), how long it's going to be released, and which party is performing the request.
Flow Overview
The actual process is slightly more complicated -- there's a pre-step to authorization where the application first requests permission to even request authorization, which may be denied if the application's API key is no longer valid.
Notes on Authorization Options I think it would be both useful and feasible for the user to be able to specify authorizations on a per-API-call basis. To simplify matters for the user, similar API calls could be grouped into sets (e.g. "My Location Information", "My Survey Data"), with the ability to drill down into the set to choose the individual calls. Additionally, the user should be able to specify the duration of the authorization, as well as list and deauthorize any access tokens they've previously authorized. Every option should be accompanied by a plain English description of what data will be released if it's chosen.
The calling application will be able to provide suggestions about what API calls it needs to function, but will be unable to require them -- if it fails to receive authorization for an API call it needs, it will have to re-request it.
Changes to ohmage to Support the Above
Thanks, and let me know what you all think. :) I realize that it's ambitious, but I think it would go a long way toward allowing ohmage to be useful to users and third-party collaborators who are not approaching the system from the perspective of conducting research studies.