search

OpenFn / adaptors

The new home for OpenFn adaptors; re-usable connectors for the most common DPGs and DPI building blocks.
GNU General Public License v3.0
4 stars 8 forks source link

Add OAuth2 support to http adaptor #581

Closed taylordowns2000 closed 1 month ago

taylordowns2000 commented 1 month ago

OpenFn v2 users can now build their own OAuth2 clients in a few clicks, making it possible for other users on the platform to create OAuth2 credentials for any app super easily.

Soon, we'll have way more OAuth2 credential types than we have adaptors!

I think that we should consider adding OAuth2 support to http so that folks can use a specific OAuth2 credential and a basic HTTP helper function to make interacting with new REST APIs super easy.

We might be able to do this by simply looking for state.configuration.access_token and using that if it's present. Thoughts?

taylordowns2000 commented 1 month ago

@mtuchi , @josephjclark , @aleksa-krolls , would love your thoughts on this!

josephjclark commented 1 month ago

Sounds good - but we can pretty much do it today!

If you pass { headers: { Authorization: `Bearer: ${$.configuration.access_token}` } } in your request, it'll work. http won't force basic auth on you (since #540).

But I agree with this issue and we should automatically use the token if present

taylordowns2000 commented 1 month ago

Ah brilliant. That's good to hear, but yeah... I'd still push for making OAuth2 automatic as we're starting to tell people that it's a better/more-standard way of doing authentication for middleware platforms.

I'd love to see devs crack open the REST API docs for "Tool X", find the endpoint they want, and simply type:

get('https://www.toolx.com/api/v3/coolThings');

And have it work because they used a "Tool X" OAuth2 credential and granted the api and coolThings scopes. Or whatever :-)