I'm working on my first DocuSign web service consumer, in the development environment. At this point, I'm just trying to duplicate the token request procedure on DocuSign's how-to page: https://developers.docusign.com/platform/auth/jwt/jwt-get-token/
I'm sticking as closely as possible to the process shown in their YouTube video. I have created an app with an integration key and an RSA key pair (generated by DocuSign). I obtained application consent as per step 1 of the how-to.
As per step 2 of the how-to page, I entered the following request in jwt.io:
Header: {"typ":"JWT","alg":"RS256"}
Payload: {"iss":"(integration key GUID)","sub":"(API username GUID)","iat":1619972504,"exp":1619975504,"aud":"account-d.docusign.com","scope":"signature"}
I pasted the public and private keys, including the starting and ending strings, into the appropriate fields, and jwt.io created and verified a signature.
As per step 3 and the YouTube video, in Postman, I created a POST request to https://account-d.docusign.com/oauth/token with
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=(encoded token copied from jwt.io)
No matter what I do, the web service always returns
{
"error": "invalid_grant",
"error_description": "unsupported_grant_type"
}
I've spent more time than I care to admit re-reading the how-to page, re-watching the YouTube video therein, and poring over my data for typos, etc.
Ideas, anyone? Thanks!
For part 2 you would also need the scope of "impersonation" for JWT.
Related
I'm pretty familiar with restAPIs, however this one is giving me a bit of a headache. I'm trying to migrate my OAuth 1.0 tokens into OAuth 2.0 tokens using this documentation https://developer.xero.com/documentation/oauth2/migrate.
The request:
POST https://api.xero.com/oauth/migrate
Content-Type: application/json
Authorization: OAuth oauth_consumer_key="your_consumer_key", oauth_token="your_access_token",
oauth_signature_method="RSA-SHA1", oauth_signature="your_signature", oauth_timestamp="1456175435",
oauth_nonce="83fd12eb-f578-4403-bd55-247b66efa11a", oauth_version="1.0"
Body: {
"scope":"your_oauth_2_scopes + offline_access",
"client_id":"your_app_client_id",
"client_secret":"your_app_client_secret"
}
I'm trying to write a script in GO that will make make the POST request, grab the data and update our database.
Now what I'm confused about is the Authorization Header.
How do I fill in the information required?
More specifically the oauth-signature, oauth-timestamp and oauth_nonce. I have little experience working with OAuth1.0a and would love to understand the flow.
Thanks!
Edit: trying to make use of this library https://godoc.org/github.com/gomodule/oauth1/oauth#example-Client-SetAuthorizationHeader
The OAuth1.0a signature is a set of key-value pairs, signed with your private key. This example migration app should give you an idea of the steps that need to be taken to build up the signature, even though it's not Go: OAuth1.0a => OAuth 2 token migration example.
There's also a Xero GoLang SDK that you can dig into to help with auth code: xerogolang
The nonce is a random single-use string that needs to be the same in your header and in the signature. The timestamp is the current date-time, in seconds since epoch, which also needs to be the same in your header and in the signature.
I'm following step by step guide on Microsoft's site (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#refresh-the-access-token), everything is working correctly but every time I try to refresh the access token, I get this error: AADSTS70000: Provided grant is invalid or malformed. error_codes: 70000.
I've created a Postman collection for testing, also downloaded the official postman collection from the Microsoft's site, everything is working correctly until the access token does not expire. When it expire, trying to refresh the token always lead to an error and I'm pretty stuck with it. I've double and triple checked correspondence between redirect_url, permission, grant, copy/paste errors, waited for the access_token to expire before trying to refresh... I've done almost 100 tests, and every time I'm stuck at the refresh part!
I start with doing the normal call to Microsoft Login API in my browser, and getting the code in query string from the browser (no problems here) (please note that client_id is URL encoded because, in my test environment, client id is an URL due to the configuration of the Drupal portan we're using, I'm truing to recreate the same behaviour in postman)
https://login.microsoftonline.com/{tenant_guid}/oauth2/v2.0/authorize?client_id={myclient_id_urlencoded}&response_type=code&redirect_uri={redirect_uri_urlencoded}&scope=offline_access%20https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&state=12345
Then with the code in query string, i POST to the token endpoint:
POST /{tenant_guid}/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-url-form-urlencoded
cache-control: no-cache
Postman-Token: a0456a8d-6979-491f-b61e-86b5d614c577
client_id={myclient_id_urlencoded}
scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
redirect_uri={redirect_uri_urlencoded}
grant_type=authorization_code
client_secret={client_secret_urlencoded}
code=OAQABAAIAAADCoMpjJXrxTq9VG9te-7FXujKZhF...
I receive back an accesso token (that is working like a charm in accessing https://graph.microsoft.com/v1.0/me for an hour) and a refresh token. I would love to get a new pair of access/refresh token when the original access token expires, using the refresh_token grant_type
POST /tenant_guid/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-url-form-urlencoded
cache-control: no-cache
Postman-Token: 5d71f813-768e-476c-a97f-c109fba3165e
client_id={myclient_id_urlencoded}
scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read
redirect_uri={redirect_uri_urlencoded}
grant_type=refresh_token
cclient_secret={client_secret_urlencoded}
refresh_token=OAQABAAAAAADCoMpjJXrxTq9VG9te-7FX8m6YMg-.....
But no matter if I try before access token expiration or after, closing and reopening postman, I always receive that error back. I've done almost 50 tests (always with the full round of login/authorization to use always a fresh refresh token) with no luck.
Seems like I'm missing something really stupid here because I can't imagine that everybody else is behaving correctly... but really can't find a way out!
So I just got mine working! Here are the required parameters I needed:
client_id = your client id
refresh_token = the refresh token here
grant_type = refresh_token,
client_secret = secret
NOTE: Everything I read told me to URLEncode the values. I found it worked with them UNENCODED - no idea if it will really make a difference or not. Since it is going in the body of the post, which means it is TLS encrypted.
The other important thing was the url I posted to. There seem to be so many examples and none seem to be consistent. I used this format:
https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
The last thing is to be sure you are using the correct app id. In my case I was using the appId for the wrong app and it didnt have consent. Hope this helps. I do wish Microsoft would make a concerted effort to spell out things consistently and think like someone who doesn't do security for a living.
Finally resolved thanks yo the Azure Support.
The problem is the client id: as I supposed before, Microsoft allow you to define another application name, but always want to use the GUID client id to submit any request. Unfortunately, it was warning me when I didn't url-encoded it, but did not alert me that it was not correct until I tried to use the refresh token.
So just read very very well the documentation: client_id: The Application (client) ID that the Azure portal – App registrations experience assigned to your app (so not the one you choose).
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Maybe including a format validation in the documentation would help!
I have attempted to use the provided test data from the Cybersource documentation to create a token for a test PAN. However, when attempting to do so (assuming it was a REST Api) it results in a "403 - Forbidden" error. The documentation is limited, as it doesn't give much information on the API other than the following:
(Test) Endpoint: https://testsecureacceptance.cybersource.com/silent/token/create
Request to create a standalone payment token:
reference_number=123456789
transaction_type=create_payment_token
currency=usd
amount=100.00
locale=en
access_key=e2b0c0d0e0f0g0h0i0j0k0l0m0n0o0p3
profile_id=0FFEAFFB-8171-4F34-A22D-1CD38A28A384
transaction_uuid=02815b4f08e56882751a043839b7b481
signed_date_time=2013-07-11T15:16:54Z
signed_field_names=comma separated list of signed fields
unsigned_field_names=comma separated list of unsigned fields
signature=WrXOhTzhBjYMZROwiCug2My3jiZHOqATimcz5EBA07M=
payment_method=card
card_type=001
card_number=4111111111111111
card_expiry_date=12-2022
card_cvn=005
bill_to_forename=Joe
bill_to_surname=Smith
bill_to_email=joesmith#example.com
bill_to_address_line1=1 My Apartment
bill_to_address_city=Mountain View
bill_to_address_postal_code=94043
bill_to_address_state=CA
bill_to_address_country=US
Is this a REST or SOAP API? How can this be tested in Postman? I tested to check if either works, and was unsuccessful. There is no information on what to include in the header either, so this is a bit puzzling.
Example POST test I am attempting:
POST https://testsecureacceptance.cybersource.com/silent/token/create
Content-Type:application/json
Accept:application/json
{
reference_number:123456789
transaction_type:create_payment_token
currency:usd
amount:100.00
locale:en
access_key:e2b0c0d0e0f0g0h0i0j0k0l0m0n0o0p3
profile_id:0FFEAFFB-8171-4F34-A22D-1CD38A28A384
transaction_uuid:02815b4f08e56882751a043839b7b481
signed_date_time:2019-03-07T06:16:54Z
signed_field_names:profile_id,access_key,transaction_uuid,signed_field_names,unsigned_field_names,signed_date_time,locale,transaction_type,reference_number,auth_trans_ref_no,amount,currency,card_type,card_number,card_expiry_date,card_cvn,payment_method,bill_to_forename,bill_to_surname,bill_to_email,bill_to_address_line1,bill_to_address_city,bill_to_address_postal_code,bill_to_address_state,bill_to_address_country
unsigned_field_names:
signature:WrXOhTzhBjYMZROwiCug2My3jiZHOqATimcz5EBA07M=
payment_method:card
card_type:001
card_number:4111111111111111
card_expiry_date:12-2022
card_cvn:005
bill_to_forename:Joe
bill_to_surname:Smith
bill_to_email:joesmith#example.com
bill_to_address_line1:1 My Apartment
bill_to_address_city:Mountain View
bill_to_address_postal_code:94043
bill_to_address_state:CA
bill_to_address_country:US
}
"Is this a REST or SOAP API?"
The URL, https://testsecureacceptance.cybersource.com/silent/token/create, is used for Secure Acceptance Checkout API. Secure Acceptance Checkout API is neither a SOAP API or a REST API. It is designed to be used as an HTML form POST from a customers browser.
If your goal is to use a REST API from the browser then you will want to use Secure Acceptance Flexible Token documented here.
If your goal is to use Secure Acceptance Checkout API the full documentation for that is here.
"How can this be tested in Postman?"
Since this is not meant to be a REST API call but an HTML form POST and HTML response you may have limited success with Postman. For example even if you get the request to work successfully the response will be an HTML document not JSON.
One problem I see is that you are using the example signature, and that will not work for you. Ensure that you follow the documentation on how to create your signature as well as set the signed and unsigned fields.
#J.J. - the error you encountered -- "This field is invalid or missing.Please contact Customer Support.: ots_profileid' ". Is telling you that you are missing (or have an invalid) profileID in your request payload. The system doesn't know what profile to use when processing this request.
We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they've identified the app_id and secret in the URL before the #. The remainder of the URI looks like what I would expect.
Is this valid? I thought maybe this is some weird cURL format I haven't seen before.
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/entity_locations/{locations_id}/
Just seeing if anyone has seen this format before?
A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.
The full scheme is:
scheme://username:password#domain:port/path?query_string#fragment_id
This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password#stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.
EDIT: a brief note about BasicAuth now you're asking - things go like this:
you make a request to http://johndoe:12345#service/api/foo/bar;
are credentials good? Ok, you get a 200 OK response with proper body;
are they not? You get a 401 Unauthorized response.
In the latter case, it's the browser [or any other program / script performing the request] that should prompt the user with the login popup.
Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent - it's just that every request to protected resources are featured with such header:
Authorization Basic base64encode(username:password)
Where base64encode is your custom way to encode the username:password string.
I am currently working on a blackberry app that needs to connect to facebook chat. I am attempting to use the XMPP/Jabber interface. I can get the challenge from the server, however when I send my response I get a "not authorized" failure. My response is structured in this way:
api_key=[my api key]&call_id=[time in millis]&method=auth.xmpp_login&nonce=[nonce from challenge]&session_key=[explained below]&v=1.0&sig=[calculated as shown below]
For the session key, I send the user a browserfield to Facebook's site. It returns an access token in the form AAA...|BBB...|CCC... where BBB... is the session key
The sig is calculated by taking the following string, md5ing it, and then converting the bytes to a hexadecimal string:
api_key=[my api key]call_id=[time in millis]method=auth.xmpp_loginnonce=[nonce from challenge]session_key=[explained above]v=1.0[secret key appended here]
from there I base64 encode the response, and send:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>[Base64EncodedResponse]</response>
Facebook's response is consistently a not-authorized error, with no adidtional explanation. Is there something that is missing or something? Thanks for the help.
I was able to figure it out. The problem was, it wants the session secret, not the app secret. So the secret key appended at the end of the signature is obtained from calling auth.promoteSession, not from the App Secret on the website.