Hi Shane, Agreed that CIBA is interesting in this context as an alternative to Device Authorization Grant.
Having the user initiate the request makes it harder for an adversary to manipulate the context, but I think it also shifts the point of attack. Now instead of getting the user to enter a user code, you have to get the user to enter their “user_hint”. This does put it on par with any regular phishing attack (at least the attack did not become easier). I do think mitigations on the back-end can help to further reduce the risks for both Device Authorization Grant and CIBA. Something else we may want to provide is some clear recommendations on when to use CIBA vs Device Authorization Grant etc (e.g. use CIBA if the user can provide input, use Device Authorization Grant if there is no input device). All of this may seem obvious for experts familiar with this space, but being explicit will help implementors who has expertise elsewhere. From looking at various protocols, whenever we attempt to use the user as a secure transport between their authentication device and the device on which the service will be delivered, we open an opportunity for social engineering attacks. Keeping that opening as small and constrained as possible and then mitigating against errors in judgement will help the overall security posture. Cheers Pieter From: Shane B Weeden <swee...@au1.ibm.com> Sent: Thursday 17 March 2022 21:21 To: Pieter Kasselman <pieter.kassel...@microsoft.com> Cc: oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits Isn’t this essentially what is mitigated in the FAPI-compliant OIDC CIBA by: 1. Requiring the client to initiate the flow with signed request parameters which include, via some hint, the resource owner for whom authentication is being requested 2. Requiring that the OP check that the resource owner approving the grant is the same as that the client associated with the request in step 1 I realise this requires that the client obtains an indication of the username of the resource owner up front to kick things off, but short of this I cannot think of any practical mitigation. On 18 Mar 2022, at 7:09 am, Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:pieter.kasselman=40microsoft....@dmarc.ietf.org>> wrote: ant problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
