VueJS SDK call to app/me endpoint failing with 401 after upgrade to latest version of FusionAuth
-
We have a complex flow authenticating between two of our systems. This has been working fine since early this year, but since we upgraded to FA 1.69.x our authentication flow is failing with a 401-Unauthorized beiing returned from the app/me endpoint which is called by the VueJS SDK to retrieve info about the currently logged in user. Here is our cross-system auth flow.
User is authenticated and logged into System A (this system does not use FusionAuth for authentication). User wishes to access System B.
1 - System A mints and signs a new JWT (signed with RSA private key unique to Sys !).
2 - System A then opens a new browser tab pointing at HTTP endpoint in System B providing the newly minted JWT as a query parameter
3 - System B uses FusionAuth Reconcile JWT API to validate the provided JWT using the corresponding RSA public key and an External JWT Identity Provider. This step works fine....JWT validates and the Reconcile API call creates the user if they do not exist and returns FusionAuth access and refresh tokens correctly.
4 - System B then sets appropriate FusionAuth cookies (app.at, app.rt, app.app.at_exp, access_token and refresh_token) and sends back a 302 redirect to a UI-related System B endpoint.
5) The users browser receives the 302 and cookies correctly and calls the VueJS-based UI endpoint, sending the set cookies.
6) The VueJS app using the FusionAuth VueJS SDK calls the FA app/me endpoint correctly including all of the set cookies (app.at, app.rt, app.app.at_exp, access_token and refresh_token).
6) app/me endpoint/API returns a 401 - Unauthorized, even though the access and refresh tokens sent (obtained in step 3 using Reconcile JWT API) are valid and user is logged in.
7) System B UI app basically blocks and returns nothing at this point since VueJS SDK thinks user was not valid. Note: our app does not redirect to a FusionAuth login page at this point, like it does if a user tries to log in directly to the System B app, that is, not using the Sys A -> Sys B auth flow described above.Steps 6 & 7 worked fine in an earlier version of FusionAuth (I think 1.47.x), but are broken in 1.69.x. We've tried all sorts of permutations but nothing is working at this point.
Can we get a detailed description of what the authorization requirements are for the app/me API endpoint with respect to what cookies it requires and what might be causing it to return a 401 all of a sudden?
Our app is time sensitive and life-critical (organ transplant) so could use some assistance in trying to resolve this issue quickly. We do have a paid license for FA.
Thanks!
-
In reading through this post, one of the first things that jumps to mind for me is that between those versions of FA, DPoP was introduced into both FusionAuth and the SDKs.
When first using DPoP in the SDKs (I did it in React), I ran into 401s for /app/me due to not running the requests with the additional DPoP headers.
Depending on your use case, it might make sense to switch from /app/me to using the userInfo property that comes from the SDK.
import { useFusionAuth } from "@fusionauth/vue-sdk"; const { userInfo, } = useFusionAuth();userInfohas most (maybe all) of what's available on /app/me and is also a more efficient fetch for it. -
We are not using DPoP at all, and the app/me call is being made transparently by the FusionAuth Vue SDK, so is not something we can change. That is the default when setting up the VueJS SDK.
I've isolated this to the upgrade to 1.60.0. It has the issue. 1.59.1 works fine.
I suspect it's due to the new tty claim that is included in the at and idt tokens, which did not exist before.
The external JWT reconcile API only returns at and rt tokens. It does not return an idt. So we were setting the at value for the idt cookie. But now that the two tokens can be differentiated, I suspect that this causes the issue.
Was trying to use the Hosted Backend app/refresh API to get refreshed tokens, including an idt, but that is returning a 403-Forbidden for some reason. Documentation on what is required for that API call is rather sparse Says it needs the app.rt cookie, which we have set...but seems it needs more.