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
