Hi team,
The auth provider I am adding to my manifest uses user_scope
as the URL param name for required scopes.
I am looking for a way to change the name of the scope
URL param that Forge generates when requesting auth from the provider.
I found that I could pass a bad scope to the provider and specify the required scopes as queryParameters
to the authorization
declaration of my provider, but this results in two problems;
- The list of scopes from the Atlassian screen is wrong
- Scope changes will not be informed to users to ask for a new authorization
Did anybody face this issue? Is there a possible solution?
Thank you
Hey @ibuchanan,
Do you know any Atlassian monitoring this channel that could point us in the right direction? We’re trying to develop a new Forge app and this seems to be a blocker for the moment.
Thanks for any help that you could provide!
Yves
I think even experts on this feature would need more information to understand the why & how of a work-around. It would help to know which auth provider, and specifically why they aren’t compliant with the OAuth 2.0 spec. Forge doesn’t provide a way to change this parameter because the spec for the authorization code flow is very specific about parameter names.
1 Like
Sorry if my original post wasn’t clear, I didn’t think specifying the external auth was necessary.
I am trying to add a Slack auth which has two query params available in the authentication action.
scope
for the bot user, and user_scope
for the user.
Our Forge app wants to interact as the user, so user_scope
is what I need to provide.
See this documentation for reference;
The scope
list requests scopes for your app’s bot user. If you have specific need for a user token (for example, so that you can act on behalf of a user), provide a user_scope
parameter with requested user scopes instead of, or in addition to, the scope
parameter.
To make the auth work in development, I had to provide the user scopes as a query parameter, and I am forced to provide a bot scope in the scope
portion of the manifest.
auth:
- key: slack-user-auth
name: Slack
scopes:
- 'chat:write'
type: oauth2
clientId: 'myappclientID'
remotes:
- slack
bearerMethod: authorization-header
actions:
authorization:
remote: slack
path: /oauth/v2/authorize
queryParameters:
user_scope: 'users.profile:read,chat:write,channels:history,channels:read'
The previous declaration works and ends up requesting the user’s permission for all scopes defined in the user_scope
parameter, with the addition of the bot scope, which makes no sense to the user at this point and in its usage. After all, it is a no-go because I do not want to bypass Forge’s core design for scope requesting.
@ibuchanan, please let me know if you need more context or if I missed anything!
Thank you!
1 Like
@PascalPerreault The way you put user_scope
under queryParameters
is correct.
Did you try to remove scopes
from the manifest? I check my app (not Slack) and deployment seems fine. The Slack consent flow will work as you expected?
1 Like
Hi @KhanhNguyen,
Thank you for your response. Here is the behavior of removing scope
from the manifest and publishing my app does;
-
The Atlassian page that displays when leaving Jira shows the scope I previously had in the scope
section of the manifest. IE it does not display the user_scope
I added in queryParameters
(which is understandable, but mildly concerning).

-
The Slack authentication page is built correctly with the scope
empty and the user_scope
filled with the queryParameters
I set in my manifest.
-
Changing the queryParameters
to request new scopes for the user and deploying again does not require an upgrade for the app - which to my understanding means there will be no validation of new scopes and invalidation of existing tokens for users. - And this is where I believe this is problematic. Don’t you agree?
My goal is basically to have the scope
’s behavior, but be able to specify another query parameter name for it.
I hope this helps!
Thanks for the additional context @PascalPerreault ,
the points that you have made are very valid; unfortunately, today, we don’t have any mechanism for you to configure the query param for which you request scopes. You can raise a feature request ticket here and upvote it.
As a workaround, is it possible for you to request both scopes under the provider’s scopes
config in the manifest and provide the custom query parameter? I understand that you will be requesting both bot and user scopes, but is this solution workable?
As an aside, adding scopes to your provider doesn’t actually trigger a major version upgrade for your app like it does for Atlassian scopes. There have also been some enhancements to the External authentication APIs lately that allow you to request credentials based on what scopes you are after you can also check what scopes are available already.
2 Likes
Hi @BoZhang,
Thank you for the confirmation. I will raise a request ticket like you suggested.
is it possible for you to request both scopes under the provider’s scopes
config in the manifest and provide the custom query parameter? I understand that you will be requesting both bot and user scopes, but is this solution workable?
My intention is to only request user_scope
so I think it will be fine.
adding scopes to your provider doesn’t actually trigger a major version upgrade for your app like it doesn’t for Atlassian scopes
Are you sure this is the case? In a recent update we’ve increased our Atlassian scopes and the publish to the marketplace caused a major version increase in our app. Doing the same in a dev environment requires a forge install --upgrade
.
If I change an auth scope, I get the same request to forge install --upgrade
after my publish in my dev environment. I cannot confirm if the version change is major when publishing to the marketplace as we are not ready to publish new auth provider scopes at this time.
For the other developers finding this thread, the issue I created can be found as FRGE-1396.
1 Like
Sorry, I made a typo, changing the Atlassian scopes required by your app will trigger a major version upgrade, but it won’t for your external auth provider.
2 Likes