Hello everyone,
Google Cloud OAuth consent screen docs (screenshot below) mention that you need to verify the domain associated with the redirect URI – which for Forge apps is https://id.atlassian.com/outboundAuth/finish.
Obviously Forge apps developers cannot verify ownership of atlassian-dot-com, but at the same time the Google Photos example Forge app uses a sensitive Google OAuth scope.
How should Forge app developers go about verifying ownership of atlassian-dot-com in the redirect URI?
Thank you
3 Likes
Hi @aponomarov - thank you for reporting this issue, I’m on the team that owns this feature and I can confirm that we’ve reproduced it and are looking into any guidance/workarounds we can provide. I don’t have any updates at this time but just wanted to assure you that this has been seen and is being looked into.
Hey again @aponomarov just wanted to thank you again for highlighting this, addressing this may be more difficult than foreseen and I can’t give you a timeline just now for when we could prioritise and fix it. As such we’ll be taking down this example for now until we can provide an example that doesn’t use sensitive Google scopes.
In the meantime, the only workaround I can suggest is for you to access these sensitive scopes via your own external server/domain and route the Forge requests through that. I’m aware this isn’t ideal and would involve a lot of extra work, but I wanted to float this as an option in the meantime as we may not be able to solve this on our end immediately.
1 Like
Hi @ChrisWilliams, thank you for getting back to me. I was able to find a less permissive OAuth scope and it looks like Google does not require domain ownership verification for non-sensitive scopes. With this post I wanted to verify if this is indeed the case, but it’s probably better checking with Google directly. Please don’t remove the Google Photos example app.
1 Like
Hey @aponomarov that’s good news, can I ask which scope you were able to find here? The intention was to take down the example and (in the short term) replace it with one that uses non-sensitive scopes.
@ChrisWilliams it’s /auth/drive.file. Full access to any file in Google Drive that was created by the app.
2 Likes
Thanks or sharing that @aponomarov - we’ll update the existing example to make use of a non-sensitive scope (probably https://www.googleapis.com/auth/drive.file) and also update the docs to highlight that sensitive scopes on Google aren’t currently supported.
Hello,
I am facing the same issue with a forge app when trying to use sensitive scopes on Google, just checking if this is still not supported or if there are any updates on that.
thanks,
Hi @MazenChmait_FusionTe - my understanding is that due to the domain verification process Google requires, we cannot support sensitive scopes as effectively we’d be telling Google that the app using the scope is the owner of our domain (atlassian.com).
My guidance on this front would be to seek out non-sensitive scopes such as the one shared in this thread. We do have an issue on our backlog for addressing the documentation gap - I’ll follow up with the responsible team to see if it could be prioritised.
1 Like
Hey @ChrisWilliams,
Just checking if the issue and documentation gap was addressed or not. Is there any plan to resolve Atlassian ↔ Google relationships on this matter or is using external auth with sensitive scope a dead end for the nearest future and we shouldn’t rely on it?
Welcome to the Atlassian developer community @Konstantin,
My short advice, don’t rely on Atlassian Forge external auth with Google’s sensitive scopes. The problem cannot be resolved simply between Atlassian & Google in a way that would allow you into that relationship.
What Google (and likely others to follow in the future) want to bolster is security weakness in OAuth when the client owner does not control the domain. The near-term, practical solution for Forge App developers would be to create your own Forge Remote, and have it own the auth with Google (domain + client id/secret). Hopefully, both the OAuth spec, and implementations will evolve to support protocols less dependent on the security of domain claims. But it will take years for specs & both Forge external consumer and Google as a provider to evolve.
1 Like
@ibuchanan , thanks a lot for reply, totally makes sense. We are planning to use Forge Remote and hope not to see any roadblocks there.
