2015-04-27 3 views
0

Я читаю протокол oauth 2, используя различные ссылки в Интернете и его rfc (RFC 6749). После прохождения через ссылку У меня есть следующие сомнения:OAuth 2 клиентский код доступа и предоставления

  1. ли это требуется для сервера авторизации, чтобы сохранить код гранта в его конце после того, генерируется и передается код клиенту?

  2. Существует сценарий, в котором 2 разных клиента пытаются получить маркер с сервера авторизации: первый клиент получает маркер после того, как владелец ресурса зарегистрировал и одобрил доступ. Затем второй клиент (который полностью отличается от первого) пытается получить токен.

    а) В случае, если второй клиент перенаправляется и владелец ресурса должно быть предложено снова войти в систему или если сервер авторизации имеют реализацию таким образом, что она обнаруживает, что владелец ресурса вошли в ранее и не будет запросить имя пользователя и пароль с ресурса
    владелец?

    b) если ответ на предыдущий вопрос - да, как мы можем справиться с вышеуказанным сценарием ?

ответ

2
  1. Средство авторизации сервер должен поддерживать состояние, связанное с code а.о. идентификатор клиента, к которому он был обращен, URL-адрес перенаправления, который использовал клиент, и отметку времени выпуска. Это обычно означает, что сервер авторизации должен поддерживать code в качестве ссылки на это состояние, которое хранится в бэкэнд. Один из способов избежать этого - кодировать всю информацию в code и шифровать ее.

  2. Для авторизации сервер авторизации может использовать сеанс входа в систему или полагаться на внешний SSO-сервер, чтобы пользователь не нуждался в повторной аутентификации. Но то, что нужно, это попросить пользователя дать согласие на выдачу токена конкретному клиенту, как для первого, так и для второго клиента. Итак: аутентификация может быть неявной (SSO), согласие должно быть явным (поскольку речь идет о другом клиенте).

+0

для 1). Я думаю, что rfc различает код и токен. генерирующий код гранта является 1 временной активностью и является полезной защитой w.r.t. Следовательно, это код или токен, который должен поддерживать сервер? для 2). могу ли я заключить, что у разных клиентов будут разные токены для данного владельца ресурса? –

+0

1) как «code», так и «access_token» подчиняются аргументам, которые я дал в 1. 2) у разных клиентов действительно будут разные токены доступа для данного владельца ресурса; жетоны являются «областями», поэтому они выдаются только для конкретного клиента –

Смежные вопросы