login the user - only the user:me scope is required for that
request additional rights e.g. to create issues/pages
However it seems that when the user logs out and in again, and on login we only request the user:me scope, ALL PREVIOUS SCOPES are removed. Since we cannot know if a user only want’s to login or he/she wants to give additional rights, this means that the user must grant all scopes on every login.
Is this the expected behaviour? How can we realise a “Login with Atlassian” with minimal scopes (which does not remove any previously granted permissions/scopes)?
Sorry for the delayed follow up. If you’re still facing issues with your 3LO app I do have a suggested approach for you.
As part of the authorization URL you can define what scopes you wish to consent for, you can then exchange the authorization code that’s passed there for a authentication token. These tokens are keyed to the scope you consented to so you can create a different token for a set of different scopes. This should then allow you to have two different flows, you just need to be aware of which token maps to which scopes on your end. You will also need to make sure you are using the rotating refresh tokens so you don’t need users to re-consent every time.
Hi @LukeD - thanks for coming back to this! Interesting approach, a bit more complex than expected but this could work. Generally, do you think there will be a more straight forward way to implement a “Login with Atlassian”? Similar to Google and other Identity Providers?
@LukeD@LukasGotter Would be great if Atlassian would support incremental authorization (via include_granted_scopes=true parameter). I believe it would fit the use case described above quite nicely. I have brought this up before with @Nir, but I am not quite sure if the feature request is tracked anywhere.
I am sure in many cases it would lead to a much better user experience because apps can request for minimal/essential scopes on installation and incrementally request more scopes as the user is using an app.
In our own app, we currently do not request delete scopes during app installation. In the rare case that an app admin wants to reset the app, we redirect them into another OAuth flow which includes the required delete scope (plus all original scopes). To have all original scopes in the authorization is not ideal but we found this to be still more user-friendly and secure than to request all scopes upfront.