Is it possible to retrieve an OAuth token using an iPlanetDirectoryPro cookie from a user session?

cory.schmidt.1

I'm working on an Eikon add-on (desktop, thick client) that uses AAA to log in and entitle users. We're transitioning some of our services to the Elektron Data Platform which requires an OAuth2 token. We want to use the iPlanetDirectoryPro cookie/token which was created when the user previously logged in. In reading the API documentation it looks like Implicit Grant is what we want (https://developers.refinitiv.com/article/oauth-grant-types-elektron-data-platform) but I haven't been able to find an example of exactly what I'm trying to do.

The auth/oath2/v1/authorize endpoint will take an iPDP cookie but requires a redirect URL to handle extracting the token. We're a desktop app so we can't provide that. The auth/oath2/v1/token endpoint will return a token but requires a username and password. Is there an endpoint that will take an iPDP cookie and return a token?

Find more posts tagged with

oauth

rdp-api

refinitiv-data-platform

Accepted answers

Gurpreet

I was incorrect about not needing a redirect_uri. It is required and you can use localhost here to capture the 302 HTTP response.

So, your request from desktop app will look like:

GET https://api.refinitiv.com/auth/oauth2/v1/authorize?client_id=****&response_type=token&scope=trapi&state=****&redirect_uri=https://localhost:9999 HTTP/1.1
Host: api.refinitiv.com
User-Agent: curl/7.59.0
Accept: */*
Cookie: iPlanetDirectoryPro=****

and the response message will contain the access token:

HTTP/1.1 302 Found
Date: Thu, 31 Oct 2019 17:52:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Location: https://localhost:9999#access_token=****&expires_in=300&token_type=Bearer&scope=****&state=****
X-Amzn-Trace-Id: Root=1-5dbb1f49-13106f15889270e68dcaf913
X-Served-By: region=us-east-1; cid=dcab979a-1ca9-4bf7-8982-21dde3066551
X-Tr-Requestid: 8265728c-23ac-48e0-ab5f-1b4b6400df0b

All comments

Gurpreet

It should be possible to use Authorization Code or Implicit grant for desktop applications. See an example for a browser based Single Page Application. A similar approach can also be taken with mobile or a desktop app.

@Olivier DAVANT @pierre.faurel any other recommendations for a seamless signin between Eikon and EDP?

cory.schmidt.1

The article you linked to contains the following paragraph:

"In any case, with both the Implicit Flow as well as the Authorization Code Flow with no secret, the server must require registration of the redirect URL in order to maintain the security of the flow."

That leads me to believe that I would still need a redirect in order to maintain security. I haven't found any documentation around already having a token/code and exchanging for an OAuth token.

I can't imagine we are the only group dealing with this problem as other Eikon components are also transitioning. It's just a matter of finding the right guidance. :-)

Gurpreet

You should talk directly to AAA and STS teams who can advise on the correct approach.

For oauth2/v1/authorize endpoint for Implicit grant redirect_uri is not a required parameter, you can pass in the response_type = token with your IDP cookie to exchange it for an Access token.

I tried it and it works.

Gurpreet

I was incorrect about not needing a redirect_uri. It is required and you can use localhost here to capture the 302 HTTP response.

So, your request from desktop app will look like:

GET https://api.refinitiv.com/auth/oauth2/v1/authorize?client_id=****&response_type=token&scope=trapi&state=****&redirect_uri=https://localhost:9999 HTTP/1.1
Host: api.refinitiv.com
User-Agent: curl/7.59.0
Accept: */*
Cookie: iPlanetDirectoryPro=****

and the response message will contain the access token:

HTTP/1.1 302 Found
Date: Thu, 31 Oct 2019 17:52:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Location: https://localhost:9999#access_token=****&expires_in=300&token_type=Bearer&scope=****&state=****
X-Amzn-Trace-Id: Root=1-5dbb1f49-13106f15889270e68dcaf913
X-Served-By: region=us-east-1; cid=dcab979a-1ca9-4bf7-8982-21dde3066551
X-Tr-Requestid: 8265728c-23ac-48e0-ab5f-1b4b6400df0b

cory.schmidt.1

Brilliant! That worked perfectly. Also, in case this helps anyone else, make sure you don't allow redirects in the request.

Thanks!

EXPLORE OUR SITES