#swagger #oauth ☕️ Люблю и не люблю такие штуки. Переделывал немного одну вещь по работе и вдруг понял, что в go-swagger для security.type="oauth2" отсутствует flow для client_credentials. Но нет, есть. Несмотря на то, что я считаю, что это довольно частый случай — пришлось выкапывать и экспериментировать.

👉 Для способа получения ключа Client Credentials Grant в go-swagger есть flow application (согласно спецификации swagger 2.0, но это надо было догадаться туда сунуться и сложить 2+2). Из обязательных полей только tokenURL, который может быть в свою очередь в этом же API:

securityDefinitions:
  OauthSecurity:
    type: oauth2
    flow: applicatiom
    tokenUrl: '/token'
    scopes:
      admin: Admin scope
      user: User scope

☝️ Главное не забыть у /token, если он локальный поставить:

security:
  - Basic: []

👍 Flow полностью соответствует RFC 6749. Но главное, что встроенный в go-swagger Swagger-UI умеет этот flow авторизовать. Он запрашивает client_id и client_secret, и scope. Пару client_id и client_secret он сам превращает в заголовок Authorization: Basic xxxx... (как и положено по RFC). Он сам получает access_token по ссылке tokenURL, которую он распознаёт, и потом с этим токеном работает в API. Единственное, что он не отрабатывает "протухание" ключа, приходится авторизовываться каждый раз заново

#swagger #oauth 🖌 Произвёл рефакторинг своего летнего поста про oauth2 в go-swagger

☝️ Я работаю с swagger только в режиме генерации кода. Генерация спецификации по коду делает код более гибким. Однако и возможностей ошибиться намного больше, чем при генерации кода по спецификации

☕️ Переделывал одну вещь по работе и не смог найти в go-swagger для security.type="oauth2" значение для flow для client credentials grant. Через несколько часов поисков и экспериментов, я всё-таки обнаружил нужный flow. Но считаю, что в документации это не очевидно

ℹ️ Что такое client credentials grant? Это когда клиенту API надо сходить с client_id и client_secret (считайте логин и пароль) на сервер авторизации и запросить токен доступа. А к ресурсам ходить уже с этим токеном. Токен указывается в заголовке. Обычно токен представляет собой JWT (данные в json. подписанные и закодированные в base64 с определёнными полями, указывающими что это за токен, срок действия, область действия - scope и т.д.). Принципиальное отличие от авторизации пользователя — права принадлежат приложению. Хотя, на практике в большинстве случаев права приложений строго равны правам, создавших их пользователей

👉 Для варианта client credentials grant в go-swagger есть специальный flow: application (совершенно неочевидное название). Из обязательных полей только tokenURL, который может быть в свою очередь в этом же API:

securityDefinitions:
  OauthSecurity:
    type: oauth2
    flow: applicatiom
    tokenUrl: '/token'
    scopes:
      admin: Admin scope
      user: User scope

☝️ Главное не забыть у /token, если он локальный, указать авторизацию Basic:

paths:
  /token:
    post:
      security:
        - Basic: []

и добавить в securityDefinitions:

securityDefinitions:
  Basic:
    type: basic

👍 Flow полностью соответствует RFC 6749. Встроенный в go-swagger Swagger-UI умеет этот flow авторизовать. Он запрашивает client_id и client_secret, и scope у пользователя. Пару client_id и client_secret он сам превращает в заголовок Authorization: Basic xxxx... (как и положено по RFC). Он сам получает access_token по ссылке tokenURL, которую он распознаёт, и потом с этим токеном работает в API через заголовок Authorization: Bearer xxxx...

‼️ Обратите внимание, что go-swagger не учитывает формата выдаваемого токена — он может быть любым. Поле scope в блоке security носит справочную информацию и передаётся в функцию обработки авторизации для справки. Опознания JWT, его разбора и сравнения scope не происходит

  /user:
    post:
      security:
        - JWT:
          - "user:create"