Google Auth re-using the OAuth token
If I want to re-use the Google OAuth for Google API client (that does some operations on behalf of the logged in user on the server), what are the steps?
6 Replies
Wohooo @Šlukas MacPrásk, you just became a Waspeteer level 1!
Hi @Šlukas MacPrásk. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. The knowledge sources provided do not contain information about re-using the Google Auth for Google API client. I recommend checking the official Wasp documentation or their community support for more specific guidance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Šlukas MacPrásk, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
I assume step 1 may be to change
getGoogleAuthConfig in src/server/auth/setUsername.ts to include the additional scopes needed for the Google API
then step 2 is a question how to extract/store the access token for the Google API client + have some job to do a refresh token
Or would it be recommended not to mix the user login auth in wasp/opensaas with Google API... i.e. the user will login (with those default scopes) and there'll be a custom redirect URL for the additional scope authorization and extracting the token information?
Or step 2 may be extending the User entity to store the Google OAuth tokens (and step 3 will be the logic for extracting the tokens) if there's no default Prisma place for it in opensaas yet?Hey @Šlukas MacPrásk !
We have an issue with the plan to make this easier for you, so that we expose this token: https://github.com/wasp-lang/wasp/issues/1567 . It doesn't however mention what you can do right now, when we still don't have this implemented. @miho what do you think?
We aren't exposing the tokens to you yet, unfortunately. Until we do, you'd need to go and implement the Google API support yourself, something like asking the user for extra permissions and then getting the token in one of your custom API endpoints. I haven't done anything like that in Wasp, so I'll have to play around a bit to get a sense what would be the best flow. But .. custom APIs + saving tokens in the DB sound okay to me. You register another callback for your Google App and generate the redirect URL yourself. Basically, reimplement OAuth to some degree. You could reuse
arctic since that's already a depdency of Wasp 😄@miho did you have a chance to play around with this? Would that be adding custom endpoints via https://wasp-lang.dev/docs/advanced/apis ? I also saw there was this PR https://github.com/wasp-lang/wasp/pull/1993 which seems to have "accessToken" in one of the hooks?
Custom HTTP API Endpoints | Wasp
In Wasp, the default client-server interaction mechanism is through Operations. However, if you need a specific URL method/path, or a specific response, Operations may not be suitable for you. For these cases, you can use an api. Best of all, they should look and feel very familiar.
GitHub
Auth Hooks by infomiho · Pull Request #1993 · wasp-lang/wasp
Closes #1556
Adding hooks:
onBeforeSignup
onAfterSignup
onBeforeOAuthRedirect
onAfterOAuthTokenReceived
Left to do:
Changelog
Docs
Headless tests #2022