We have 2 GraphQL urls that uses the same OAuth 2.0 authentication. I have it set up where you can authenticate to one but then you have to authenticate to the other as well because I can't change the base URL when I have it saved as a resource. Has anyone else experienced this and if so, what was your workaround? I don't want to make the user authenticate twice.
Hey @Daniel_Ramalhosa! Unfortunately this isn't currently supported each authentication token is saved per user per resource. We do have an internal request logged for this, and I've bumped it with your request as well. We can update you here as we have any new information to share.
I just checked and it seems that this feature request had been moved to our engineering team's backlog.
However, it was recently moved to a new specialized 'resource auth' team from our core data team, which gives me hope that this will be but on their roadmap.
I also just added in your +1 to the ticket's thread which will give it more weight in being prioritized. I appreciate your patients on this as we work to build out a robust solution that will both meet security standards and also enable teams to develop without having to spend too much time authing and re-authing in to use resources.
I had a thread from another user where they use Oath 2.0 to give permission to an app as opposed to an app user which helped them set up their auth flow set up.
Might be worth checking out, although their solution is for a Microsoft service.
So does this mean that if we consume GraphQL and REST resources from the same system sharing the same authentication token per user, our users are going to have to perform the same login for each resource ? This would be a little counter productive.
Unfortunately yes, you are correct. The resources are currently not able to communicate with each other to check and see if there is another resource that uses the same end point/system, and if this has been validated and received an unexpired auth token that can be re-used.
This is currently a feature request so I can add a +1 for you to this ticket and keep you updated on any news from our engineering team. I agree this is redundant, as it seems obvious that two resources are getting data from the same source. Resources were built with a 1-to-1 use case in mind
Silver lining is this does ensure security for the resource. I would recommend using one protocol as much as possible.