scope approval by 2nd app in mobile SSO (OpenID Connect Native SSO for Mobile Apps 1.0)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Originally submitted by nov (Nov Matake) on 2019-03-15
In the mobile SSO spec, 2nd app uses token exchange.
In that flow, there is no chance to get user approval for the specified scopes.
Is it intended?
Isn't it better for the 2nd app to do front-channel communication?
e.g.,
In the case below, do you allow "email_management" scope to the 2nd app even though the 1st app didn't get the scope?
- A calendar app did the 1st OAuth dance w/ "calendar_managemen" scope, and saved device secret in the vendor key store.
- A mailer app comes later and uses the device secret to get access token w/ "email_management" scope.
Bitbucket status: open
Bitbucket origin: issue 1070
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the mobile SSO specification's token-exchange flow and the linked Bitbucket issue 1070. Examine how scopes are approved for the first and second apps, then determine whether the specification needs front-channel communication or another normative rule; done means the scope-approval behavior is resolved and documented with the example addressed.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, authorization, mobile-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100