#zelbazk
1 messages · Page 1 of 1 (latest)
much appreciated!
Hi there 👋 jumping in as my teammate needed to step away. I don't have too much experience with this, but am happy to talk through it. Can we start by focusing on the passing of the client_secret to Google's service, specifically why you feel that isn't a great pattern?
Could you also provide a link to Google's OAuth docs that you're referencing? I found some that give me the impression the call to Google would return an access_token, so I'm worried I'm not looking at the right docs for what you're trying to leverage.
Hi Toby! Thanks for stepping in.
I'm happy to pass the client_secret so long as I don't expose it to the end user within the app, however the documentation made it sound like its not possible to do this.
for context I'm trying to stand up a more or less standalone stripe app that just connects to a user's google account
re: returning an access_token, actually i think the issue is more on the stripe sdk side in that case. the documentation makes is sound like i have to accept an authorization code at the redirect_uri and not a access_token. But is this not the case? would oauthcontext passed to the view expose to me the access_token straight away?
That guide may not be exactly worded for every OAuth provider, various providers may have slightly different requirements/patterns and their docs are usually the best reference for that.
The documentation I was looking at from Google, seemed to indicate that when provided a grant_type of authorization_code (which that doc also said is a requirement) that the response will still include an access_token:
https://cloud.google.com/apigee/docs/api-platform/security/oauth/access-tokens
ah, so I'm looking at Google Oauth here https://developers.google.com/identity/protocols/oauth2/web-server#exchange-authorization-code
and not apigee
But I guess the short cut question really here is that is the pattern for the stripe app to provide client_id + client_secret clientside for google Oauth?
just because I feel like client_secrets should always remain confidential.
Based on how we recommend handling the client secrets that are created as part of Stripe flows, I agree those values should not be logged/stored. But it's client-side code that relies on those values so they must be shared.
and there's nothing like with the Secret's Store that keeps things serverside? I feel like this is gonna be me rotating the secret every couple of days haha
Still parsing through things
Hello! To clarify, the access token is stored in the secret store, but your Stripe App UI needs to retrieve the token from the secret store to use it. Can you provide more details about your specific concerns about this? How would you expect to be able to access the OAuth provider without the token?
Hey Rubeus, the issue is more of where the client_secret is stored in order to obtain the access_token.
Okay, tell me more about that.
If i upload a client_secret with app in plaintext, doesnt that bring with it all the issues of having my google client_secret exposed and checked into a source code?
Why would you do that instead of storing it in the secret store?