We have had a security consultant make a recommendantion of an approach that does not follow the IEFF best-practice document (https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-6). I am looking for reasons why this is not recommended , ie what attacks are we opening ourselves up to.
Our set up is as follows. We have a number of JS applications
site1.domain.com site2.domain.com sub.site3.domain.com domain.com/site4
and a number of apis on seperate domains
api.site1.domain.com api.site2.domain.com api.sub.site3.domain.com api.domain.com/site4
And an authentication provider:
The suggestion is to use Authorization Code Grant Flow to return the cookies in a redirect from the apis.
So for an authentication flow, assuming the user had a valid auth cookie with the authenication provider, but not with the api, we'd have something like:
- User lands on site1.domain.com
- We make a request to api.site1.domain.com - this fails as no cookie is present
- We open an iframe to api.site1.domain.com which then redirects to our authentication provider.
- The bff then redirects back to site.domain.com with the cookie (samesite strict, http only, secure) in the iframe
- Api requests now work
For unauthenticated users we would then do the above redirects outside of the iframe.
The key concern I have is the js applications are on different domains (although sharing an origin) to the apis, and we may be lacking some of the security checks normally present in the fe flows such as code flow with pkce.