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

[Tom Jones]

I demonstrated a way to be sure that a native app and web app were on the
same machine using localhost over 2 years ago. YouTube link below. What I
have not been able to do is create an e-e secure link between them on the
same device. That would not be too hard for browser guys to do; but they
have no incentive.

https://www.youtube.com/watch?v=Tq4hw7X5SW0

..tom


On Tue, Jan 17, 2023 at 8:19 AM George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Vladimir,
>
> This is great news regarding the implementation.
>
> Regarding the URN... I styled them after the URNs in the OAuth Token
> Exchange spec and yes, not registering an official one or using the ietf
> OAuth params in an oversight. It should be
> `urn:ietf:params:oauth:token-type:device_secret` and I will need to work
> with Mike on how that should get changed and what it might mean to existing
> implementations.
>
> I agree that authentication from a mobile app to web app is a common
> transition and another space for which there is little specification. I
> wrote a draft for this back in 2013 I believe:) The biggest issue is that
> if not using a WebView, there is no way to ensure the web request is coming
> from the same device where the mobile app is running. All parameters must
> be present on the URL and so it's possible for an attacker to start the
> flow on one device and the URL with all required parameters to another
> device for completion.
>
> That said, I'm definitely open to options for how we might specify a safe
> way to perform this step seamlessly. I'm attaching the old draft (v2 though
> I believe I did an v3 version but don't seem to have access to it anymore).
>
> Thanks,
> George
>
>
>
> On Tue, Jan 17, 2023 at 5:32 AM Vladimir Dzhuvinov <
> vladimir at connect2id.com> wrote:
>
>> 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
>>
>> ------------------------------
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230117/5fe5638a/attachment-0001.html>