Аутентификация с помощью JWT с использованием GraphQL

После некоторого поиска в Интернете я обнаружил, что лучший способ аутентификации JWT при использовании GraphQL — вставка токена JWT в контекст GraphQL. Таким образом, распознаватели могут получить к нему доступ и проверить, вошел ли пользователь в систему, есть ли у него разрешения и т. д.

Мне было интересно, нужно ли мне размещать логику/функцию аутентификации в каждом распознавателе, для которого требуется аутентификация. Есть ли способ, которым я мог бы установить по умолчанию (например, промежуточное программное обеспечение) аутентификацию для каждого запроса, кроме входа/выхода из системы/регистрации/забытого пароля?

Gabriel Gian 05.10.2017 источник

Ответы (2)

arrow_upward
0
arrow_downward

Нет необходимости проверять резольверы. Вы можете добавить промежуточное ПО на стороне сервера.

const graphQLServer = express();
graphQLServer.use('/graphql', function(req, res, next) {
  var token = req.headers.token;
  if (token != null && token != 'undefined') {
    //Do token verification here
    next();
  } else {

    // if there is no token
    // return an error
    return res.status(403).send({
      success: false,
      message: 'No token provided.'
    });
  }
})

Просто попробуйте это

Seena V P 06.10.2017

arrow_upward
2
arrow_downward

Этот вопрос всплывает время от времени, но недостаточно обсуждался. Я думаю, что ответ заключается не в технологии, а в том, как лучше всего удовлетворить ваши потребности.

При переходе на GraphQL важно помнить, что;

Вам не нужно отказываться от REST
У вас может быть более одной конечной точки GraphQL.

Вот несколько предложений, основанных на моем опыте внедрения GraphQL.

Аутентификация

Для входа в систему/выхода из системы/забытого пароля и всего прочего подумайте о том, чтобы перейти к старой школе. Form Post + рендеринг на стороне сервера, REST API служил нам десятилетиями. На этом основаны многие сторонние сервисы аутентификации (Facebook Login, Google, OAuth2... и т.д.). Я стараюсь избегать использования GraphQL для этой цели.

Авторизация

Логика проверки того, имеет ли запрашивающий авторизованный доступ к GraphQL, может быть обобщена до двух уровней.

Сервисы GraphQL

По сути, вы проверяете, авторизован ли запрашивающий для использования службы GraphQL. Как правило, проще проверить, аутентифицирован ли запрашивающий, иначе вообще запретить доступ к службе. Обычно это делается через промежуточное ПО веб-сервера.

Будут времена, когда вам нужно будет предоставлять некоторые запросы GraphQL анонимным пользователям, и я склоняюсь к другой «неограниченной» конечной точке GraphQL. Эта конечная точка, как правило, почти не имеет мутаций, предоставляет ограниченный подмножество информации и ограниченные вложенные запросы.

По сути, вы просматриваете данные и решаете, какая информация/операция является общедоступной, а какая нет. IMO, этим намного проще управлять и защищать, чем иметь одну конечную точку GraphQL и реализовывать контрольные точки авторизации в каждом пути/преобразователе запроса.

Разрешение на мелкое зерно

На данном этапе в основном все запрашивающие являются аутентифицированными пользователями. Нам может понадобиться задать вопрос:

Является ли запрашивающий тот же пользователь, чья информация просматривается в данный момент?
Является ли запрашивающий другом пользователя, чья информация просматривается в данный момент?
Является ли запрашивающий членом компании, чья информация просматривается в данный момент?

Именно здесь действительно имеет смысл помещать логику проверки в распознаватели (или модели). Лично я считаю, что резольверы — отличное место для этого. В сочетании с DataLoader реализация может быть быстрой и эффективной.

Надеюсь это поможет!

Ivan Choo 06.10.2017