To homepage To homepage
Solved

OAuth with authorization prefix "Bearer "

  • 26 September 2023
  • 23 replies
  • 307 views
P
Rank
Userlevel 3
Badge +1

Hi,

I am trying to connect to a REST API that uses OAuth2 authentication.

The API documentation is very clear on what to include in the authentication: 

 

I have entered all this information in the REST CData provider and I can successfully use the provider’s “Authorize OAuth” button.

However, when I try to test the connection, error “401 - Unauthorizated” is returned.

In the API documentation, they state that the token needs a prefix “Bearer “.

I suspect my error is caused by the REST CData provider sending the authorization header without the Bearer prefix, like so:
Authorization: {ACCESS_TOKEN}

Which the API of course does not accept.

 

Is there any way to include a prefix to the token in the authorization header?

icon

Best answer by daniel 26 September 2023, 15:05

View original

23 replies

daniel
Rank
Userlevel 4
Badge +5

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 [ACCCESS TOKEN]

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

= Daniel

P
Rank
Userlevel 3
Badge +1

Hi @daniel,

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

I will try your suggestion in the misc section!

P
Rank
Userlevel 3
Badge +1

@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 [access token]”. 

 

daniel
Rank
Userlevel 4
Badge +5

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

daniel
Rank
Userlevel 4
Badge +5

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

P
Rank
Userlevel 3
Badge +1

@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? 

daniel
Rank
Userlevel 4
Badge +5

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?

P
Rank
Userlevel 3
Badge +1

 @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?

Thomas Lind
Rank
Userlevel 6
Badge +5

@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.

P
Rank
Userlevel 3
Badge +1

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.

Thomas Lind
Rank
Userlevel 6
Badge +5

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.

 

P
Rank
Userlevel 3
Badge +1

@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:

 

G
Rank

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

Thomas Lind
Rank
Userlevel 6
Badge +5

​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.

​

P
Rank
Userlevel 3
Badge +1

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. 

G
Rank

@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.

P
Rank
Userlevel 3
Badge +1

@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.

G
Rank

@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.

Thomas Lind
Rank
Userlevel 6
Badge +5

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.

G
Rank

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

Thomas Lind
Rank
Userlevel 6
Badge +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.

G
Rank

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

Thomas Lind
Rank
Userlevel 6
Badge +5

Hi @gerrit.deglee 

Can you make a specific support ticket for this issue?

Reply


Terms and ConditionsCookie settings