For a deeper look into our Elektron API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
Getting {"error":"access_denied"} when trying to get access token
Here is the part of code that calls the endpoint (to get a glimpse of headers, method etc.):
Unirest.setTimeouts(0, 0);
HttpResponse<String> response = Unirest.post("https://api.refinitiv.com:443/auth/oauth2/v1/token")
.header("Content-Type", "application/x-www-form-urlencoded")
.field("grant_type", "password")
.field("username", "***************")
.field("password", "***************")
.field("takeExclusiveSignOnControl", "True")
.field("scope", "trapi")
.field("client_id", "********************")
.asString();
Here’s what I get from server:
Response body:
{"error":"access_denied" }
HTTP status: 400
Headers:
Date Tue, 30 Jun 2020 14:24:59 GMT
Content-Type application/json
Content-Length 29
Connection keep-alive
X-Amzn-Trace-Id Root=1-5efb4b3b-4a278e16d28720ec9826d572
X-Served-By region=eu-west-1; cid=9b0a08d5-13b9-4b70-bc36-90e6c60e0089
X-Tr-Requestid 52ddba1d-31a4-4b9f-bc55-30d1834d5c81
Credentials are ok, because if I change them to the wrong ones - I get different message.
I've tried sending request with Postman, Refinitiv provided Python script: https://raw.githubusercontent.com/Refinitiv/websocket-api/master/Applications/Examples/EDP/python/market_price_edpgw_service_discovery.py
Result is totally same.
The ERT in Cloud team has verify the issue and found the root cause. The issue comes from corrupted DNS cache in the network level. The issue is now resolved.
Hi @adomm, Have you generated the AppKey and using that parameter in the client ID. Please see this step-by-step quick start guide. If you are still getting access denied message, it would imply that your credentials are incorrect. Please contact you Refinitiv account manager in that case.
Thank you for answer Gurpeet. Forgot to mention that code worked successfully before for quite a while and it stopped working just out of the blue. And yes, I did follow Quick start and yes, I generated AppKey and used as client id.
Password doesn't seem to be a problem as if I actually change the password to the wrong one - I get a different message.
I'm in contact with support and no one has a slightest clue what's going on.
What is the message when wrong password is used. Could you post complete return messages.
Here is what I get on wrong username/password:
HTTP 400:
{"error":"access_denied" ,"error_description":"Invalid username or password." }
And on incorrect client ID:
HTTP 401:
{"error":"invalid_client" ,"error_description":"Invalid Application Credential." }
When wrong password is used I get HTTP status 400 and Body: {'error': 'access_denied', 'error_description': 'Invalid username or password.'}
When password is right I get just: {"error":"access_denied" }
If needed - I can provide X-Amzn-Trace-Id, X-Served-By and X-Tr-Requestid header values which might help debugging, I guess.
Hi @Gurpreet.
Can you please investigate the bold/italic part above with development? This is the point where things go wrong on Adomas environment.
I have used his credentials and get the following.
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
Regards,
Erol
Note: Unnecessary use of -X or --request, POST is already inferred.2JmZDY0NmY4NGE1MGE2MjJlMzYyNDRlYW
* Trying 52.19.116.133:443...
* TCP_NODELAY set
* Connected to api.refinitiv.com (52.19.116.133) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; postalCode=10036; ST=New York; L=New York; street=3 Times Square; O=REFINITIV US LLC; OU=RDP; CN=api.refinitiv.com
* start date: May 29 00:00:00 2020 GMT
* expire date: May 29 23:59:59 2021 GMT
* subjectAltName: host "api.refinitiv.com" matched cert's "api.refinitiv.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Organization Validation Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x564ee25fddb0)
> POST /auth/oauth2/v1/token HTTP/2
> Host: api.refinitiv.com
> user-agent: curl/7.68.0
> accept: application/json
> content-type: application/x-www-form-urlencoded
> authorization: Basic MDA1N2JmZDY0NmY4NGE1MGE2MjJlMzYyNDRlYWIzMWM2ZGI4NjQ1ODo=
> content-length: 188
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* We are completely uploaded and fine
< HTTP/2 400
< date: Thu, 02 Jul 2020 13:16:30 GMT
< content-type: application/json
< content-length: 29
< x-amzn-trace-id: Root=1-5efdde2d-6a3384aa010ef27c7d3289cc
< x-served-by: region=eu-west-1; cid=7936fa55-77dc-4fa7-a9f8-80bc66a20408
< x-tr-requestid: 8f714e38-d958-4a68-a128-6535002deab2
<
* Connection #0 to host api.refinitiv.com left intact
{"error":"access_denied" }
Hi Erol, We can provide technical API support, but don't have any visibility into product deployment. It is best to raise a service ticket at my.refinitiv.com for product team to look into the issue.