Is there a spec out there for defining your configuration to generate a Refresh Token for an API specifically Oauth2 but there's almost certainly other use cases. It's kind of like upstream of both https://gitlab.com/meltano/meltano/-/issues/2873 and https://gitlab.com/meltano/meltano/-/issues/2918 Today the steps are: 1. Write a Readme walking people through how to generate a refresh token 2. Normally the steps are something like, use curl or your favorite HTTP requests tool 3. Type in your clientid,clietnsecret, scope, etc 4. Use your browser to do something 5. Copy the Refresh token into your configuration It's almost like Meltanos concept of

kind

for configs of oauth2_refreshtoken or maybe more specifically something like

zoho_oauth2_refreshtoken

Use Case: 1. Instead of the steps above being a Readme bake that spec into some kind of configuration. You could have a UI help you out to generate refresh tokens for you I'm sorry this is kind of hand wavy I'm mostly wondering if someone can help point me in the right direction here. I don't think I want to build anything right this second but I can tell you this is a problem in every Data Platform

Hi Derek, Not sure if you got any crowd wisdom on this one? Initially it sounded like you were after something like OpenID connect https://openid.net/connect/ , but then I wondered if you were thinking more like a standard for the tap configuration. We recently implemented some 'intelligent' refresh token support in (https://github.com/Matatika/tap-google-analytics) and a React plugin that understands the discovery settings oauth_credentials.* - e.g. when you see the oauth_credentials.authorization_url, oauth_credentials.scope, and oauth_credientials.grant_type=authorization_code you know you need to ask the user for google consent. Hoping to get into the SDK oauth in taptober later this week!

The react plugin sounds right up the ally of what I'm talking about! Just a layer between the plugin, and the React plugin. I think everyone shims together their own version of this with some layer in the UI. I really wonder if this should be a "type" of configuration, some spec most everyone agrees on for oauth2 flows (ha, I think I'm dreaming as I'm writing this) end goal is to get the Refresh Token in the UI. Specifically Google's libraries tend to spin up a local server to do the handshake (what do you authorize this application to do, hit yes, send back a code) local webserver takes the code, and stops blocking the local process, then the handshake continues (code -> refresh token) refresh token gets stored somewhere and you're in luck. Now for google the right answer is go with a Service Account (which I believe bypasses this). A lot of apps don't have that option so you have to gen a refresh token somewhere.

Right. This layer in the middle is actually pretty cool. So what we do is something similar to Auth0 - proxy the oauth authorization and refresh requests. Basically the UI has to be involved for the consent request as you say, but the code exchange and refresh request need to using a clientid / secret and require a 'secure server' somewhere to do this. This is what is look like now: