OpenID Connect with custom protocol handlers in browser

[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）のメッセージ:

> 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
> http://lists.openid.net/mailman/listinfo/openid-specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20181224/87f039e2/attachment.html>