#vlad-bubble_api
grave widgetBOT
👋 Welcome to your new thread!
⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime!
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1212432103975821413
📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question. Thank you for your patience!
alpine caveBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- vlad-bubble_api, 23 minutes ago, 12 messages
teal widget
Hi there 👋 we do close threads that have been stale for a while, and typically do not reopen them. Can you summarize the state of your question/concern here for me?
barren phoenix
well, there is a question from Hanzo in my original thread, and I cannot answer it.
maybe we can continue the conversation with Hanzo here.. 🤷♂️
I'll stick around for a real time conversation this time.
teal widget
What's the question? I don't know when Hanzo will be staffing the server again.
Found a second to review the previous thread. Can you tell me more about what you're trying to do? We typically don't recommend using OAuth integrations after we introduced Platform Controls a couple years ago. Instead we now recommend integrating similar to this (may be slightly different depending on the type of Connected Account being used) currently:
https://docs.stripe.com/connect/standard-accounts
alpine caveBOT
barren phoenix
Hi Toby, thank you and sure, here is some context, we have a fairly extensive integration with stripe. Our platform allows users to integrate web applications they create with Stripe via API keys. Functionality like creating subscriptions, adding items to invoices, etc, is offered to our users, and we access the Stripe API directly for these actions.
We've been asked by stripe to move away from API keys and to start using oauth instead.
After exploring the oauth2 approach for stripe-apps, I am now exploring the oauth approach offered via the https://connect.stripe.com/oauth/authorize endpoint.
teal widget
My concern with using OAuth is the note that we have listed here:
https://docs.stripe.com/connect/oauth-reference#:~:text=Starting in June 2021%2C Platforms using OAuth with read_write scope won’t be able to connect to accounts that are controlled by another platform
Where you if you try to connect to a Stripe Account that is already controlled by another Platform, you won't be able to. Instead a new account is quietly created and you're connected to that new account, without any good way of knowing when that behavior occurred.
barren phoenix
How is the word "Platform" used here. is my company (for which I am doing this work) the "Platform" or are is Platform referring to another product or set of endpoints on the stripe side?
sorry, i've been struggling to understand the product descriptions and distinctions in the stripe documentation to be honest. I don't fully understand what this warning is talking about.
teal widget
You are the Platform in a Connect scenario
barren phoenix
Ok. so this warning is saying that if we decide to switch one of our users from using the API Keys they have in their dashboard, and route them via the connect oauth path (where they'll be asked to login into stripe, select the set of permissions, etc).... actually what are we saying... They should be able to use their existing credentials and authenticate with stripe, and be redirected to whatever the redirect_uri is (after which we can go on and request the access token and refresh tokens and etc). Is that not accurate?
teal widget
If that person's Stripe Account is already being controlled by another Platform, that is to say they've already connected to another service that is using Connect in such a way that the Platform they're connected to has significant control over the behavior of the account, then you will not also be able to connect that account. However, if this happens, you don't encounter any sort of an error. A new Stripe Account is created for that person and you're connected to that new fresh account.
barren phoenix
Will the user know that a new account is being created for them during the authentication flow (the flow that's hosted by Stripe where the user is asked to login, provide details, etc).?
teal widget
I don't recall exactly how it looks. I think it's more of a concern from your end, like if you're expecting to be able to interact with existing objects that may not be possible.
It may not be a concern if you only want to allow abstracted access to our API though.
barren phoenix
we do only want to allow abstracted access to your API. I think that's the whole point of this exercise.
but, reading through the concern you mention...
by 'existing objects' you're referring to a scenario - for example - where a user's app tries to update a subscription that was created before the user transitioned to the connect/oauth way of connecting... Is my understanding accurate?
violet mason
Hello! I'm taking over and catching up...
Ah, have you read through these docs? https://docs.stripe.com/stripe-apps/onboarding-plugin
barren phoenix
Hi Rubeus.. Yes. This document you linked seems very similar to: https://docs.stripe.com/stripe-apps/api-authentication/oauth?locale=en-GB (except for the few notes regarding stripe-apps vs connect at the top).
I've mentioned to toby earlier in the thread that I am looking into the connect https://docs.stripe.com/connect/oauth-reference approach at the moment.
violet mason
Sorry, I might be misunderstanding. It sounds like you have a product/service/system where you ask people to paste in their Stripe API keys so you can interact with the Stripe API using those keys and perform operations on their behalf. Now you're being asked to move away from the copy/paste API keys approach. Is that correct?
barren phoenix
yes that's correct 👍
violet mason
Okay, so in that case this is the page you to look at: https://docs.stripe.com/stripe-apps/onboarding-plugin
I recommend trying the OAuth flow described there in test mode to see how it works.
barren phoenix
hi.. soo. I don't know what to say to be honest. I've looked at this document you linked to and that's the approach we considered at first.
the push and encouragement to use Connect comes from stripe. The motivation sounded reasonable:
- connect is simpler to use
- you can authenticate with connect and continue accessing the full API (subscriptions, invoices, etc).
I started looking into connect, and my original question was regarding the expiration time for access tokens obtained via connect. This current conversation notwithstanding, I would love to get that answered if that's possible: if we use oauth via the connect endpoint and start retrieving access tokens for a user who's logged in via connect - how long do the access tokens last? And also how long do refresh tokens last?
I would love to get point that Toby raised in his response here: https://discordapp.com/channels/841573134531821608/1212432103975821413/1212446131003330693 addressed also. Just to make sure that I udnerstand it.
violet mason
The access token expires in 5 minutes as documented here: https://docs.stripe.com/connect/oauth-reference#get-authorize-response
The refresh token does not expire.
The access token is only used to establish the connection between your platform and the connected account. After that you make API calls on that connected account by using your platform's API key and specifying the connected account's ID in the Stripe-Account header. Details here: https://docs.stripe.com/connect/authentication
With the flow and use case you're describing a new account won't be created, this approach is for connecting to existing accounts.
barren phoenix
The first link you provide talks about the authorization_code expiring after 5 minutes. It doesn't say anything about the expiration for the access_code
but based on the second part of your answer, it sounds like we don't need to use access_tokens, and that we can request an access_token once only and from then on use the connected account forever and ever?
violet mason
That's correct.
The access token is only used during the OAuth flow, which only happens once to establish the connection.
After that OAuth and the access tokens are no longer involved.
barren phoenix
ok thank you for that insight. Frankly I am not sure I would have made that connection from the documents.
violet mason
Yeah, I can see that. I'll flag internally and see if we can improve the docs here.
barren phoenix
follow up question.. The docs for using oauth with a stripe-app talk about permissions. The app needs to be permissioned correctly and needs to have all the permissions that you intend to use in terms of accessing the stripe API (payment_intents, subscriptions, etc).
there doesn't seem to be a concept for permissions when using oauth via Connect.
That's because we're still providing our own API key for each call, so it's as if we're accessing the API as usual, but now every call into stripe will be "coming from bubble".. is that correct? (basically - with connect oauth - we don't have to worry about permissions?).
violet mason
Yeah, if you use Connect there aren't permissions at the granular level like with Stripe Apps.
When you use OAuth to connect to an account the main thing permissions-wise is the scope, which can be read_only or read_write.
grave widgetBOT
barren phoenix
one more questions (I may be able to answer this wehn I test this later today but I am not sure that I will)..
the question is, after we get the authorization_code (once the user has completed loging in and has been sent back to the redirect_uri) - do we even have to request an access_token - or is everything done at this point, can we then start making api calls using our secret_key with the connected account's id?
it seems like we do have to make a call into https://connect.stripe.com/oauth/token to retrieve the stripe_customer_id (but we can ignore the token).
blazing sage
Yes, you should be able to after the onboarding has been completed. As you said, you'll use your own secret key and then use the Stripe Account header: https://docs.stripe.com/connect/authentication to make that request.