OAuth 1.0 Failure to Authenticate

[#1]

Hi,

I have apigee calling a target which has OAuth 1.0 as security. We have exchanged keys and tokens. I have a script (obtained from here: https://github.com/ddo/oauth-1.0a) in apigee which runs, and generates the signature, nonce and timestamp, then creates the correct header. The target responds with invalid login.

I have tried a different script (obtained from here: https://github.com/jrconlin/oauthsimple), but the same problem occurs.

I have tried making the same call through Postman (with the same credentials), and it works. The team on the target server have tried calling themselves with oauth using the same script (https://github.com/ddo/oauth-1.0a), and it works.

There seems to be a problem in apigee that I cannot see. Here's a sample header I'm providing from apigee for reference (though I'm sure it is okay because the structure is the same as from Postman):

OAuth realm="****",oauth_consumer_key="*****",oauth_token="****",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1466021105",oauth_nonce="bTgpA",oauth_version="1.0",oauth_signature="***"

Any suggestions as to what the problem may be?

Thank you for any help,

Aleks

[#2]

OAuth 1.0 signatures are notoriously finicky to generate. Check basic stuff first, are the verb, url, and parameters all the same when you look at what Apigee's signing vs what the target is receiving? If that all checks out, I'd try to force the nonce and timestamp in your script then run on Apigee and locally to compare the string-to-sign that gets generated. Usually it's a matter of going through that string with a very fine toothed comb to make sure that character escaping, parameter order, and everything that makes up the string-to-sign is exactly right. I would try to put the string-to-sign into a variable, trace it then do the same thing locally and compare.

[DChiesa]

Chris is right - problems with OAuth1.0a signatures are really tricky to diagnose. are you certain you're hitting the right target URL? One of the surprises you can get is ..Edge applies the pathsuffix to the path you supply in the target URL. This is documented, but still, it surprises some people. That would cause the signature to be rejected at the receiver.

Also, how are you sending the requet from Edge? You said "the target responds with 'invalid login' ". Are you using ServiceCallout? JS with HTTP Client? A regular HTTP Target?

[#4]

I know I'm hitting the right target url (I can see it in trace) but I'm also able to successfully make calls to the target through an alternative form of security (not OAuth1.0). So the issue appears to be only my OAuth. Also, interestingly, if I pass the wrong key and token the target replies with invalid schema. It looks then that the error I'm getting in my original post is not from an invalid key/token.

Its difficult to see what the target sees, since as far as they have told me, they do not have visibility into what is coming in.

Its just a regular HTTP target endpoint.

[DChiesa]

Hi Aleks

I'm sorry you're still having trouble. I asked you several questions, and you did not respond to those. I'm trying to help, but to be most helpful, I'll need the information I specifically asked about.

> If I pass the wrong key and token the target replies with invalid schema.

Is that expected? Wouldn't you expect a 401 Unauthorized?

-----

The good news is:

• you have several working examples.
• you have contact with the team who owns the server.

The latter fact, especially, bodes well for you. You should be able to ask them to provide information to you about exactly where the rejection is occurring. In OAuth1.0a, it can be at one of many points: key validation, algorithm rejection, SHA mismatch, invalid token, nonce rejection.... And often the only information you have is "401 Unauthorized". But if you know the server team, you can ask them to provide additional diagnostics about when and where in the process your OAuth1.0a token is being rejected.

Good luck!

[#6]

Hi Dino,

I'm not sure which questions you have asked that I have not answered.

As far as I can tell you asked:

1. are you certain you're hitting the right target URL?

My Reply: I know I'm hitting the right target url (I can see it in trace) but I'm also able to successfully make calls to the target through an alternative form of security (not OAuth1.0).

2. Also, how are you sending the requet from Edge? Are you using ServiceCallout? JS with HTTP Client? A regular HTTP Target?

My Reply: Its just a regular HTTP target endpoint.

I only noticed two questions.

Sorry, by invalid schema the response means invalid authorization schema (as in the authorization header was invalid). It should be a 401, their system is just not properly documented yet. When I send the valid token and key, it gives a 401, which may imply that it passed validation of the header schema and token/key validation. Just thought it might be useful to narrow down the problem.

We are quite sure that our oauth header string is valid. We have seen it in trace, and in the other system. We have ensured escaping, parameter order, etc is what is expected. Though, there may be something we have missed, or cannot see.

We have a ticket open (for a few weeks now), for which we are getting almost no support. We're not quite sure what's going on with that.

We are trying to work with the other team, though it seems that the oatuh authorization functionality is pre-built into their system, and they have little access or grasp of its functions. We are working to resolve it with them, as this seems to be the only way to move forward.

Thanks,

Aleks

[DChiesa]

Yes, I see. Sorry I did not understand your responses.

We have a ticket open (for a few weeks now), for which we are getting almost no support. We're not quite sure what's going on with that.

Does this mean, you have a ticket open with Apigee Support? I don't think Apigee Support will be able to help you diagnose an OAuthv1.0a validation failure, when your code is producing the signature, and a third party is validating the signature. That's my understanding of the situation, please correct me if I am wrong about that. Apigee Edge doesn't really play much of a role, except an indirect one. You've commented "my code works outside of Apigee Edge", and that's clear enough, but... now it's up to you to figure out exactly what varies when your code is hosted within Apigee Edge. It could be anything!

It could be a timestamp, it could be the callback is invalid, it could be ... 12 other things. You haven't provided enough detail.

Are you running ddo in the JS callout or in nodejs? If nodejs then how does it compose with "a regular HTTP Target endpoint"? What's the signature base string? Are you sure it's right? How are you setting the header for the outbound request? (show code)

Is this a request-for-request-token? a request-for-access-token? Or ... are you using an access token you have already obtained from somewhere else in a signed request for service?

so many details. That's always a challenge with OAuthv1.0a.

Is the target service public? If you tell us which target it is, maybe somebody here can try connecting to it. If not, have you tried connecting to a public target service like Twitter (which I think is still oauthv1.0a) or bitbucket or ...? Maybe the problem you are having would surface itself there, too.

You have to go through everything methodically and just make sure it all lines up. It can be helpful to explain it to a third party (like me, here), in excruciating detail, because that forces you to go back to the very basics. Did you sort properly? Did you include spaces after the commas? Did you include query parameters? We can help you check those things, but in the end, the solution is in your hands.

You can try playing with this online tool to see if the results it generates line up with what you're producing in code. You can also try explaining everything in detail here. We'll try to be helpful, but... there's only so much we can do.