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` 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
