OpenID Connect with custom protocol handlers in browser
senya
senya at riseup.net
Sat Jan 19 15:30:37 UTC 2019
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>
>> *Sent:* Tuesday, December 25, 2018 4:12 PM
>> *To:* n-sakimura <n-sakimura at nri.co.jp>; Nat Sakimura
>> <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>
>> <mailto: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> <mailto:sakimura at gmail.com>
>> *Cc:* openid-specs at lists.openid.net
>> <mailto: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
>> <mailto: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 <mailto:specs at lists.openid.net>
>> http://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/20190119/6d18731f/attachment.html>
More information about the specs
mailing list