tmhOAuth PHP library as OAuth Echo Delegate?

[sterling]

I’m trying to figure out how to set up my web app as an OAuth Echo delegator. I am using tmhOAuth. Right now my client sends information to my web app and my web app should send those auth headers on to Twitter to verify the user. The headers do not seem to be making it to Twitter intact though. The code has examples but those example are all showing how to send information to a delegator like Posterous or Twitpic, not how to act as one.

Thanks.

[episod]

I don’t have a PHP example for you, but this small demo of a Ruby-based mock OAuth Echo provider might have some hints for you: https://github.com/episod/mock-oauth-echo-image-host

https://github.com/episod/mock-oauth-echo-image-host/blob/master/app/controllers/api_controller.rb contains the most important bit. Happy to answer any questions you may have.

[sterling]

Thanks. Pretty sure I understand how it is supposed to work but I think my problem may be the tmhOAuth library (https://github.com/themattharris/tmhOAuth/) just does not support OAuth echo. I’ll have to find a different way.

[episod]

When performing an OAuth Echo request, you’re going to want to perform a vanilla HTTP client request rather than having your echo’d request sent through an OAuth library. All the OAuth has already been done for you – you just need to take the values you receive (after programmatically deciding if it’s a request you’ll honor – for instance, you wouldn’t just blindly want to send such requests to any arbitrary host) in an inbound request and re-package them as a basic HTTP request to the third party (Twitter in this case).

[sterling]

How do I figure out the client’s identity? I need to take what they sent me and verify that with Twitter somehow.

[episod]

Identifying the client making the request is a bit out of scope of OAuth Echo itself – your own service is responsible for identifying the clients calling to it – you might use OAuth or OAuth2 or just a simple API key system. I don’t recommend no system at all, but potentially you could just implicitly “trust” valid requests to your endpoints as well.

I’ll walk through the request cycle:

1. You receive an OAuth Echo request on the endpoint you’ve asked developers to use for this purpose. You’re going to give them something back and the end of this process – probably a URL pointing to some kind of content, but potentially also a HTTP code indicating you couldn’t verify the auth.

2. The request you get may have an API key or identifier in however you’ve pre-arranged with the implementor. You can gate on that if you like, but the next thing to gate on is whether the request is syntactically correct – does it have a X-Auth-Service-Provider HTTP header and a X-Verify-Credentials-Authorization HTTP header?

3. If it has these headers, you’re going to consume them. I would first consume the X-Auth-Service-Provider header and analyze the URL you’ve been given – is it a service you trust for identity? If you only want to support Twitter – make sure it points at twitter.com – ideally to https://api.twitter.com/1/account/verify_credentials.json or .xml. If it matches, you’re going to use this URL exactly as it is in your next request – don’t modify its parameters or destination. Consume the X-Verify-Credentials-Authorization header. Store this in a string, this is what you’re going to set as the HTTP Authorization header in the next step.

4. Prepare a request using your HTTP library to open the URL from step 3 using the Authorization header also from that step. If you get a 200 OK back, the user is good and you can trust the response back. If you get a 401 the OAuth is bad in some way, including the possibility that the user hasn’t auth’d the remote app in question. Anything non-200 is something you won’t gatekeep for. You might want to provide more informational errors of your own here, but that’s up to you.

Hope this helps!