<div dir="auto"><span style="color:rgba(0,0,0,0.87);font-family:roboto,helveticaneue,arial,sans-serif;font-size:16px;background-color:rgb(255,255,255)">TL;DR but your usecase seems to somewhat overlap with AccountChooser / OpenYOLO. Have you checked them? </span><div dir="auto"><span style="color:rgba(0,0,0,0.87);font-family:roboto,helveticaneue,arial,sans-serif;font-size:16px;background-color:rgb(255,255,255)"><br></span></div><div dir="auto"><span style="background-color:rgb(255,255,255)"><font color="rgba(0, 0, 0, 0.870588235294118)" face="roboto, helveticaneue, arial, sans-serif"><span style="font-size:16px"><a href="https://openid.net/wg/ac/">https://openid.net/wg/ac/</a></span></font><br></span></div><div dir="auto"><span style="background-color:rgb(255,255,255)"><font color="rgba(0, 0, 0, 0.870588235294118)" face="roboto, helveticaneue, arial, sans-serif"><span style="font-size:16px"><br></span></font></span></div><div dir="auto"><span style="background-color:rgb(255,255,255)"><font color="rgba(0, 0, 0, 0.870588235294118)" face="roboto, helveticaneue, arial, sans-serif"><span style="font-size:16px">Cheers, </span></font></span></div><div dir="auto"><span style="background-color:rgb(255,255,255)"><font color="rgba(0, 0, 0, 0.870588235294118)" face="roboto, helveticaneue, arial, sans-serif"><span style="font-size:16px"><br></span></font></span></div><div dir="auto"><span style="background-color:rgb(255,255,255)"><font color="rgba(0, 0, 0, 0.870588235294118)" face="roboto, helveticaneue, arial, sans-serif"><span style="font-size:16px">Nat </span></font></span></div></div><br><div class="gmail_quote"><div dir="ltr">2018年12月24日(月) 3:15、senya さん（<a href="mailto:senya@riseup.net">senya@riseup.net</a>）のメッセージ:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
I'm trying to figure out if it is possible to implement OpenID Connect<br>
client authorization using a custom protocol handler registered by a<br>
user in browser.<br>
<br>
I'm a software developer and I'm researching the possibility of<br>
implementing "sign in with diaspora*" feature for 3rd party websites to<br>
authenticate with  diaspora* federated social network accounts.<br>
Diaspora* supports OIDC with the Dynamic Client Registration extension.<br>
<br>
<br>
Imagine there is a federated web service, which has different web entry<br>
points. Imagine that this federated service supports custom protocol<br>
handler. For example diaspora* supports registering `web+diaspora://`<br>
protocol handler using `registerProtocolHandler`<br>
[<a href="https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler" rel="noreferrer noreferrer" target="_blank">https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler</a>]<br>
browser API call.<br>
<br>
Each user has a specific entry point to this federated service, i.e. a<br>
website where the user has login credentials. Users can register a<br>
custom protocol handler for their entry points and when the user follows<br>
the custom protocol link, the link will be opened on the correct web<br>
site for this user. The login credentials represent the user's identity<br>
in the federated service.<br>
<br>
My question is: whether it is possible to use OpenID Connect to<br>
implement "sign in with" feature for 3rd party clients to allow users to<br>
sign in using the user's federated identity with using the custom<br>
protocol handlers to discover the entry point?<br>
<br>
I did some research, but I didn't find an answer.<br>
<br>
What I expect is that when a user requests "sign in with diaspora*"<br>
button at the 3rd party web site, the browser redirects this request to<br>
the custom protocol URI, which is resolved by the web browser and opened<br>
on the proper federated service node, where the authorization will<br>
happen and the redirected back to the 3rd party site using the<br>
`redirect_url` according to OpenID Connect.<br>
<br>
So the main difference from most of the OpenID Connect authorization<br>
providers is that the real address of the authorization providers is not<br>
known in advance. However we suppose that the user has registered a<br>
custom protocol handler in their browser. If we use the custom protocol<br>
link at the authorization phase, then the user's web browser will<br>
redirect the request to the correct web node. The first problem here is<br>
that you can't use a preshared secret to identify the 3rd party site<br>
because the nodes are not predefined.<br>
<br>
I discovered the "OpenID Connect Federation"<br>
[<a href="https://openid.net/specs/openid-connect-federation-1_0.html" rel="noreferrer noreferrer" target="_blank">https://openid.net/specs/openid-connect-federation-1_0.html</a>]<br>
specification draft which covers so called "Implicit registration". This<br>
allows to register the OIDC client at the time when the authorization<br>
request is made. This partially solved this problem. So when OIDC client<br>
uses a custom protocol URI as an authorization endpoint, the<br>
authorization provider will receive this request and then discover the<br>
OIDC client using the dynamic registration protocol.<br>
<br>
So for example when you push the "sign in with diaspora*" button you're<br>
being redirected to `web+diaspora://authenticate?authorization_params`<br>
which is resolved for you into the<br>
`<a href="https://your-federation-node.tld/link_handler?url=authenticate?authorization_params" rel="noreferrer noreferrer" target="_blank">https://your-federation-node.tld/link_handler?url=authenticate?authorization_params`</a><br>
URL which is then requested and upon the request the original OIDC<br>
client is being discovered.<br>
<br>
By using this technique I managed to pass the authorization phase.<br>
However there another problem arose. I don't know how is it possible to<br>
pass the real host name of the OIDC auth provider back to the OIDC client.<br>
<br>
In a simple setup when authorization is successful authorization result<br>
is a code. However in my example, if we respond to the OIDC client with<br>
a code, the OIDC client will not know where this code came from. This is<br>
because the authorization request was sent to the custom protocol URI,<br>
not the real URI. The only source of the information here is HTTP<br>
referrer of the authorization callback which cannot be relied upon.<br>
<br>
I found this document<br>
[<a href="https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document" rel="noreferrer noreferrer" target="_blank">https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document</a>]<br>
which describes replying to authorization request using a JWT token<br>
which includes the `iss` (issuer) field, which can be used to identify<br>
the actual node of the federated service. However the same document states:<br>
<br>
> Assumption: the client remembers the authorization server to which it<br>
sent the authorization request and binds this information to the user<br>
agent.<br>
<br>
> The client obtains the iss element from the JWT and checks whether its<br>
value is well known and identifies the expected issuer of the<br>
authorization process in examination. If the check fails, the client<br>
MUST abort processing and refuse the response.<br>
<br>
However when combined with the implicit registration the authorization<br>
server is not known at the point when we send the authorization request.<br>
We can't remember the server at the request time because we don't know<br>
the server and therefore we can't validate the response. This means that<br>
it is not possible to use this JWT token authorization response along<br>
with the implicit client registration which makes it impossible to<br>
implement it without breaking the protocol. Did I get that right?<br>
<br>
Is there a way to implement the described feature and remain in comply<br>
with the OIDC protocols?<br>
<br>
Can JWT authorization response can be used in a combination with the<br>
implicit client registration from OIDC Federation?<br>
<br>
With best regards,<br>
<br>
Senya.<br>
<br>
<br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank" rel="noreferrer">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote></div>