в спецификациях OAuth без бутылки не разобраться, я когда изучал самая вменяемая документация была вроде у MS и Okta...
Что касается вопроса про "Authorization code with PKCE" - это невозможно изучать без отрыва от rfc8252, конкретно нас интересут section-7.2 :

rfc82527.2. Claimed "https" Scheme URI Redirection

Some operating systems allow apps to claim "https" scheme [RFC7230]
URIs in the domains they control. When the browser encounters a
claimed URI, instead of the page being loaded in the browser, the
native app is launched with the URI supplied as a launch parameter.

Such URIs can be used as redirect URIs by native apps. They are
indistinguishable to the authorization server from a regular web-
based client redirect URI. An example is:

https://app.example.com/oauth2redirect/example-provider

As the redirect URI alone is not enough to distinguish public native
app clients from confidential web clients, it is REQUIRED in
Section 8.4 that the client type be recorded during client
registration to enable the server to determine the client type and
act accordingly.

App-claimed "https" scheme redirect URIs have some advantages
compared to other native app redirect options in that the identity of
the destination app is guaranteed to the authorization server by the
operating system. For this reason, native apps SHOULD use them over
the other options where possible.

Суть происходящего в следующем:
- implicit flow считается западлом, потому что пользователь вводит свой пароль в приложении, а не на доверенном ресурсе (ну и еще приложение секрет должно хранить, в итоге получается что секрет доступен всем)
- в случае authorization code flow имеют место быть следующие проблемы:
-- если мы не хотим хранить секрет в приложении, то нам нужен свой собственный сайт, на который будет проходить редирект после попытки авторизации, а этот сайт в свою очередь будет побуждать браузер/операционную систему передать управление нашему приложению
-- если сайта у нас нет, то можно при запуске слушать какой-то порт на локалхосте и редиректы с сервера авторизации слать туда, здесь секрет все равно нужно хранить + нет гарантий что кто-то другой уже порт не слушает, можно для пущей надежности в операционной системе зарегистрировать url-схему, чтобы нам когда нужно передавалось управление, однако хранение секрета - это дыра
- вот в случае использования "Claimed "https" Scheme URI Redirection" получается так, что секрет нам на самом деле какбы и не нужен вовсе: мы доверяем операционной системе и браузеру, в том плане, что после всех редиректов управление в конце концов перейдет к нам
- т.е. суть "Authorization code with PKCE" заключается в том, что оно на самом деле ничего не усиливает, а просто девальвирует необходимость секрета при этом сохраняя совместимость с обычным flow

questioner,


вон оно в Authorization передает id и secret