Мне кажется, что в спецеификации не оговаривается, что client_id — это тип или класс приложения (мобильное или ваше серверное). Зато явно сказано, что client_id выдается сервером клиенту. Поэтому ничто не мешает завести client_class_id в первом запросе на получение client_id и, если надо, client_secret. client_class_id как раз будет обозначать, что это мобильное приложение.
К тому же содержание пункта
tools.ietf.org/html/rfc6749#section-2.3.1 как раз напоминает ранее известную и привычную схему логин: пароль.
В итоге каждый пользователь сразу же получает свой client_id, который, кстати, и будет потом передаваться со всеми остальными запросами согласно спецификации.
Пример:
клиент отправляет
POST
xxx/oauth/credentials
в теле client_class_id=12sdfs31sdfsd23&остальные идентификаторы&всякие модели&типы и сопотствующая информация
получает client_id=cid и client_secret.
далее, если клиенту нужно залогиниться, то он отправляет
POST
xxx/login?response_type=code&redirect_uri=yyy://zzz&client_id=cid
в теле login=vasya&password=123
Если он гость, то что-нибудь другое отправляет.
получает HTTP/1.1 302 Found
Location: yyy://zzz?code=vasya_code
далее запрашивает POST
xxx/oauth/token с grant_type=authorization_code&code=vasya_code&redirect_uri=yyy://zzz все как обычно.
Простой
Средний
Простой
Простой
