Dear @pontus.berglund ,

Do you have the connection working with Postman? 
OAuth2 can work in different ways.

If the connectection works with a Bearer token I put the Autorization in the Custom headers in the MISC section of the REST connector: Authorization: Bearer rACCCESS TOKEN]

Did you try to add; Bearer rACCCESS TOKEN] where it now inputs just the Access Token?

= Daniel

Hi @daniel,

Yes I have got it to work with Postman using this feature:
 

I will try your suggestion in the misc section!

@daniel  Am I supposed to write it in this way? It seems that the Rest provider is not actually passing the token in the header, only the text, “Bearer eaccess token]”. 

Dear @pontus.berglund ,

Yes this is the way. Make sure that you dont have other authorization options filled in and you should enter the access token where you now have ACCESS TOKEN]. This does not work as an variable or anything. (maybe you've created the screenshot with ACCESS TOKEN] to not show the access token )
have you set the Authentication method to ‘OAuth2’?

= Daniel

Unfortunately I dont not have a OAuth2 connection currently. I'm working on one but the endpint is SOAP and that works completely different (and I don't have it working yet as well)

So if it is a more modern API endpoint then SOAP it should work like this:

You can set up the logging so you can see what is going on. Set verbosity to 5 so you can see in detail what is going on. Dont forget to set it back or turn the logging off when done. This will create very big logfiles otherwise.

To use the custom header: Check here aswel: 

= Daniel

@daniel You are right, I assumed it would work like a variable. I entered the token as a regular string like you suggested and it worked! Thanks for the help.

On a side note, I am guessing this method will not work after the token expires? 

Dear @pontus.berglund ,

No I'm afraid that this will not work when the token expires. Maybe @Thomas Lind knows how this works with the refresh token? Maybe some custom coding in a RSD.

Although there are a lot fof options in the connector so it kind of looks like it is a ‘build in’ feature.

Would be great to have a TimeXtender Tuesdays on this topic?

 @daniel yes it would be great if there was a way to make it work dynamically with tokens that expires, even if we need to customize our RSD file. This is the second API I have come across with this issue. 

@Thomas Lind or @Christian Hauggaard, could you make a ticket with CData about adding the option to include an authorization header prefix in their REST Provider, like Postman has?

@pontus.berglund 

If the token expires or not is dependent on the API, some will not expire others will expire every hour.

You need to figure out how to set up OAuth authentication in the setup. If it works in Postman using the authorization option it will work in TX.

You can use the Graph API to test on. It can be used both for CLIENT and CODE grant types depending on what rights the app you use have.

Using OAuth, will store the bearer token that gets generates in the file called OAuthSettings. This will be updated before each execution.

Hi @Thomas Lind,

That would work if the API did not demand that the token is returned with “Bearer ” as a prefix.

What is happening is that I am successfully authenticating with the API using OAuth, and a token is returned. Let’s say that the token has the value 123.

The CData is returning the token by default in a header to the API like this:
Authorization: 123

This however fails, since the API is expecting the Bearer prefix to be included, like this:
Authorization: Bearer 123

In postman you have the option to define a authorization header prefix (as seen in my screenshot above). I have seen several APIs using Bearer as a header prefix. The only way to get it working in TX I have seen is @daniels example where we hard code the prefix together with the token in a custom header.

Hi @pontus.berglund

Have you tried to set it up as explained in the initial setup image?

I may have missed you explaining this, but I can’t find it in this thread whether doing that worked.

Graph API also returns a bearer token. It is not something you can see in clear text as it is encrypted in the settings file.

If you see how it looks after I generate a new token in Postman with the Bearer token authorization header.

@Thomas Lind , Yes I have set up my data source like described in the API documentation and I can authenticate successfully. If I also look at the log file I can see that a token has been returned.

This is how it looks in Postman when I call the API with the header prefix “Bearer“ included:

When I try the exact same request but without “Bearer” as prefix to the token, it fails:

This is not a suprise since this is what the documentation states:

Hi Pontus, did you manage to solve this? I'm having a very similar problem.

​Hi @gerrit.deglee 

Pontus and I had a meeting with CData yesterday. So it is still ongoing.

One thing we were suggested was to use fiddler to see what was sent in regards to headers, token and similar. So you could try that as well,

We are planning to use the RSD option as well.

Let me know how your issue is, maybe it is a little bit different compared to this.

​

Hi @gerrit.deglee,

To add to Thomas’s comment, I was facing this issue with two different API’s. The problem was solved for one of them by updating to the latest version of the CData REST connector. The investigation into the API we still have issues with is ongoing. 

@Thomas Lind in my case I'm getting an acces and refreshtoken by using username and password:
 

In subsequent requests I need to use the obtained accesstoken with the bearer prefix:
 

I can also do the initial login manually once and set the refreshtoken if that is easier

I've tried multiple variations of OAuth, OAuthPassword and OAuthJWT without success yet. I'm only able to gain access if I use a customheader with the Authorization:Bearer <token>. But that should be dynamic somehow.

@gerrit.deglee that sounds very much like the problem I am facing. Out of curiosity, in what “form” is the access token being returned to you when you make the POST call? Is the response body only a string of text,

like so: “poiafhjpafj.qfqf.awfaesg”

or is it in a JSON object

like so: {“access_token” : “poiafhjpafj.qfqf.awfaesg”}?

In my case, it is returned as a string, and our current hypothesis is that the REST connector does not understand that it is a token, and therefore it is not used in the authentication process. Please note that we have not confirmed this, more testing will need to be done.

@pontus.berglund In my case it is returned as JSON. But, to be honest, in my case it could still also be a configuration error.

Hi gerrit

We learned a secret method. Add EncryptOAuthSettings=false to the Other field

Then attempt to run the Authenticate OAuth procedure. Now the file will be without encryption and you can see what is being returned.

Hi @Thomas Lind, I've added that, but no logfile is generated when using Authorize OAuth, only when using 'Test Connection’. I get a 500 error instead. For the record, I'm using CData ADO.NET Provider for REST 2023 (23.0.8685.0) with Verbosity 5

Hi @gerrit.deglee 

It is not the log file it is the OAuthSettings.txt file you can see it in.

Do you have that after authenticating? You can find it by copying the path and excluding the filename itself.

Hi @Thomas Lind unfortunately that file is not generated in my case.

Hi @gerrit.deglee 

Can you make a specific support ticket for this issue?