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]> *On Behalf Of *senya > *Sent:* Tuesday, December 25, 2018 3:44 PM > *To:* Nat Sakimura <[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] > <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
