When we add a permission such as youtube in the google connection it is not clear to me if I also need to
Or are these both taken care of somehow?
@Steve_Lee if you enable the YouTube permission in the Google Connection in the Auth0 Dashboard and you have selected the YouTube APIs for your Google application (whose client id/secret you configured with Auth0) then once you successfully authenticate a user Google will include an access token in the user profile it returns to Auth0. You can then use this token to call their API (and any others you requested permission for and the user accepted).
Thanks Kim,
I had the basic workflow down but in fact I still found I had to do enable “Youtube Data api v3” in the Google API panel (https://console.developers.google.com/) before my hosted page authenticated app could access the Google APi (with the token you mention) without the calls returning errors. The same for google tasks and gmail. Your docs never mention this so I wonder if something is a bit strange with my set up
For gmail I eventually found some docs in a hidden corner explaining that the scope options provided in the Auth0 portal are very broad and to specify more restrictive ones (like https://www.googleapis.com/auth/gmail.readonly) you can specify them in the auth option to Lock - eg aim-web-app/hostedAuth0.Login.html at master · AlwaysInMind/aim-web-app · GitHub
Thanks
Okay, great to see you were able to solve your issue! Do you think there could’ve been a better way we could’ve helped guide users using Google APIs in our docs? I am going to take your current feedback to the team, but if you had any further insights/feedback I’d be more than happy to listen. Please feel free to DM me if you prefer.
Thanks for following up Kim - that make me happy 
and reinforces the impression that Auth0 rock!
So for Gmail I think those 2 were the main issues I hit while trying to figure it out.
The other issue I hit was how to get the Google token via the Admin API which was undocumented at the time. I did guest post for you on that after chatting to support and I see you have documented it now.
One remaining issue there is you recently rate limited the Management API which leaves us in a bit of a dodgy position when getting provider tokens. As a serverless app I don’t really want to cache it in external storage.
One thing I need to do an I do not see documented at all is how to handle refresh tokens with gmail (and other providers) My architecture is SPA front end that calls the hosted Lock pages [1] and with a node back end. The front end logs in and the back end gets the google token. You quite clearly and sensibly state SPAs should not store refresh tokens (well at least in one of several places where they are mentioned). YOu docement ways to get Refresh tokens but the exact architectural context is not always clear.
So how do I improve the user experience so they don;t keep needing to log in when the shortlived access token expires. It will no doubt involve the backend getting a refresh token, but I could not find an example that obviously fits my architecture. Plus, again. as a serverless i’d need ot cach it somewhere - where would be good? Probably the Auth0 User DB.
In general your docs are fantastic. It’s great that you continuously improve them even if that equires frequent re-reads to check for new stuff. One comment is I think I find some topics listed in various places with different emphasis or details and that gets confusing. For example, Lock, AuthJS Hosted pages, custom hosted pages have very similar docs and overlap in ways that can get missed or cofuse and some assertions only apply to some contexts. I’m not complaining; I understand it’s a touch job
Thanks again for a great service and support (and I’m not even paying, yet).
Oh the code links I forgot to add (in case they are of use)
Front : aim-web-app/auth.js at master · AlwaysInMind/aim-web-app · GitHub
back: aim-web-app/api/src/providers/auth0 at master · AlwaysInMind/aim-web-app · GitHub
Hosted: aim-web-app/hostedAuth0.Login.html at master · AlwaysInMind/aim-web-app · GitHub
Oh, One final point that would benefit form guidance - how to best alert the user of token expiry. Should it be a async user prompt or as my code does at the moment just check on an API call? This is a design decision but very closely tied to your topic of Auth
OK, another final point - the docs demonstrate in several places the Implicit Grant type for JS clients, yet many sources, including this - What is the OAuth 2.0 Implicit Grant Type? | Okta Developer say that is bad, for good reasons. This impacts me as I need to get a refresh token which even you say is not compatible with the Implicit grant
Can you PLEASE clarify this?
Thanks and sorry for adding so many issues
Thank you so much for taking the time to share this with me, and with such great detail! I am happy to hear you describe the docs (in general) as fantastic. We are also able to achieve this by great feedback from users like yourself! I am going to pass on the feedback, especially as you mentioned with regards to refresh tokens, using the Google API and with your use case of implementing an SPA with hosted pages and a node backend (thank you so much for all the links too!) and discuss further on ways users, like yourself, can implement architecture well and in ultimately be able to improve user experience. I agree with you that currently there can be various places with different emphasis or details which leads to confusion.
To your final point, I would say that across the board (not just at Auth0) we can work on defining the circumstances in which it makes sense to adopt certain types, the limitations, and everything in between!(as mentioned in the article you linked).