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

Wed Jan 18 18:11:36 UTC 2023

Hi George,

Thanks for passing your web session bootstrap draft. It proves this was 
in need of a solution 10 years ago and still is :)

Let me know if I got this correct about the web session bootstrapping:

  * The client passing the bootstrap-token to the web session endpoint
    at the AS establishes a session (cookie) for the token subject (the
    user), without any user interaction.

  * The AS then redirects the brower to dest_url, i.e. the web app

  * The web app would then make an authZ request to the AS, but because
    we'll now have an AS session for the user, the login prompt will be
    skipped and the client web app will be able to get its tokens
    without further user interaction (okay, assuming explicit consent).

Coming back to the native SSO flow, I was thinking that the 
device_secret could be used to link device related context, i.e. a 
browser fingerprint. So when the handover token is generated, this 
context will serve the OP later in the browser based flow to check that 
the device wasn't changed.

But there are issues with the browser fingerprinting:

  * If the original authZ request to get the device_secret is far in the
    past, the user may have updated their browser or browser settings,
    or even switched to a different one, which will break the
    fingerprint comparison at the OP. Depending on how this is seen, it
    may be a sought effect.

  * Browser fingerprinting has issues on its own, being bad for privacy
    it may not be such a good idea using it, and I suppose browsers will
    eventually seek to suppress it.

One crude way to bind the browser session to the device is to record the 
client's IP address in the issued handover token. When the token gets 
consumed at the OP the browser IP address will be checked against the 
one in the token. Presuming the two events are close in time, it should 
be unlikely that the device's IP address changes between the token issue 
and its use. So this might work as a sort of check. BTW, the session 
bootstrapping token could use the same technique.

I'm wondering what else can be done. The native SSO spec builds on the 
premise that the flow cannot rely on browser cookies or other state, 
correct?

Regarding the device_secret URN, the token exchange has examples how to 
register them in a spec:

https://www.rfc-editor.org/rfc/rfc8693#name-oauth-uri-registration

With servers which have the x-oath URN the new std URN could be added as 
an alias, so that both new and old clients would work.

Vladimir

Vladimir Dzhuvinov

On 17/01/2023 18:19, George Fletcher 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230118/4eaf538c/attachment-0001.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/20230118/4eaf538c/attachment-0001.p7s>