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