I recently registered to Microsoft Azure and set up a Cognitive Services Account. Using the instructions from the Text Translation API Documentation I was able to retrieve an authentication token from the /issueToken service using the interactive online example. However, if I want to use that token (for example for the interactive /translate example) I end up with the response
<html><body><h1>Argument Exception</h1><p>Method: Translate()</p><p>Parameter: </p><p>Message: The received token is of incorrect token type.</p><code></code><p>message id=0344.V2_Rest.Translate.3D8A6FF1</p></body></html>
What am I doing wrong? What should the token look like and in what format should I supply it? In the online example I specified the token by setting the appid field to "Bearer [token]" where [token] is the response from /issueToken.
In my case the token is a 687 characters long string which can be separated into three parts (using '.' as delimiter). The first two parts are base64-encoded and just contain some JSON-encoded information that stays constant (except the expiration date field). The third and last part changes everytime and can not be decoded using base64. Instead of supplying the full token I also tried to just use various substrings of the full token but without any success so far.
I also tried authenticating via curl using the Authentication-header instead of the appid-field, which also did not work for me.
The token actually has to look like it is described in the question text (at least as of now). The problem in my case was that I used the wrong subscription key. Note here: You get a different key for the translation API and the speech API each; even though both run under Cognitive Services and even if you connect both through the same resources.
I post this as an answer to my question because I want to confirm that all the steps listed above are correct and because I hope that it may help people who do the same mistake as I did.
Related
We are using ourname.azureiotcentral.com/ and ReadyApi 3.5.0
An access token we created on the azureiotcentral website
looks like this:
SharedAccessSignature sr=739023aa-a2d4-4cc1-8044-0447586f622a&sig=teSPECIMENmawBMI0QUA5b%2BJ%2BDdhuie7JSTA%2BggltI0E%3D&skn=specimen&se=1635585779999
Now back in ReadyApi, which one do we choose as authentication?
next question is:
and how do you know which one to choose?
https://learn.microsoft.com/nl-nl/rest/api/iotcentral/devices/getcredentials
asuming it is ... OAuth 2.0 (Azure)
Then how do you know the profile name?
and is the token started from the SharedAccess part or before the sr= or only the part after the sr=?
and why is there a spacebar in the token? (in short: how to format?)
I tried this:
But then the respons is something with cookies. How do I know what browser is tested/tried?
(today: A colleague told me he thought it was the bearer option)
According to https://learn.microsoft.com/en-us/learn/modules/manage-iot-central-apps-with-rest-api/3-exercise-authorize-api, the shared access signature goes in the "Authorization" header as-is without the "Bearer" prefix. I'm not sure what option that corresponds to in ReadyApi, but it might be easier to remove the authentication option and just add it manually as a header named "Authorization".
in the field VALUE you paste the complete token, including "SharedAccessSignature" and including the spacebar before the sr=! (and yes without the Bearer, thanks Scott) that's it.
Where does a JSON web token live? After doing jwt.sign and adding the payload / expiring date, what happens next, where is it stored ? I cant seem to find anything about it.
Thanks in advance.
JWT is not stored anywhere, its very existence contains everything. Its consisted of three parts, first one is hashing method, second one contains all the information you put there and the last one is signature so you can check if the token is valid or not (if you have secret).
This is actually the main reason JWT is so popular and used - as it can carry information through the multiple systems that can be verified by authorized systems.
I have generated the JWT Token for DocuSign through the https://jwt.io .The signature is verified.
Now to obtain the Access token I am using following Command in Curl,on Windows Command line tool.Rrefering the Document https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken.I am getting "invalid Grant".What is the problem with my request?I know my token is correct because the token verifies the signature.
curl --data "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=YOUR_JSON_WEB_TOKEN" --request POST https://account-d.docusign.com/oauth/token
invalid_grant is the the publicly facing version of several errors rolled together. If you've hit your limit of troubleshooting, I'd recommend opening a case with DocuSign Support, and provide your Demo Account ID, UserID, Integrator Key and the value of an x-DocuSign-TraceToken of a failing assertion. The plaintext version of your assertion would be helpful as well.
Here's a few things to check:
aud value - must be exactly account-d.docusign.com (for demo) or account.docusign.com for prod. Including https:// or any other value will fail.
sub value - must be an active userID (in GUID format) in the appropriate environment.
iss value - must be a valid client ID
Private Key used for signing - must be associated with the Client ID in the correct environment. If you're using a key generated in Production but the assertion is directed to account-d.docusign.com it will fail. In some cases it can take a few minutes for a newly generated keypair to be valid in the Account Server, so if you've just generated that key, wait a bit and try again.
Timestamps used - Your exp value must not have passed, and if you are using an nbf value, it must be in the past. Confirm your computer's clock is correctly configured - if it's dramatically off, your application could be generating invalid assertions because of that.
The pro-tip is to use a library to generate the JWT and convert it to an Access Token.
See the JWT examples for code examples in many languages. The examples use either a JWT method from a DocuSign SDK or a lower level JWT library.
C# .NET Core https://github.com/docusign/eg-01-csharp-jwt-core
C# .NET Framework https://github.com/docusign/eg-01-csharp-jwt-framework
PHP https://github.com/docusign/eg-01-php-jwt
Java https://github.com/docusign/eg-01-java-jwt
Node.js https://github.com/docusign/eg-01-node-jwt
Python. https://github.com/docusign/eg-01-python-jwt
Ruby https://github.com/docusign/eg-01-ruby-jwt
See the repositories’ Readme files for installation and configuration instructions.
I've been using Charles to debug the communication between a mobile app and an API.
We are now changing both the client (app) and the server to use JSON Web Tokens (JWT).
Is there a way to configure Charles so that the JWT is decoded when browsing the requests ?
Basically, the request (from mobile app to server) will consist of a single header (Authorization) containing the JWT, and when I click on that request in Charles, I'd like to see:
- the original token
- the decoded header
- the decoded payload
Looking at Charles' documentation, I found the following:
- Rewrite tool: could replace the token with the decoded data, but it doesn't seem like functions (base64decode) are supported, only plain text or and regexp replacement.
- Map Remote tool: seems like it could do the job, by calling a script on a server which takes in the original request as an argument, and returns the new request with the decoded data. The documentation describes a use for replacing specific sources (when browsing a website), so I'm having a hard time seeing how it could be applied to this case (client to API communication). Doesn't seem like it can pass the original request as an argument (just replaces it).
I know that I could always copy paste the token in a tool that decodes JWT, but that's a small step that I will be repeating a hundred/thousands of times, so I'd like to avoid it.
Or is there another way to debug HTTP requests between mobile and server that are encoded in JWT format ?
Since Charles Proxy doesn't support JWT Decode feature, you can try out Proxyman, which automatically decode JWT and display in a nice place.
If you need to manipulate it, you can take a look at JWT Decode Addon . The Scripting feature allows you to write JS code to achieve the same result.
Disclaimer: I'm a creator of Proxyman. Hope this answer could help you.
There are many excellent questions (and answers) on S.O. around the subject of REST and security. Many say "purists won't like this, but blah blah"... and then others says "you should never do that, because blah blah".
But I have not seen the solution that the "purists" are suggesting for the following scenario. So my question is - what are the "pure RESTful solutions" to the following scenario?
The simple scenario...
Imagine building a database/website that lets a user manage their favorite recipes. The website exposes a RESTful API so that users can query and manipulate their list from a custom program that they want to write (that utilizes this API).
So, user "A" has 3 favorite recipes with the ID's "1", "2" and "3".
User "B" has 2 favorite recipes with the ID's "4" and "5".
We need to make sure that if user A sends a DELETE command to /Recipes/4 that he will get a Forbidden (403) response.
What I would normally do...
What I would normally do is make them first call an authentication method, and send them some sort of auth-token that is valid for 30 minutes or so. Typically this token would be passed via a cookie.
What is the pure solution?
Is the pure REST solution to have them pass it as a variable in the query string? Are cookies the devil? Should the token be used as a segment of the URL (as opposed to a query string parameter)? Is there something else that answers this question clearly?
Pass the token in the authorization header. That's what it is designed for. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-12.html
Treat the auth token as a resource.
You authenticate by GETting an auth token with parameters being credentials (basic auth over https for example).
Logout by DELETE'ing the auth token resource you got when logging in.
A simple stateless and cookie free solution would be giving each of your users an identical token.
There are ways to generate those tokens so that they are sparse enough for security concerns.
e.g. https://www.grc.com/passwords.htm
Suppose you have user A and user B. You generate a token X for user A and a token Y for user B.
So the user A will use something like /X/Recipes/1
and user B will use something like /Y/Recipes/4
It's safe because user A is the only one knows his token and as I mentioned before, the way you generate tokens can make sure it's "impossible" for others to guess that token.
So if someone else, like user B uses some other token in the url, say /Z/Recipes/1, you should be able to recognize and return a corresponding error message.
You can let user deliver the token in url, like I showed above, or embed it in HTTP request as Autherticantion message.