Hi everyone, The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract further explains that it "details the security considerations and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0.".
As such, detailing security considerations is important. I share the point of view that basing web applications on proven concepts is important. The approaches detailed in the document have all their advantages and disadvantages. There are 2 main approaches to browser-based applications security. One of them is to store security credentials at the frontend. The other one is to use cookies and a BFF. Though common practice, there is nothing fundamentally more secure about them in a demonstrable way. Different approaches, different characteristics and security assumptions. Nobody can prove that either approach is better, just that there are different concerns. Handling security in BFFs relies on cookies that cannot be read by the javascript application. This mechanism provides some reliable protection about the cookie itself that is used as a kind of credential to access confidential web resources. It obviously demands some additional layers in the flow (proxy or light server). You also need a mechanism to share session information, either at the server side, or for example by having the cookie itself hold that information. A bigger concern to me is that you basically give up standard mechanisms for securing the flow between the frontend and the backend: the security between the two is a custom solution (based on cookies, in a specific, custom way, this part being in no way OAuth or standard). This solves the problem by not using OAuth at all in the browser part of the application, basically making the client application purely backend. However, the fact that browser-based applications cannot be secured with OAuth isn't universally true, and strongly depends on one's definition of "secure", and basically comes down to what the security issue is. Storing tokens at the frontend has advantages: it solves my concern above about a standard based flow between the frontend and the backend. It's simpler from an operational point of view. And it's been used in the wild for ages. Both flows have been compromised numerous times. This doesn't mean they are not right by design, but that the specific security concerns have to be addressed. Now, the concerns we are really discussing is, what happens in case of XSS or any form of malicious javascript. In this case, for all known flows, session riding is the first real issue. Whether the injected code calls protected web resources through the BFF or using the stored tokens, is irrelevant: the evil is done. Seeing different threat levels between token abuse and session riding is a logical shortcut: in many cases, the impact will be exactly the same. Reducing the attack surface with a BFF or even a simple proxy is a possible but separate topic: this doesn't have to be linked to where tokens are stored. Alternatively, services that shouldn't be accessible could simply not be exposed, and token scope and audience must be well thought. As such, BFFs as well as frontend token storage, though different, are application design choices and have no demonstrable superiority from a security point of view. Still, it seems it matters to some people to not exfiltrate tokens in case of successful XSS. In the first instance, I don't share this need to protect short-lived tokens in a game over scenario, but the whole investigation of more secure frontend storage mechanisms started because some customers are concerned. We are in the realm of choice, not of provable security need, but it is still important to them. Documenting security concerns and possible solutions is part of the document. Where you store the tokens has an impact on how easy it will be for an attacker to exfiltrate them. Local or session storage is obviously not the best choice here, as injected javascript can easily access it. A service worker is an interesting place to store them, as it can additionally play the role of a front-end proxy that both holds the token securely, and securely proxy requests to the resource server. Besides, a track was started with Rifaat to initiate changes to the service worker specifications to make some things simpler. The point that the service worker solution isn't that widespread is indeed correct and should be addressed. I propose transparently mentioning that it is seen as a possible but uncommon storage mechanism. There should also be some explanation about other kinds of web workers, which are more commonly used but exploitable, so less secure when token exfiltration is a concern. The document isn't only about security best practices, though, but about security concerns. Implementations are explicitly out of scope. My conclusion is that, though we can surely make the document better, there is no all-encompassing solution. Similarly, BFFs are not a higher level of security for healthcare of banks, just a different solution. Service workers are still an interesting solution for people who absolutely want to secure tokens at the frontend, and as improvable as the document is, shouldn't be left out. About some specific concerns: > *While content injection attacks are still possible, the BFF limits the attacker’s ability to abuse APIs by constraining access through a well-defined interface to the backend which eliminates the possibility of arbitrary API calls.* Session riding is still the main issue and isn't addressed at all. If the intention here was to limit the number of exposed endpoints, the application can still be designed to either only expose what is needed, or put a proxy or api manager between for limiting exposition, unrelated to where token storage happen. *> No, because running a silent flow in an iframe typically uses a web message response. In essence, the callback is not the redirect URI, but a minimal JS page that sends the code to the main application context using the web messaging mechanism. The message will have the origin of the authorization server as a sender. * The iframe needs to get the auth code somehow, and that typically happens by setting its src to the auth endpoint, and having a redirect URI that points to that minimal js page. This would mean an attacker can change the redirect URI to be able to point to some custom js in the application, which is a whole different Philippe, I'm honestly quite skeptical about that attack, but it sounds interesting. Can you provide some details or a reproducer? Best regards, Yannick
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
