<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.19
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:99.25pt 3.0cm 3.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext">AccountChooser presents the list of IdPs that the user has used against the domain and let her chose it.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext">Then, the client receives the IdP that the user has selected so that the normal federated login can be done.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext">Cheers,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext">Nat<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> specs <openid-specs-bounces@lists.openid.net>
<b>On Behalf Of </b>senya<br>
<b>Sent:</b> Tuesday, December 25, 2018 3:44 PM<br>
<b>To:</b> Nat Sakimura <sakimura@gmail.com><br>
<b>Cc:</b> openid-specs@lists.openid.net<br>
<b>Subject:</b> Re: OpenID Connect with custom protocol handlers in browser<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hello, Nat.<o:p></o:p></p>
<p>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?<o:p></o:p></p>
<div>
<p class="MsoNormal">24.12.2018 4:49, Nat Sakimura пишет:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">TL;DR but your usecase seems to somewhat overlap with AccountChooser / OpenYOLO. Have you checked them? </span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><br>
<br>
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><a href="https://openid.net/wg/ac/">https://openid.net/wg/ac/</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Cheers, </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Nat </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">2018<span lang="JA" style="font-family:"ＭＳ ゴシック"">年</span>12<span lang="JA" style="font-family:"ＭＳ ゴシック"">月</span>24<span lang="JA" style="font-family:"ＭＳ ゴシック"">日</span>(<span lang="JA" style="font-family:"ＭＳ ゴシック"">月</span>) 3:15<span lang="JA" style="font-family:"ＭＳ ゴシック"">、</span>senya
<span lang="JA" style="font-family:"ＭＳ ゴシック"">さん（</span><a href="mailto:senya@riseup.net">senya@riseup.net</a><span lang="JA" style="font-family:"ＭＳ ゴシック"">）のメッセージ</span>:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">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" 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" 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" 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" 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">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
</body>
</html>