I am using oauth to authenticate dropbox and download a file from dropbox after getting access_token am using the below signature for download a file from dropbox am passing the root, path of the file, consumerKey and oauth_token with signature_method as PLAINTEXT and am getting an error
{"error": "Bad oauth_signature for oauth_signature_method 'PLAINTEXT'"}
Signature am using is given below :
https://api-content.dropbox.com/1/files?oauth_consumer_key=twcek2m7cxtantc&oauth_signature_method=PLAINTEXT&oauth_token=1jczc39y7rn1265&oauth_version=1.0&path=test%2Fut.txt&root=dropbox&oauth_signature=fbs34nykryouuj1%2526gbwmn3e27g97cfy
What should I do to resolve this error?
I was searching about this and found that:
1) The PLAINTEXT method does not provide any security protection and SHOULD only be used over a secure channel such as HTTPS. It does not use the Signature Base String.
2) The Service Provider declares support for the HMAC-SHA1 signature method for all requests, and PLAINTEXT only for secure (HTTPS) requests.
3) When used with PLAINTEXT signatures, the OAuth protocol makes no attempts to protect User credentials from eavesdroppers or man-in-the-middle attacks. The PLAINTEXT signature algorithm is only intended to be used in conjunction with a transport-layer security mechanism such as TLS or SSL which does provide such protection. If transport-layer protection is unavailable, the PLAINTEXT signature method should not be used.
You can refer this link http://oauth.net/core/1.0/#anchor22
You can also check if your keys are correct
The signature Protocol Parameters are set with the following values unencrypted:
oauth_signature_method : Set to PLAINTEXT.
oauth_signature : Set to the concatenated encoded value of the oauth_consumer_secret parameter and the value of the oauth_token_secret parameter. If the values contain a . character (ASCII code 46), it must be encoded as %2E. The values are separated by a . character (ASCII code 46), even if empty. The result MUST not be encoded again.
For example, if the Consumer Key is dj.9rj$0jd78jf88 and Token Secret is jjd999(j88ui.hs3, the encoded values are:
Consumer Key : dj%2E9rj%240jd78jf88
Token Secret : jjd999%28j88ui%2Ehs3
And the oauth_signature value is dj%2E9rj%240jd78jf88.jjd999%28j88ui%2Ehs3. This value is not encoded anymore and is used as it in the HTTP request. If the Token Secret is empty, the value is dj%2E9rj%240jd78jf88. (the separator . is retained).
Related
I am building a Web API for which the plan is to do OAuth Authentication using Azure AD. The API code is using Microsoft's Owin library and Identity.Web to validate the token once received in HTTP Request header. The challenge is that when I generate client secret from Azure AD and provide that in Web API code to validate received token, there is an error -
The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
Have tried generate client secret multiple times but all trial has resulted in invalid base64 secret. Is there a way to generate base64 compatible client secret from Azure AD because MS Own library needs it that way? Can Azure AD be used for OAuth authentication?
Thanking all in advance.
The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
The above error occurs that when your token is not a valid Base64 encoded string and also you should verify that the base64string length is a multiple of 4 and that it is valid.
In order to correct this, you may have to try to pad it and change - to + and to / as follows:
public static byte[] DecodeUrlBase64(string s)
{
s = s.Replace('-', '+').Replace('_', '/').PadRight(4*((s.Length+3)/4), '=');
return Convert.FromBase64String(s);
}
Your code required encodedbase64 format but token is decoded base64 this may cause the error so try the above code.
Reference:
c# - The input is not a valid Base-64 string as it contains a non-base 64 character - Stack Overflow
I am trying to follow the guide to generate Oauth authentication tokens for YAHOO DSP API.
Base64 encoding is a way of encoding binary data into text so that it can be easily transmitted across a network without error.
In this step, you will take the client ID and client secret that the YDN console generated for you and encode them using the base64 protocol. You can use an online encoding service like base64encode.org.
No matter which service you use, ensure that no spaces are appended to the CLIENT_ID and CLIENT_SECRET keys and separate the CLIENT_ID and CLIENT_SECRET with a colon, i.e. CLIENT_ID:CLIENT_SECRET.
The generated value will now be referenced as ENCODED(CLIENT_ID:CLIENT_SECRET) in this guide.
An example is given:
CLIENT_ID = dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
CLIENT_SECRET= a7e13ea3740b933496d88755ff341bfb824805a6
AUTHORIZATION = ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Using the recommended website I get the wrong AUTHORIZATION.
I have tried both encoding the whole thing at once ie. encode(CLIENT_ID:CLIENT_SECRET), and each element individually encode(CLIENT_ID):encode(CLIENT_SECRET).
Attempt encoding whole thing:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCTOiBhN2UxM2VhMzc0MGI5MzM0OTZkODg3NTVmZjM0MWJmYjgyNDgwNWE2
Attempt encoding each element:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCT:YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Expected result:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
The difference between 'each element' and the expected result is only a few characters corresponding to the end of client_ID and the colon.
B4oCT: should be BLS06.
Links to full documentation:
https://developer.yahoo.com/dsp/api/docs/authentication/tokens.html
https://developer.yahoo.com/dsp/api/docs/traffic/info/sandbox.html
Update:
The final character of Client_ID is '–' . This is some sort of non-standard character that is interpreted as two dashes i.e.'--' in utf-8 and windows 1258.
One different, TO NOTE is, that when you decrypt the expected output you will get your client id as
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA--
instead of
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
NOTE, there are two "-" at the end.
OAuth client auth token is always generated using Base64 encoding with following format
Base64_Encoding(CLIENT_ID:CLIENT_SECRET)
Most of the usage perform this Base64 encoding with encoding type as "UTF-8".
It looks like, Yahoo requires this token with different encoding. On "https://www.base64encode.org/" if you try to encode your "CLIENT_ID:CLIENT_SECRET" with "Windows-1254" as destination charset, you will receive the expected result. So, it looks like both encoding and decoding here is done keeping "Windows-1254" charset in place.
How to work with Dwolla API which required Client_id & Client_Secret
https://www.dwolla.com/oauth/rest/users/{account_identifier}?client_id={client_id}&client_secret={client_secret}
I already register Application. And Got Key and Secret
But when I call above described API Endpoint via Fiddler. Got bellow response.
{"Success":false,"Message":"Invalid application credentials.","Response":null}
Note: I tested Client_id = API Key / Client_id = Application Key. But the response remain same. What is the problem ?
The client_id is just another name for the API/Application Key, which identifies your application. The client/application secret is a string that functions as a password for your application. Just like a password, you should never give out your application secret; and if it's ever compromised, let us know immediately and we'll generate a new key/secret pair for you.
About your failed request: Try encoding your application key and secret. If special characters aren't escaped from the URL, the request will be interpreted differently from what you intend.
You can quickly encode the two strings from your Javascript console:
var key = "EUFH378&36%394749D\DWIHD";
encodeURIComponent(key);
Result: "EUFH378%2636%25394749DDWIHD"
var secret = "WOIDJ38&IDI\DK389DDDDD";
encodeURIComponent(secret);
Result: "WOIDJ38%26IDIDK389DDDDD"
And place their encoded equivalents back into your request URL:
https://www.dwolla.com/oauth/rest/users/gordon#dwolla.com?client_id=EUFH378%2636%25394749DDWIHD&client_secret=WOIDJ38%26IDIDK389DDDDD
I've a problem when trying to do a webrequest to UGC and authenticate using oAuth. I'm making a webrequest such as:-
WebRequest wr = WebRequest.Create("http://ugc.service/odata.svc/Ratings(Id=200)");
wr.Headers["authorization"] = "OAuth " + auth;
Where auth is my token returned from the access_token.svc. According to the documentation the token returned from the service should be something like:-
HufXeuUt%2FYYElA8SYjJOkUkrXxV9dyXRirmKhjW%2Fb%2FU%3D
However, what I'm being returned from access_token.svc is more like:-
{"access_token":"client_id%3dtestuser%26expiresOn%3d1361898714646%26digest%3d%2fW%2fvyhQneZHrm1aGhwOlgLtA9xGWd77hkxWbjmindtM%3d","expires_in":300}
I've parsed the JSON to extract various strings and attempted to pass these through to the authorization but whatever I try I get an error in the logs - "ERROR OAuth2AccessToken - Digest is wrong." Exactly what part of the token and in what format should I be passing through to authorization?
Many thanks
John
Like you mentioned, the protocol is this:
You make a post request to the access token end-point to get a token (you need to provide here your client_id and your client_secret as headers or as query parameters);
You get an answer similar to this: {"access_token":"sometoken","expires_in":300};
2.1 Worth knowing is that the token is url encoded and in UTF-8 format so, on Java side you need to do URLDecoder.decode("sometoken", "UTF-8"); while on .NET side you need to do HttpUtility.UrlDecode("sometoken", System.Text.Encoding.UTF8);;
Your next request needs to include the authorization header. On Java side you do builder.header("authorization", "OAuth " + decodedTokenString); while on .NET side you can use Client.Headers["authorization"] = "OAuth " + DecodedTokenString;
Worth mentioning is that the SharedSecret defined in the cd_webservice_conf.xml (/Configuration/AuthenticationServer/SharedSecret/) of the TokenAccessPoint needs to be the same as the SharedSecret defined in the cd_ambient_conf.xml (/Configuration/Security/SharedSecret/) of the (WebService)EndPoint.
Are you sure you decoded properly the token gotten from the server? Are you sure that you configured the proper SharedSecret in the two configuration files?
Hope this helps.
The HMAC-SHA1 signature method requires a key formed with the concatenation of the client shared secret, '&' and the token shared secret.
I wonder which value should I use for the token shared secret when the client still does not have the request or access token: the client shared-secret again or leave it empty.
From the specification:
3.4.2. HMAC-SHA1
The "HMAC-SHA1" signature method uses the HMAC-SHA1 signature
algorithm as defined in [RFC2104]:
digest = HMAC-SHA1 (key, text)
The HMAC-SHA1 function variables are used in following way:
text is set to the value of the signature base string from
Section 3.4.1.1.
key is set to the concatenated values of:
1. The client shared-secret, after being encoded
(Section 3.6).
2. An "&" character (ASCII code 38), which MUST be included
even when either secret is empty.
3. The token shared-secret, after being encoded
(Section 3.6).
digest is used to set the value of the "oauth_signature" protocol
parameter, after the result octet string is base64-encoded
per [RFC2045], Section 6.8.
Thanks
The key should be set to the client shared-secret plus the "&" character when the token shared-secret is unavailable.