<I would like to continue discussing this issue> N...
# singer-tap-development
a
I 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
If 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
Our 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.
It 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
Almost all of oauth flows can be handled by storing the refresh tokens. The tap then uses that refresh token to generate new access tokens
So 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
Oh it looks like what I need
c
Almost 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.