Я хочу разработать API GraphQL. Этот API-интерфейс будет использоваться некоторыми браузерными приложениями, а также будет открыт для непосредственного использования людьми, которые хотят создавать свои собственные сценарии / создавать отчеты и т. Д. API будет полагаться на стороннее приложение, поддерживающее Oauth Openid Connect (okta) для пользователя и роли. управление. Это будет написано на Django.
Поскольку JWT является рекомендуемым способом защиты API-интерфейсов GraphQL, а также потому, что OIDC использует токены JWT. Я подумал о простом способе, при котором API будет просто принимать токены JWT, выпущенные Okta. Это работает, но я вижу большую задержку, когда API запрашивает ok для проверки токена (эта задержка может быть меньше в рабочей среде, потому что я тестирую бесплатную пробную версию auth0 вместо рабочей okta). Поэтому я думаю, что, возможно, мой API должен выпускать свои собственные токены JWT. Я могу подумать о трех стратегиях:
- Оставьте все как есть - используйте только JWT OIDC.
- Введите мутацию входа в систему или конечную точку REST входа в систему, которая будет принимать OIDC выше ивыпускать JWT, которые можно использовать для всех других операций.
- Как указано выше, но также разрешать прямое использование JWT от okta (я не уверен, смогу ли я реализовать его с помощью системы аутентификации Django, так что если токенраспознается, OIDC не вызывается).
Какой из этих трех является правильным (и, возможно, разработчиками OIDC) способом защиты моего API?