scope approval by 2nd app in mobile SSO (OpenID Connect Native SSO for Mobile Apps 1.0)
Issue #1070
open
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.
Comments (4)
-
reporter
-
In regards to the second app asking for a scope that was not requested by the first app the validation rules provide the following guidance…
The AS SHOULD verify that the scopes requested by the client in the token request (either default scopes or explicitly specified in the optional ?scope? parameter) do NOT require explicit user consent. If any requested scopes require explicit user consent the AS SHOULD fail the request and return an error of ?invalid_scope?.
Does that address the first issue?
I haven’t thought much about how an app running on a device would interact with a self-issued IDP. So there isn’t anything in this spec that addresses that use case. We can look to add it though.
-
reporter
Does that address the first issue?
Yes, but in that case, SSO won’t work well between apps which requires different scopes.
how an app running on a device would interact with a self-issued IDP.
In my implementation, all apps in the SSO circle are acting as self-issued IdPs using a shared key-pair.
In this flow, every app sends its own AuthZ Req to the Server-side IdP. And the Server-side IdP acts as an RP of the Self-issued IdP. So every time (except for the first time), the Server-side IdP can authenticate the user without explicit authentication ceremony, but can show consent screen per app & scope pair.
The sequence is attached below.
-
- changed status to open
To be discussed in Atlantic call.
- Log in to comment
On iOS, I'm (one of my clients is) using Self-issued IdP backed by vendor-wide shared keychain. In that case, 2nd app launches browser and the browser calls self-issued IdP instead of asking username & password.
On Android, I'm (one of my clients is) implementing similar mechanism backed by AccountManager. To be honest, I'm recently leaning to using WebAuthN in Chrome instead of Self-issued IdP in the Android world though.