OpenID Connect with custom protocol handlers in browser

Tue Dec 25 06:44:02 UTC 2018

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 さん（senya at riseup.net
> <mailto:senya at riseup.net>）のメッセージ:
>
>     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
>     specs at lists.openid.net <mailto:specs at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20181225/cad0c23c/attachment.html>