[Openid-specs-ab] "Backchannel" SSO for native apps

[George Fletcher]

We discussed this briefly during the last working group call and I was 
asked to share my thoughts...

The context is a mechanism to enable native app SSO across native apps 
by the same vendor. This is NOT about how to do native app SSO across 
app from different vendors.


I know this topic has come up in the past but I'm not finding anything 
written down. I thought that Google implemented cross-app "SSO" on iOS 
using a library at one time and also I believe on Android was allowing 
multiple apps from the same vendor to bootstrap from an id_token. Do we 
have any best practice in this regard?

My concern over just using the system browser is that a user could 
logout of their system browser session (i.e. clear the cookies) without 
invalidating the apps refresh_token meaning that SSO is lost for the 
next app (when maybe it doesn't have to be?).

I've been thinking about this a bit and am looking for feedback. My 
requirements of bootstrapping from an id_token issued to app A by app B 
are...
1. The session represented by the id_token must still be valid (means 
the id_token needs a session identifier in it which is useful for logout 
anyway)
2. The id_token can ONLY be shared among apps by the same vendor on the 
same device (meaning the id_token needs to be device bound in some way)
3. The AS must whitelist the client_ids that can share an id_token.
4. A new refresh_token for app B can only be issued if the requested 
scopes are implicitly allowed for that app. Meaning, if explicit user 
consent is required for a requested scope, the "bootstrap" MUST fail.

As for implementation...
1. When exchanging the code for tokens, the app passes an additional 
device_identifier value (could be IDFV on iOS, or strong random string 
and saved in the keychain)
2. The AS when issuing the id_token, adds a di_hash claim (in the same 
vein as at_hash) which is a function of the device_identifier. The AS 
also adds the session identifier claim to the id_token.

When App B wants to log the user in it...
3. Calls the /token endpoint (new grant type possibly?) and passes the 
id_token, client_id, scopes, and device_identifier
4. The AS first ensures the "session" is still valid based on the 
session identifier. Then it validates that the presenter of the id_token 
knows the correct device_identifier by taking the passed in 
device_identifier value and calculating the di_hash value and comparing. 
The AS also validates that App A and App B are allowed to share 
id_tokens. Finally, it validates that none of the requested scopes 
require explicit user consent.
5. If step 4 passes, issue new tokens with the audience of App B's 
client_id and set the expiry time of the refresh_token to that of the 
original "session".

Thoughts/security concerns/better ways to do this?

Thanks,
George