<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello, Nat.</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?<br>
</p>
<div class="moz-cite-prefix">24.12.2018 4:49, Nat Sakimura пишет:<br>
</div>
<blockquote type="cite"
cite="mid:CABzCy2ADtsj3dxDfahaGkOhNLhEnw86Jf_t0wmpas7yYmC1o2Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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
face="roboto, helveticaneue, arial, sans-serif"
color="rgba(0, 0, 0, 0.870588235294118)"><span
style="font-size:16px"><a
href="https://openid.net/wg/ac/"
moz-do-not-send="true">https://openid.net/wg/ac/</a></span></font><br>
</span></div>
<div dir="auto"><span style="background-color:rgb(255,255,255)"><font
face="roboto, helveticaneue, arial, sans-serif"
color="rgba(0, 0, 0, 0.870588235294118)"><span
style="font-size:16px"><br>
</span></font></span></div>
<div dir="auto"><span style="background-color:rgb(255,255,255)"><font
face="roboto, helveticaneue, arial, sans-serif"
color="rgba(0, 0, 0, 0.870588235294118)"><span
style="font-size:16px">Cheers, </span></font></span></div>
<div dir="auto"><span style="background-color:rgb(255,255,255)"><font
face="roboto, helveticaneue, arial, sans-serif"
color="rgba(0, 0, 0, 0.870588235294118)"><span
style="font-size:16px"><br>
</span></font></span></div>
<div dir="auto"><span style="background-color:rgb(255,255,255)"><font
face="roboto, helveticaneue, arial, sans-serif"
color="rgba(0, 0, 0, 0.870588235294118)"><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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">specs@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>