[Openid-specs-mobile-profile] Issue #179: Bearer token on client notification (openid/mobile)

[james_manger]

New issue 179: Bearer token on client notification
https://bitbucket.org/openid/mobile/issues/179/bearer-token-on-client-notification

James Manger:

Client Initiated Backchannel Authentication Flow \([CIBA](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=)\) 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`\).

How safe is this?

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\).

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.

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.

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.

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.