OAuth 2 + guest access

Question

[Назар Мокринский]

Есть API, доступ к нему предоставляется по access_token+client_id+client_secret, согласно OAuth 2.
А что если доступ к API должны иметь и гости, при этом нужно знать, что несколько запросов приходят от того же гостя?
Можно ли сделать метод типа access_guest_token? Интересует именно решение в рамках OAuth 2, чтобы не городить лишнего, что-то не могу найти в спецификации.

Если чего путаю — поправьте.

Comments

[Назар Мокринский]

Пока добавил поддержку /token с grant_type=guest_token, но не знаю, на сколько это допустимо.

Answer 1

[Алексей Журбицкий]

Вообще без подробного описания сложно что-то толковое предложить, но на вскидку — почему гости тоже не могут использовать access_token+ зарезервированный гостевой client_id?

Comments

[Назар Мокринский]

client_id — это не пользователь, а, например приложение для мобильного, которое получает доступ к API.
access_token — это то, что характеризует пользователя для каждого конкретного client_id.
Фиксировать access_token не вариант, так как нужно чтобы он истекал по прошествию определенного времени, и был уникальным для каждого гостя (например, к нему привязываются географические координаты положения пользователя).

[Алексей Журбицкий]

nazarpc я в курсе про client_id и access_token :) Я имел ввиду пункт 4 rfc 6749 и описание чем отличается гость от обычного пользователя.
Допустим форма авторизации выглядит так: логин, пароль и кнопки войти и гостевой доступ. С обычными пользователями все понятно. Для гостей достаточно будет сгенерить на фоне уникальный логин и пароль (пользователю их показывать не нужно), вместе с access_token-ом желательно передать expires_in и естественно не передавать refresh_token. Тут есть нюанс — пользователи могут вечно пользоваться гостевым доступом (в случае если обычный доступ платный), но опять же, не зная нюансов сложно что-то предложить.

Расширять grants допускается (п 4.5), но если api открытое, то вы должны понимать что стандартные OAuth библиотеки могут и не поддерживать такое расширение.

[Назар Мокринский]

Всё дело в том, что нужно дать доступ приложению к определённой общей информации через API, не напрягая и не запрашивая ничего у пользователя, как обычный гость на сайте. Если пользователь хочет получить персонализированную информацию — он может войти.

Answer 2

[Talyutin]

Мне кажется, что в спецеификации не оговаривается, что 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 все как обычно.