Preapproved request tokens should be supported by the OAuth server to facilitate OAuth calls from the consumer to the provider which do not need the users approval. This means that the consumers API can only be used to store user-specific data that is provides by the consumer itself.
Examples in which case 2-legged OAuth can/should be used:

  • A gadget invokes a reporting API, which returns data that is in no way user-specific
  • A gadget uses a remote file service API to store personal user documents. These documents are stored in a specific consumer space such that no other consumers can access it.

Example in which case 2-legged OAuth should NOT be used:

  • A gadget stores photos in an Album service API. The photos are stored per user and the username is send along with the request from the gadget container. This should not use 2-legged OAuth since the photos can also be accessed from other consumers.

From these examples it is clear that the Service API determines if 2-legged OAuth and/or 3-legged OAuth is required. The Service API should this be capable of retrieving this info from the acquired token. So:

  • The request token servlet should be enhanced with an additional 'preapproved=true' parameter to request a preapproved request token
  • The 'is pre-approved token' becomes a property of the token, which can be retrieved by the Service API being invoked with OAuth
  • Pre-approved access tokens never contain a user id
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers

Reply via email to