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 <[email protected]> > *Sent:* Tuesday, December 25, 2018 4:12 PM > *To:* n-sakimura <[email protected]>; Nat Sakimura <[email protected]> > *Cc:* [email protected] > *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 <[email protected]> > <mailto:[email protected]> *On Behalf Of *senya > *Sent:* Tuesday, December 25, 2018 3:44 PM > *To:* Nat Sakimura <[email protected]> <mailto:[email protected]> > *Cc:* [email protected] > <mailto:[email protected]> > *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 さん（[email protected] > <mailto:[email protected]>）のメッセージ: > > 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 > [email protected] <mailto:[email protected]> > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
