APIToken service throws HTTP 403 to our request

Log:

GetAPIToken HTTP Request: grant_type=password&username=GE-A-00173750-3-4555&scope=trapi&client_id=GE-A-00173750-3-4555&password=xxx&takeExclusiveSignOnControl=true

2021-05-03 13:45:49.843 +00:00 [Information] ApiTokenServiceElectron: GetAPIToken HTTP Response: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>

APITokenService URL: https://api.refinitiv.com/auth/oauth2/v1/token

Best Answer

  • Gurpreet
    Answer ✓
    I don't say that the whole service is wrong, what I say, it doesn't work with my credentials, although it should, and have been working for half a year.

    This is the reason I wanted you to check a Refinitiv provided sample. There is no other way for us to identify if the issue is in your code, or with your entitlements. We do know passing machine ID as client ID is not correct - which is what your application is doing.

    You can contact your Refinitiv account manager to check your credentials.

Answers

  • Hi @laszlo.torok,

    What is this function GetAPIToken and which language/API are you using. If you are new to Refinitiv Real time optimized, then please start from this quickstart and use the provided samples to test it out.

    This error message is not originating from Refinitiv systems.

  • Also note that you are using your machine ID as client ID. The application needs to pass a unique client ID, which you can be generated from AppKeyGenerator.

    See the quickstart linked in previous response.

  • I'm sorry, this is message IS from the URL I provided. We have been using exactly this HTTP request for at least half a year now, then on Friday, suddenly, the API token service started to throw this error. The goal of the call would be to get an authentication token from the token service.

  • The limited information that you are providing isn't helping in diagnosis of the issue. The URL cannot be invoked in a browser - if that is what you are asking. I just tried it getting token in an application and was successful.

    If you are getting HTTP 403 - Forbidden, there will be additional details in the JSON message like this:

    {
      "error": "invalid_client",
      "error_description": "Invalid Application Credential."
    }

    Can you try to download the sample as mentioned in the quickstart and follow all the steps and let us know if this is still an issue for you.

    Are you using EMA, if so which language and version?

  • I don't use the URL from a browser, but from C# code.

    response = await httpClient.PostAsync(authTokenUrl, httpContent);

    string result = response.Content.ReadAsStringAsync().Result;

    authTokenUrl: the URL I provided above.

    httpContent: provided above.

    result: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>

    I don't need a sample, as this code have been working for half a year, and your service started to throw HTTP 403 since Friday.

    From my perspective, it doesn't matter if your sample works or not, as you tried it with different credentials. Which really matters is why it doesn't work with these credentials.

    I don't say that the whole service is wrong, what I say, it doesn't work with my credentials, although it should, and have been working for half a year.


  • And I will repeat this again:

    <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>

    This error message is not originating from our servers. Your C# library responsible for REST call is generating it.

  • "You can contact your Refinitiv account manager to check your credentials. "

    That person sent me here, stating that Refinitiv support works here..

    "This error message is not originating from our servers. Your C# library responsible for REST call is generating it."

    You can repeat it as many time as you want, but it doesn't solve the problem, just show your attitude. The response sent by your server cannot be parsed as JSON, that's why I'm restricted to the pure HTTP response. It's an empty HTTP 403, without JSON content.

    Anyway, this is not what I expect. I expect support to investigate why their service throws HTTP 403, instead of working with the same way with same credentials for half a year.

    I understand, in your opinion passing the same thing as username and client_id is wrong, but then how it it has been been working or months? And if it has been working, my expectation is:

    - It should work the same way towards

    - Or YOU should investigate why it doesn't work not me.

  • Hello @laszlo.torok,

    It's unfortunate that you have encountered this issue, that the code that have been working, have suddenly stopped working, you have not made any changes on your side just prior, is my assumption on this correct?

    If this is the case, one possible and very likely cause is your machine id's permissions having expired or been updated.

    The best course of action is, as suggested by @Gurpreet, to contact your Refinitiv account manager directly, who can help verify your RDP credentials, and will be able to request your RDP password reset, if required.

    The moderators of the forums can be of help with Refinitiv API usage questions, but not with permissionining issues, at least not directly.

    In this instance, we have also contacted your organization's Refinitiv account manager, to let them know of this issue.

    However, looking at the worst case scenario, if, once the creds are verified and password is reset you continue facing the issue, this would mean that the credentials remain valid and permissioned, and the solid next step would be to test with the standard example that is included with Quickstart Guide , to verify if the issue is originating within C# code/config, as discussed by @Gurpreet.


  • Hi @laszlo.torok

    I just tested the get token endpoint with both client id or machine id as client id input and both of them work fine:

    image

    image

    If the code has been working fine before, are you aware of any network policy/firewall/proxy changes in your company?

    I believe that this may be related.

    By the way, if the issue is related to your machine id permission (I don't think this is the case).

    You still have to contact to Helpdesk to investigate the account permission issue.

    Thanks for your understanding.

  • No, we haven't changed the code, and I'm not aware of network changes. Anyway, it doesn't seem to be a network/firewall problem, as we can access the server, just the response is not what I expect. I'm going to ask the Account Manager.