В OAuth для веб приложений традиционно существует 2 типа flow: Implicit Flow и Auth Code Flow, в первом случае токен возвращается напрямую в браузер юзера в параметрах url, во втором — требуется бэкенд для обмена кода на токены. Стандартные рекомендации — для обычных asp.net приложений Auth Code Flow т.к. есть секьюрный бэкенд, для SPA — Implicit Flow.
Проблема Implicit Flow в том, что он недостаточно безопасен (токен из парамеров урла может утечь хакеру несколькими способами), но это применялось т.к. другого пути просто не было. Сейчас (с появлением CORS) появился новый flow — PKCE, некоторый компромис между 1 и 2-м методами
Я никак не могу до конца понять, почему принципиально игнорировался тот факт, что "чистых" SPA не так и много, у них всегда есть свой бэкенд, и ничто не мешает имплементировать Auth Code Flow с его участием: первая часть flow выполняется в SPA, получив code тот перенаправляет его в свой бэкенд, который добавляет свой секрет и получает токен в обмен на код, после чего отдает его обратно в SPA. Таким образом нет проблем, от которых страдает Implicit Flow, и он более секьюрный чем PKCE т.к. используется секрет
В интернете не особо статей по этому поводу, единственный довод против который я нашел — это использование 2-х компонентов для единого flow, и я согласен с этим, но все-же хотелось-бы знать какие реальные проблемы для безопасности, за исключением идеологических, это может принести

Здравствуйте, Stalker., Вы писали:

S>Я никак не могу до конца понять, почему принципиально игнорировался тот факт, что "чистых" SPA не так и много,

Думаю, потому что развивается хипстерский serverless, где нет бэка, а есть anything as an service. Для быстрого статапчика это может оказаться вариантом.

вот тут обзор, покопайся, может чего найдёшь:

One question that would commonly be asked about making browser-based clients more secure is “what about code flow – why can’t we use that instead?”. It turns out code flow (by itself) was worse because 1) public clients don’t use a real secret to exchange the code at the token endpoint, so an attacker could just as easily steal the code to obtain the access token, 2) codes passed via the query string are sent to the server (whereas fragment values are not), so they would be exposed more than when using implicit flow, 3) the client is required to make more requests to complete the protocol for no additional security, and 4) to use the token endpoint the token server would need to support CORS, and CORS was not yet widely enough supported by browsers. At that time, the spec designers could not take a dependency on CORS thus they had to find an alternative.