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]> >> *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
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
