That is similar to what we are doing at TweetPhoto and it is working
Feel free to check out what we are doing:
Third-party apps share with us their app's consumer key and secret.
We receive the same level of access to the third-party app using our
photo sharing service.
When two companies work together and are partners there needs to be a
level of trust.
Furthermore, developers can change their consumer secret at any time
so their is no real issue with this method.
There are a few integrations coming out soon with this method in
Please let us know your thoughts and if you have any questions.
On Feb 11, 10:05 am, Brian Smith <br...@briansmith.org> wrote:
> Raffi Krikorian wrote:
> > The term most frequently used for “delegator” is “relying party.”
> > What you call the service provider is most frequently called the
> > “identity provider.” What you call the consumer is usually called
> > the “subject.” See OpenID, InfoCard, and other similar
> > specifications for example usage of these terms.
> First, what I wrote about "subject" was misleading: the user--not the
> consumer--is the subject.
> > i hear all this - it just gets a bit complicated with because we are
> > conflating this with our oauth situation.
> This doesn't really have much to do with OAuth, because you are not
> trying to allow delegation of credentials--that is, you are not trying
> to allow the "consumer" app to let the relying party use the consumer
> app's OAuth access token to read/write the user's account.> perhaps its time
> to move to an oauth + openID hybrid system.
> I don't know if OpenID really solves this problem well, especially for
> apps that aren't webapps.
> > The subject doesn’t want the relying party to have access to the
> > entire response from the account/verify_credentials request as if
> > he had given the relying party read access to his account. I am
> > not sure if account/verify_credentials returns sensitive
> > information (information only available to apps that have been
> > authorized by the user) yet, but I think it is likely in the
> > future that it will do so. It would be prudent to have delegation
> > use a different resource designed specifically for delegation.
> > i think this is again a general case vs a twitter case. i think in
> > the general case, the delegator would call some endpoint that would
> > simply verify the identity through a HTTP code (2xx for success, 4xx
> > for failure). twitter, as a special case, sends along the user object
> > [as] part of it?
> account/verify_credentials discloses information that is private. For
> example, the HTTP header of account_verify_credentials discloses
> information about how frequently the user accesses twitter (the rate
> limit headers). If the user hasn't previously authorized (via OAuth) the
> delegator (relying party) to have read access to his account, then the
> delegator (relying party) shouldn't be able to get this information.
> Also, I think you should plan ahead for the case where
> account/verify_credentials returns even more sensitive information. If
> you were going to reuse an existing resource, I'd reuse
> users/show.format?user_id=<username> instead. But, AFAICT, it's much
> better to create a new resource for this purpose, and pretty easy to do so.
> I think the following would be a better protocol:
> Consumer to Relying Party: Give me <RP-SIGNED-TOKEN>, a nonce signed
> with your OAuth credentials for the relying party'sidentity verification
> service. Relying Party to Consumer: Here is the token <RP-SIGNED-TOKEN>.
> (This is done using whatever protocol the consumer and the relying party
> agree to use.)
> Consumer to Identity Provider: Here's <RP-SIGNED-TOKEN>. Give me
> <IP-SIGNED-TOKEN>, which is (<RP-SIGNED-TOKEN>, screen_name) signed with
> a signature that the relying party can verify is from the identity
> provider. Identity Provider to Consumer: I verified that the token was
> signed by the relying party identified by <RP_ID>. Here is
> <IP-RP-SIGNED-TOKEN>. (This is an OAuth-protected transaction using the
> consumer's credentials).
> Consumer to Relying Party: Here is <IP-RP-SIGNED-TOKEN>.Relying Party to
> Consumer: OK, let's continue on with whatever we need to do. (This is
> done using whatever protocol the consumer and the relying party want to
> Notice in particular: (a) each server only has to process one request,
> (b) the relying part and the identity provider never have to communicate
> directly with each other, (c) the consumer (user) can control the level
> of security used in all the communication (e.g. TLS for everything), (d)
> IP-RP-SIGNED-TOKEN> can be used as the assertion in the OAuth 2.0/WRAP
> assertion profile, if the relying party is using OAuth WRAP to
> authenticate the user, (e) the user and the identity provider can both
> restrict which consumers can sign into which relying parties for which
> users using this mechanism.