[Openid-specs-ab] openid-connect-native-sso 04 - token type URI, applying the SSO to web apps

[Vladimir Dzhuvinov]

Hi George,

After voting for the implementer's draft of the native SSO we now 
consider adding it in the open source Nimbus OIDC Java SDK we maintain.

We noticed the actor_token_type uses an x-oath URN instead of the common 
format of other registered token type URIs. I'm not sure if that was a 
missed artifact from an early spec or implementation, or is intentional:

"urn:x-oath:params:oauth:token-type:device-secret"

https://openid.net/specs/openid-connect-native-sso-1_0-04.html#section-4.1

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri


Some people who read the draft have faced the problem of integrating 
mobile and web SSO into one seamless UX. Say a user who is logged into a 
mobile app performs an action that opens a web page belonging to the app 
vendor. This will typically trigger a new OpenID auth request, and that 
is perceived as super bad and illogical UX. Handover between mobile and 
web app appears to be fairly common. Often it doesn't require the user 
to be authenticated at the target web page, but occasionally it does.

So, the idea why not adapt the native SSO flow, roughly as it is, to 
handle signing into a web app.

Here is one flow that is currently being considered:

  * It requires the native client to know the client_id of the web app.

  * It requires the web app to be a confidential client.

  * The native client makes a token exchange request, stating the
    client_id of the target web app in the "audience" parameter (this is
    not semantically correct, because the web app is not the ultimate
    consumer of the issued token) and the "requested_token_type" to
    indicate a new "handover" token. The native clients sends the ID
    token and device secret used in the native SSO token exchange.

  * The returned handover token will be encrypted by the OP to self (or
    will be a random string key pointing a DB record at the OP), and
    carry the end-user ID, her auth context (if any), and the client_id
    of the target web app.

  * The native app will open a web app link in the system browser,
    passing the handover token.

  * The web app will make a new _authenticated_ token exchange request,
    using the handover token to obtain an ID token and potentially
    access and refresh token. The OP will not release the requested
    tokens to the web app unless the client_id in the validated handover
    token matches the authenticated client (the web app).

    Another variant, if the web app doesn't support token exchange, is
    to pass the handover token in a login_hint of a standard prompt=none
    OpenID authentication request, and continue from there as normal.
    The handover token client_id will be checked when the client
    authenticates at the token endpoint. This variant could also work
    for web apps that are public clients (SPAs).


We are quite keen to support a flow that builds upon the proposed native 
SSO to link associated web apps. I wonder if you already considered 
something like this. And your general thoughts on using the native SSO 
flow to also cover web apps vs alternatives.


Vladimir

-- 
Vladimir Dzhuvinov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230117/be9002df/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230117/be9002df/attachment.p7s>