When I use the HTTP OAuth2.0 connector and I try to set up authentication, I use the redirect URI in the Fusion 2.0 documentation but when it redirects it says page not found. Do I have the wrong redirect?

[CadenCr]

redirect URI: https://www.workfront.com/oauth/cb/oauth2

[darin_patterson]

Hi Caden,

I think you have identified a problem with our documentation. We will work with our team to fix. In the mean time, the correct redirect URI is: https://app.workfrontfusion.com/oauth/cb/oauth2

Apologies for the likely confusion that would cause.

[CadenCr]

Hi Darin,

Yep that was the issue! Thanks for your help!

It is recognizing and verifying the authentication now but when I make calls it isn't recognizing the authentication and I am getting a 403 error. I'm not sure if it is a misunderstanding of the third party API or my misunderstanding of the connector. Do I need to put the token in the header or is that supplied automatically?

[darin_patterson]

Hi Caden, I'm glad that got you a bit further.

A 403 error is most commonly associated with a concept wherein you don't have the appropriate permissions in the 3rd party system (or haven't requested them and got them granted in an fully fledge oAuth2 implementation).

This will definitely be nuanced based upon each 3rd party API, but it does indicate that "authentication" worked...but "authorization" did not .

To your question on the header, the default is that our HTTP connector will send the token in the header (but you can change that with advanced settings of the HTTP connection).

Out of curiosity, what service are you connecting to?

[CadenCr]

That is a helpful distinction Authentication/Authorization. I'll look into this and look at the token header in the advanced settings.

I am trying to use a service called Bluescape. https://developer.us01.bluescape.com/guides/user-auth#step-1_authorize

[darin_patterson]

got it. I don't see anything obvious on this service that would produce a 403..but it could be as simple as the user doesn't have access to something.

Also, I would assume you'd want pass in response_type=code in your initial request ("Access Token generated using Access Code and Refresh Token")

[CadenCr]

I was able to replicate the error. It happens when the header parameter, 'Authorization', is equal only to 'Bearer'. For some reason, the connector isn't putting the token into the Authorization value.

When the authentication pop-up comes up and I authenticate it goes to a screen that say something like 'you can close this window' but up in the URL of the pop-up I see as one of the parameters ?code=<access_code>. I know that I am obtaining the access code with my first authentication but from what I am gathering several things could be happening from here

1. There isn't a second call being made to obtain the access token or it is failing but I don't know if either is happening
2. I am obtaining the access token but it is either it is not being put into my Authorization header or I have mistype something in my advanced setting under 'Header token name'. By default, it had 'Bearer' as a value so I assumed it would concatenate the access token but when I looked at the documentation it stated to put in 'Bearer <access token>' but that didn't work either. It doesn't seem to be dynamic or perhaps if it is then it might have mis-matched nomenclature but I would have no way to change that.

I might be way off but I know at least that I replicated the error in postman by placing the value of the Authorization header as 'Bearer' so I think it has something to do with the access token.

[darin_patterson]

Hi Caden, In the spirit of collaboration, I *may* be able to help work through this with you if you want to jump on a short call. Send me an email at darinpatterson@workfront.com if you are interested in arranging such a thing. Cheers.

[darin_patterson]

For what it's worth (to anyone else our there:) ). Caden an I were able to connect and successfully establish an HTTP oAuth2.0 connection to Bluescape in Fusion. It turns out, once you get all the URIs right (from 3rd party systems), Fusion does a good job of handling the rest. A few notes for others that may be worthwhile.

The HTTP OAuth2 connection follows a standard "Authorization Code Flow" or "Implicit Flow". (you choose which one). These are oAuth 2 standards and a good resource to learn more about those standards is here. As such, step one is to ascertain what type of flow the 3rd party uses and how closely they follow the standard.

In the case of an "Authorization Code Flow", Fusion automatically passes in the standard parameters for the GET to the authorization endpoint (e.g. client_id, redirect_uri, response_type, etc.). You don't have to add these in yourself. If there are "non-standard parameters", then you can add those as well. Once the authorization part is completed, it will automatically pass standard parameters for the POST against the Token Endpoint (e.g. grant_type, code, redirect_uri, etc.).

In other words, many times (and this time), all we had to do is enter the correct Authorize URI, Token URI, client_id, and client_secret and everything else just works.

Cheers.

[GregWi]

@Darin Patterson - inactive‚ Glad I found this post noting that the redirect is https://app.workfrontfusion.com/oauth/cb/oauth2 - as I was working with the https://www.workfront.com/oauth/cb/oauth2 uri which is still referenced in documentation - here. There did not seem to be any 'straight' OAuth2.0 instructions, just those for MS & Google.

Unfortunately while I now can get past the 404 error and see the code returned in the pop-up window I am getting a Failed to verify the connection error. But no error codes or anything showing in Fusion Dev Tools that I can see. Wonder if anyone has managed to connect to GoToWebinar via OAuth before? Have it working in OK in Postman......

[darin_patterson]

Hi Greg, thank so much for pointing that incorrect documentation out. I've connected with our documentation team to make sure that we update that article as well. My apologies for any confusion.

The typical "oAuth 2.0" connector documentation is here.

As for "GoToWeinbar", I've never personally established this connection but I suspect I have a clue.

Without going into all of the "why", can you try this out:

When creating your connection, go to advanced settings and add a "Custom header". The key should be "Authorization" and the value would be "Basic {{base64}}" where base64 is the base64 encoded clientID:secret combination described on GoToWeinbar here.

If that works, then I'll give all the gory details as to why. If not, feel free to post additional details or questions.

[GregWi]

@Darin Patterson - inactive‚ Worked like a charm - that's what I get for assuming that the connection was automatically encoding the ID & Secret provided in those fields...... I'd tried different combos of scope, info in headers / parameters / both to no avail. Off for some GoToWebinar API fun.

[darin_patterson]

that's great to hear. Thanks Greg.

I'll take the action item to make this more explicit in our documentation. But there are two ways that an oAuth flow might support client authentication according to oauth2 standard. One is to send the client ID and client password through the body (which the http oauth 2 connector does automatically). and the other is to transform the clientID and clientSecret to base64 and include in the header of the Token call as an "authorization parameter" (which the http oauth 2 connector does not do automatically).