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

[George Fletcher]

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230117/f0ba961d/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230117/f0ba961d/attachment-0003.html>