OpenID Connect with custom protocol handlers in browser

Sun Jan 20 00:39:50 UTC 2019

I still do not grasp the problems properly.

1)  I did not quite get the privacy problem. Could you explain it a bit
more fully?

2) Why two full redirects always?

3) OIDC dies use custom scheme for Self-issued OP. Have you checked that?

2019年1月20日(日) 0:30、senya さん（senya at riseup.net）のメッセージ:

> Hello!
>
> I want to say it just in case that I still don't have a solution to the
> problem I described in the above messages, so any suggestions are welcome.
>
> senya
> 25.12.2018 11:01, senya пишет:
>
> Oh, I see. So It's possible that AccountChooser does the server resolution
> even when this server was never known before by the authorization client?
> Because you wrote
>
> > AccountChooser presents the list of IdPs that the user has used against
> the domain and let her chose it
>
> And I understood that like I have to discover the IdP in advance.
>
> I think you understood my use case correctly.
>
> Well, the problem with the solution you propose (with AccountChooser) is
> that I have to implement some discovery-specific support on the diaspora
> site. The way the custom protocol handlers work, the authorization client
> can redirect to the custom protocol address from the login page (e.g. the
> AccountChooser). And in order to use this to resolve the remote host
> (diaspora) the IdP has to redirect it back to the original service. So when
> I redirect to "web+diaspora://authenticate" from the AccountChooser in
> order to resolve the target host I'll have to redirect back from diaspora
> to the URL of the authorization client with the host name in the request
> parameters. And only after that I can do the OIDC authorization flow.
>
> Besides the fact that this way I'll have two redirect-callback rounds
> between the same two services, it also has some privacy issues, because
> implementing an endpoint which unconditionally redirects back and telling
> your diaspora server host name can be used to identify the host name even
> when user doesn't want it. This issue can be solved by asking the user at
> the diaspora site something like "Do you want to tell example.com your
> host name?" but this would also mean that the user will be asked twice:
> once for the host name and second time for the OIDC authorization
> permission which is a terrible UX.
>
> That's why I looked at the "implicit registration flow" which actually
> combines this two things into one redirect-callback round: it redirects to
> the custom protocol URL and then goes back to the authorization client with
> the authorization response. If the user refused the authorization we can
> redirect without telling the hostname which solve the privacy concern.
>
> Thanks for the detailed response, though!
> 25.12.2018 10:13, n-sakimura пишет:
>
> Hmmm. Then I am not understanding your use-case properly.
>
> What I understood was as follows:
>
>
>
>    - There is a diaspora user who wants to login to a service.
>    - However, diaspora being distributed, there has to be a way to find
>    out which server the user is using.
>
>
>
> So, that is the objective, right?
>
>
>
> Your proposed solution to it is to
>
>    - Utilize a custom protocol handler so that the user can be redirected
>    to the service.
>
>
>
> Is this correct?
>
>
>
> If so, my next question is why does it not suffice for the site to find
> out the diaspora server URL using AccountChoser? Once the client gets the
> address of the diaspora server, it can register itself to it and start the
> standard OpenID Connect flow. What is the reason that this does not work?
>
>
>
> Cheers,
>
>
>
> Nat Sakimura
>
>
>
> *From:* senya <senya at riseup.net> <senya at riseup.net>
> *Sent:* Tuesday, December 25, 2018 4:12 PM
> *To:* n-sakimura <n-sakimura at nri.co.jp> <n-sakimura at nri.co.jp>; Nat
> Sakimura <sakimura at gmail.com> <sakimura at gmail.com>
> *Cc:* openid-specs at lists.openid.net
> *Subject:* Re: OpenID Connect with custom protocol handlers in browser
>
>
>
> Yeah, but that's not what I want.
>
> 25.12.2018 9:06, n-sakimura пишет:
>
> AccountChooser presents the list of IdPs that the user has used against
> the domain and let her chose it.
>
> Then, the client receives the IdP that the user has selected so that the
> normal federated login can be done.
>
>
>
> Cheers,
>
>
>
> Nat
>
>
>
> *From:* specs <openid-specs-bounces at lists.openid.net>
> <openid-specs-bounces at lists.openid.net> *On Behalf Of *senya
> *Sent:* Tuesday, December 25, 2018 3:44 PM
> *To:* Nat Sakimura <sakimura at gmail.com> <sakimura at gmail.com>
> *Cc:* openid-specs at lists.openid.net
> *Subject:* Re: OpenID Connect with custom protocol handlers in browser
>
>
>
> Hello, Nat.
>
> Thanks for the link, but however I can't see how it overlaps with my use
> case. AccountChooser / OpenYOLO seem to describe something like credential
> managers, while I want to implement sign in with an authentication
> provider. It's like "Sign in with Facebook", but with diaspora* social
> network instead. The only difference is that diaspora* social network is
> federated, therefore there is no single entry point like "facebook.com"
> to send authentication request. This is the problem that I'm trying to
> solve. I can't see how the specifications you've referenced can help, but
> maybe I'm just missing something?
>
> 24.12.2018 4:49, Nat Sakimura пишет:
>
> TL;DR but your usecase seems to somewhat overlap with AccountChooser /
> OpenYOLO. Have you checked them?
>
>
>
>
> https://openid.net/wg/ac/
>
>
>
> Cheers,
>
>
>
> Nat
>
>
>
> 2018年12月24日(月) 3:15、senya さん（senya at riseup.net）のメッセージ:
>
> Hello!
>
> I'm trying to figure out if it is possible to implement OpenID Connect
> client authorization using a custom protocol handler registered by a
> user in browser.
>
> I'm a software developer and I'm researching the possibility of
> implementing "sign in with diaspora*" feature for 3rd party websites to
> authenticate with  diaspora* federated social network accounts.
> Diaspora* supports OIDC with the Dynamic Client Registration extension.
>
>
> Imagine there is a federated web service, which has different web entry
> points. Imagine that this federated service supports custom protocol
> handler. For example diaspora* supports registering `web+diaspora://`
> protocol handler using `registerProtocolHandler`
> [
> https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler
> ]
> browser API call.
>
> Each user has a specific entry point to this federated service, i.e. a
> website where the user has login credentials. Users can register a
> custom protocol handler for their entry points and when the user follows
> the custom protocol link, the link will be opened on the correct web
> site for this user. The login credentials represent the user's identity
> in the federated service.
>
> My question is: whether it is possible to use OpenID Connect to
> implement "sign in with" feature for 3rd party clients to allow users to
> sign in using the user's federated identity with using the custom
> protocol handlers to discover the entry point?
>
> I did some research, but I didn't find an answer.
>
> What I expect is that when a user requests "sign in with diaspora*"
> button at the 3rd party web site, the browser redirects this request to
> the custom protocol URI, which is resolved by the web browser and opened
> on the proper federated service node, where the authorization will
> happen and the redirected back to the 3rd party site using the
> `redirect_url` according to OpenID Connect.
>
> So the main difference from most of the OpenID Connect authorization
> providers is that the real address of the authorization providers is not
> known in advance. However we suppose that the user has registered a
> custom protocol handler in their browser. If we use the custom protocol
> link at the authorization phase, then the user's web browser will
> redirect the request to the correct web node. The first problem here is
> that you can't use a preshared secret to identify the 3rd party site
> because the nodes are not predefined.
>
> I discovered the "OpenID Connect Federation"
> [https://openid.net/specs/openid-connect-federation-1_0.html]
> specification draft which covers so called "Implicit registration". This
> allows to register the OIDC client at the time when the authorization
> request is made. This partially solved this problem. So when OIDC client
> uses a custom protocol URI as an authorization endpoint, the
> authorization provider will receive this request and then discover the
> OIDC client using the dynamic registration protocol.
>
> So for example when you push the "sign in with diaspora*" button you're
> being redirected to `web+diaspora://authenticate?authorization_params`
> which is resolved for you into the
> `
> https://your-federation-node.tld/link_handler?url=authenticate?authorization_params`
> <https://your-federation-node.tld/link_handler?url=authenticate?authorization_params>
> URL which is then requested and upon the request the original OIDC
> client is being discovered.
>
> By using this technique I managed to pass the authorization phase.
> However there another problem arose. I don't know how is it possible to
> pass the real host name of the OIDC auth provider back to the OIDC client.
>
> In a simple setup when authorization is successful authorization result
> is a code. However in my example, if we respond to the OIDC client with
> a code, the OIDC client will not know where this code came from. This is
> because the authorization request was sent to the custom protocol URI,
> not the real URI. The only source of the information here is HTTP
> referrer of the authorization callback which cannot be relied upon.
>
> I found this document
> [
> https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document
> ]
> which describes replying to authorization request using a JWT token
> which includes the `iss` (issuer) field, which can be used to identify
> the actual node of the federated service. However the same document states:
>
> > Assumption: the client remembers the authorization server to which it
> sent the authorization request and binds this information to the user
> agent.
>
> > The client obtains the iss element from the JWT and checks whether its
> value is well known and identifies the expected issuer of the
> authorization process in examination. If the check fails, the client
> MUST abort processing and refuse the response.
>
> However when combined with the implicit registration the authorization
> server is not known at the point when we send the authorization request.
> We can't remember the server at the request time because we don't know
> the server and therefore we can't validate the response. This means that
> it is not possible to use this JWT token authorization response along
> with the implicit client registration which makes it impossible to
> implement it without breaking the protocol. Did I get that right?
>
> Is there a way to implement the described feature and remain in comply
> with the OIDC protocols?
>
> Can JWT authorization response can be used in a combination with the
> implicit client registration from OIDC Federation?
>
> With best regards,
>
> Senya.
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
> _______________________________________________
> specs mailing listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20190120/a91f7e24/attachment.html>