Learn how to build a secure Python AI Agent with Microsoft Agent Framework and FastAPI and use Auth0 Token Vault to securely connect to the Gmail API.
Read on here!
1 Like
Any questions? Any feedback? Drop your message here!
My Account API seems to be required. Could you update the blog post with this new requirements?
Thank you for highlighting this. Actually, the blog post was published when Auth0 for AI Agents was in Early Access, and some things changed when it became Generally Available.
I fixed the missing part about the My Account API. Thanks! 
1 Like
Great tutorial! However, I’m stuck on this error:
AccessTokenForConnectionError: Federated connection Refresh Token not found.
My setup:
-
Auth0 app has Token Exchange grant enabled, Refresh Token Rotation OFF
-
Google connection: Token Vault enabled, Offline Access checked, Gmail scopes added
-
Code uses connection_scope, prompt=consent, access_type=offline
Auth0 logs show successful Google login (type: s) immediately followed by feta error “Federated connection Refresh Token not found.”
Is there something specific that makes Auth0 capture Google’s refresh token into Token Vault? Feels like Google is authenticating but the refresh token isn’t being stored.
Hi @joao.d.oliveira,
Thank you for reading the article and trying the sample project.
Actually, the Offline Access on the Google connection should grant a refresh token from Google 
I assume you have already checked everything on the Google side following this document.
Also, you didn’t explicitly mention it, but I assume you have enabled and configured the My Account API as described here.
Please, double check and let me know if you have additional info.
Thanks for the swift answer!
I might be missing something, but I do believe I went diligently through the setup. I’m attaching screenshots of what I think are the most relevant configurations.
I’m wondering if there could be issues in the tenant account setup or the Auth0 ↔ GCP API linkage.
To help pinpoint the issue, I see Token Vault as a 4-step process:
-
Registration (user consent flow) —
Works. I see my app’s permission request and the user approves it. -
User creation in Auth0 —
Works. User is created in Auth0, I can re-login successfully. -
Credential storage —
Seems fine. Auth0 shows the user was created. -
Token retrieval from Token Vault —
Broken. This is where I get the Federated connection Refresh Token not found error.
I’d love guidance on how to debug step 4 specifically.
Additional observations:
-
Auth0 dashboard shows successful login, authentication, and user creation
-
Google Cloud Console shows no API Requests in my project’s metrics, however I do see OAuth token grant rate activity (grants occurring at the time of my login attempts). This suggests the OAuth flow itself is working, but something isn’t capturing/storing the refresh token.
-
When I start a fresh registration, I do see my Google project being used for the OAuth consent screen
This makes me think the issue is in how Auth0 handles/stores the refresh token from Google, rather than the OAuth flow itself.
Is there a way to verify that the refresh token is actually being captured and stored by Auth0 during the initial authentication?
Thanks!
Hi @joao.d.oliveira,
Thanks for the additional details and for your patience.
I see you also opened an issue on the sample project and the explanation given by my colleague. Unfortunately, this blog post was written when Auth0 for AI Agent was in beta, and a few things have changed since then. While AI apps using the AI SDKs for LangGraph and LlamaIndex work seamlessly, for the MS Agent Framework (which doesn’t have a dedicated Auth0 AI SDK currently), I need to adapt the code. Just to let you know that I’m working on it.
Thanks again for your patience.
The blog post has been updated!
It uses the new settings for connected accounts and handles the AccessTokenForConnectionErrorerror.
Thank you for raising this issue and for your patience
Thanks Andrea — and apologies for the silence, I was on holidays.
Also, thanks again for the great article and for updating the post to use the new connected accounts settings and handle the AccessTokenForConnectionError.
Quick update: I got my setup working and Token Vault is now behaving as expected — I’ve been using it successfully.
Best of luck!
Joao
1 Like
Hi Andrea! Is there an updated library to handle connected accounts flow for Django? I’m analyzing auth0-fastapi library. Look at this. This is not supported by authlib which is recommended by the current Django documentation. Is that true?
I have another question. We can’t initiate the connected account flow right away because we need a user access token with the proper scope, right?
That means we always have to start the authorization code flow without the connected account first. Then, once that step is finished, we can trigger the connected account flow. Does that sound right? Only when this last step is concluded I’m able to get the access token from the connected account (i.e. Google).
I’m asking because it seems like the user has to grant permissions twice: once when they first log in, and again for the connected account flow. This gets even more complicated when you introduce account linking into the mix.
Hi @tinuvi.solutions, I’m not aware of a specific library for managing connected accounts in Django. Probably @jesstemporal knows more
You are right. The general flow is to authenticate first and then trigger the connected account flow.
Unfortunately, when using the same IdP to authenticate and get the connected account (as in the sample code in this blog post), you will be requested to grant permissions twice.
The authentication and connected account flows are separated because you can use different accounts. For example, you can authenticate with Auth0 and then connect your Auth0 account to your Google account.
This gets even more complicated when you introduce account linking into the mix.
The connected account flow replaces the account linking behavior for Token Vault from the Developer Preview.
Does it replace? Look at this scenario:
- You log in as email + password (
auth0provider) - Execute connected account flow with your Google account
- Log out
- Log in using the same Google account
- You end up with two users on Auth0 Dashboard (just check it at
https://manage.auth0.com/dashboard/us/YOUR_TENANT/users)
This means account linking is more vital than never. It avoids you paying two seats (MAU). Beyond that, you have to create very complicated infrastructure code to deal with this limitation.
1 Like
Hi @tinuvi.solutions for the Django app you’ll have to use the auth0-server-python package since this is the base SDK for all the Auth0 Python SDKs like the FastAPI one. I haven’t used Django in a while but expect you can use the MyAccountClient to reproduce the same behavior you saw in the FastAPI example you shared.
You are right authlib has all the OAuth support but the “My Account” API is not standard OAuth, its Auth0’s technology. 
Also thanks @Andrea.chiarelli for tagging me in.
1 Like
Thank you for helping me out! I’d actually already seen that library, but sadly, it doesn’t work for our setup. We use Django with Gevent (you can see why here), and that library requires asyncio. 
We ended up building our own library from scratch. Basically, we translated the auth0-fastapi and auth0-server-python libraries to create an opinionated way of handling account linking, connected account flows, and so on. My big concern is that the My Account API is not GA. 
I used to use Token Vault, but it changed so drastically that I had to focus on account linking instead—at least until I found a serious bug in it. Well, there is a specific topic for that.
1 Like
You are right on this scenario. I shared your feedback internally.
My reference was to the Token Vault account linking action used in the Developer Preview, which is no longer a functional way to obtain tokens for another account now.
2 Likes
We just open-sourced our library. Check it out here:
1 Like