For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
3 0 0 1

RTO CIAM-V2 Websocket Java Example Code and Access&Refresh Token

Api used: Websocket

Lang: Java

V2 Permitted grant type used by service account: ClientCredentials

Hi, my question is regarding Websocket - Java connection to RTO CIAM-V2 on behalf of my client. Appreciate if it can be replied in short time, thanks in advance.

Let me first ask regarding example codes on github. In this client case, the example github code is given like below based on Real-Time WebSocket API: Refinitiv Real-Time Optimized Version 2 Authentication Migration Guide | Devportal (lseg.com) article. Is this code the latest version and valid for Java Websocket api connection to RTO v2 with clientcredentials grant type? Can client directly use this instead of re-coding the current code? I also see MarketPriceRdpGwJwtAuth.java example too, but I assume this is for JWT token grant type for Service ID, not for Service ID with Client Secret. Appreciate if you can confirm this.

websocket-api/Applications/Examples/RDP/java/MarketPriceRdpGwClientCredAuth.java at master · Refinitiv/websocket-api · GitHub

Currently, my client is connected to RTO with Machine IDs and they are using websocket-Java application. In the current version, refresh token is used. To convert it for CIAM-v2, what should they do for refresh token part? Do they need to remove refresh token related parameters-parts from the code? Will this be sufficient? For access token, it is mentioned that v2 authentication does not need to renew an Access Token (HTTP/RSSL-WebSocket) as long as the streaming channel (WebSocket/RSSL) is active. Is there any change required to update on current code for the access token part in case that it disconnects? If same, will it automatically connect without manual interruption required by client? I am a little bit confused because it mentions that v2 have longer access token time as V1: 10 minutes vs V2: 120 minutes while also saying no need for resfresh token in v2. But I assume these are two different things. Is this something related to ClientCredentials grant type or JWT token? If regardless, does this mean any change required on client code for access token related parameters or is this just something on our end?

Thank you very much for your assistance, wishing a great weekend ahead.

Best Regards,

Bazit

#technologyrrtorequest-tokenciam
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
23.1k 60 15 21

Hello @muhammed.kizilkaya,

The example in the GitHub shows the correct usage for the Client Credentials (v2) authorization. They should be able to run it without modifications, by passing in command line arguments for --clientid and --clientsecret.

In the client credentials authorization, the application no longer has to periodically renew the token - as long as the session is connected. Once disconnected, they can use the refresh token (if still valid) or use CC grant again.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hi @Gurpreet, thank you very much for prompt response. I informed my client accordingly now.
Upvotes
23.1k 60 15 21

I would also like to mention, that if the client is using Java for programming, then using the EMA Java SDK would be a better approach, since the underlying tasks of tokens/refreshes as well as network disconnects and re-subscription etc are all handled transparently in the SDK.

The OAuth V2 example demonstrates how to use client credentials with RTO.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks for the suggestion, I also added this as advice.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.