<div dir="ltr"><div><br></div><div>Copied the following from a comment on the ticket:<br></div><div><blockquote><br>> How safe is this?
</blockquote>
<p>I guess I’d say that it’s safe enough so as to not warrant making breaking changes to the protocol. Noting also that <a href="https://bitbucket.org/openid/mobile/issues/146/client_notification_token-seem-redundant" rel="nofollow">https://bitbucket.org/openid/mobile/issues/146/client_notification_token-seem-redundant</a> had some folks specifically wanting the callback to be able to be protected by a client-supplied Bearer token.</p>
<p>An internal API that’s accessible from the AS but not the client 
would need to exist. That API needs to be RFC 6750 OAuth protected and 
the client needs to somehow be able to obtain an access token that would
 be accepted for access to the internal API. The API would need to 
accept a POST with JSON like either</p>
<div class="gmail-codehilite"><pre><span></span>{ "auth_req_id": "..."}
</pre></div>


<p>or </p>
<div class="gmail-codehilite"><pre><span></span>{ "auth_req_id": "...", "access_token": "...", "token_type": "Bearer", "expires_in": ..., "id_token": "..."}
</pre></div>


<p>that would be syntactically valid for the API and result in something
 happening that a malicious client would have some incentive to have 
happen. </p>
<p>The malicious client also needs to know about this internal API and 
to have its backchannel_client_notification_endpoint point to said 
internal API. This adds some traceability and accountability to the 
potential attack - basically the admin of the  client has to register 
their malicious intent with the AS, which is a further disincentive to 
attempt something. </p>
<p>All in all, it seems quite unlikely that there’s something exploitable.</p>
<p>I admittedly have some bias here because we’ve already got a CIBA 
implementation in product. But I don’t think we are alone in that. And I
 don’t think the cost/impact of making a change here is warranted.  </p></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 5:58 PM james_manger <<a href="mailto:issues-reply@bitbucket.org">issues-reply@bitbucket.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">New issue 179: Bearer token on client notification<br>
<a href="https://bitbucket.org/openid/mobile/issues/179/bearer-token-on-client-notification" rel="noreferrer" target="_blank">https://bitbucket.org/openid/mobile/issues/179/bearer-token-on-client-notification</a><br>
<br>
James Manger:<br>
<br>
Client Initiated Backchannel Authentication Flow \([CIBA](<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_mobile_src_master_openid-2Dclient-2Dinitiated-2Dbackchannel-2Dauthentication-2Dcore.xml&d=DwMFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0&m=ql-nK6mmIvDg6mArTQUTYT46P4HOR3uFOtojJyL_kgg&s=ByYUsMqM_QTVMSONa26pGvDv20K1Clut11rKkGlYHso&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_mobile_src_master_openid-2Dclient-2Dinitiated-2Dbackchannel-2Dauthentication-2Dcore.xml&d=DwMFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0&m=ql-nK6mmIvDg6mArTQUTYT46P4HOR3uFOtojJyL_kgg&s=ByYUsMqM_QTVMSONa26pGvDv20K1Clut11rKkGlYHso&e=</a>)\) in Ping or Push modes involves an OpenId Provider POSTing to a client-registered address \(`backchannel_client_notification_endpoint`\) with a client-supplied Bearer token \(`client_notification_token`\).<br>
<br>
How safe is this?<br>
<br>
If a malicious client registers a web address internal to the OP it might trick the OP into calling an internal API. This is a common risk to callback scenarios, and is sort of covered in the Security Considerations that says “the OP SHOULD ensure that the "`backchannel_client_notification_endpoint`" configured at registration time is in the administrative authority of the Client”. Though I’m not sure how easy it is to achieve this \(you presumably have to check the IP addresses the endpoint resolves to at runtime, as opposed to just a registration-time check\).<br>
<br>
Using a client-supplied Bearer token seems to make this worse. Now a malicious client might trick the OP into calling APIs that require authentication.<br>
<br>
Getting an access token from party A to use when calling party B is almost standard OAuth. But it is usually a client accepting an access token from an OP the client has explicitly chosen to trust & register with. Whereas in the CIBA situation, the OP is accepting an access token from the client. But OPs don’t choose clients quite like clients choose OPs.<br>
<br>
One alternative design would be to use the client\_notification\_token as a querystring parameter on the callback: `POST <backchannel_client_notification_endpoint>?notification=<client_notification_token>`. It is only moving a client-supplied value from the `Authorization` HTTP header to the URL, but that alone should prevent attacks on APIs requiring authentication.<br>
<br>
Another alternative would be to require the `backchannel_client_notification_endpoint` to have the form `https://`_host_`/.well-known/oauth-callback/`_label_. That should make it much harder to exploit the callback for an attack, but at the cost of imposing structure on clients, and you might need rules limiting redirects to the same host.<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net" target="_blank">Openid-specs-mobile-profile@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><br>
</blockquote></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>