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
