<I would like to continue discussing this issue>
N...
# singer-tap-developmenta
alex_dimov
12/09/2022, 8:47 AMI would like to continue discussing this issue
Now I have come to the conclusion that we have products that use oath2 (authorization through a pop-up window), that is, the user clicks on the product, then he opens a MS, Google, etc pop-up window, where he enters data from his account, and the provider returns us accessToken and refreshToken. We store this pair and when the accessToken is expired we refresh it with a refreshToken.
In this case, we do not receive the user's authorization data and do not store it with us, we only have a couple of tokens
If you say that at every start it is necessary for tap to receive authorization data, then it seems to me that in this case it will be impossible. We run tap every 15 minutes.
Based on this, I have only one solution, create a getToken route on our server, and keep the token updated on our server if meltano does not support it.
c
christoph
12/09/2022, 9:42 AMIf I were in your position I would do everything I can to push back on using the OAuth 2.0 auth code grant flow and get the owner of your datasource to support the OAuth 2.0 client credentials grant flow.
a
alex_dimov
12/09/2022, 12:08 PMOur company has no rights to this. Some of our clients are very concerned about their security and cannot provide direct access to their offices. It's also quite inconvenient (we shouldn't make our flow worse than before)
Authorization using oauth2 allows the client to connect the product in 2-3 clicks; Given that it can connect 10-15 products, we think this is important.
alex_dimov
12/09/2022, 12:12 PMIt seems like it can be done.
The connection of the product takes over our server, receives the access_token and the refresh_token then save to the database, and meltano is launched with an environment that is formed from the database - it does what if the access_token has expired - meltano renews the token using the refresh_token, and also makes a request to our server where it sends new up-to-date data (in order for it to have valid credenshales the next time it is launched. Is this a normal way? Or does it violate some principles
v
visch
12/09/2022, 7:21 PMAlmost all of oauth flows can be handled by storing the refresh tokens. The tap then uses that refresh token to generate new access tokens
visch
12/09/2022, 7:23 PMSo in your case the flow on your webpage does the "oauth dance" gets a refresh token, stores it securely. Then the tap uses that refresh token to generate access tokens
a
alex_dimov
12/09/2022, 8:24 PMOh it looks like what I need
c
christoph
12/10/2022, 12:26 AMAlmost all of oauth flows can be handled by storing the refresh tokens.That is true. But the security problem is that for any OAuth 2.0 token flows that don't use a client secret (and Alex's example indicates such a Public client flow without a client secret!), the refresh token when stolen is the ONLY thing needed to take over the identity. The OAuth 2.0 Security Best Current Practice says on this topic:
2.2.2. Refresh Tokens
Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation as described in Section 4.13.https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-refresh-tokens https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#refresh_token_protection https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-recommendations So, in short. I think that transferring and re-using refresh tokens from a public client flow (e.g. Authorization code grant flow) within a confidential client flow (e.g. Client Credentials flow) should be much more discouraged in the industry than it currently is.