Блог

В настоящее время я внедряю STS обмена токенами OAuth и немного испытываю трудности. Стандарт определен в https://www.rfc-editor.org/rfc/rfc8693 Мой вариант использования включает в себя цепочку межсистемных вызовов, запускаемых действием пользователя (принципала). Я хочу убедиться, что авторизация на уровнях конечных точек выполняется с помощью сочетания областей и идентификаторов клиентов из белого списка. Кроме того, я хотел бы сохранить контекст клиента.

Я вижу, что здесь допустим сценарий обмена токенами. В спецификации приведен пример, в котором результирующий токен содержит субъекта, которому был делегирован доступ. Однако спецификация помещает логическую систему (иначе клиент OAuth) в утверждение «sub» вложенной информации об акторе, как показано здесь:

 {
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"user@example.com",
  "act":
  {
    "sub":"https://service16.example.com",
    "act":
    {
      "sub":"https://service77.example.com"
    }
  }
}
 

Я нахожу это немного странным. Я бы ожидал, что заявка «sub» будет содержать фактический субъект, если токен субъекта также был персонализированным токеном (скажем, «adminuser»).). На мой взгляд, система, которая проводила обмен токенами, отправила бы в качестве токена участника токен client_credentials. Это не содержит утверждения «sub», а только утверждение «cid» (client_id). Это утверждение должно быть включено в утверждение «act» результирующего токена, поэтому я ожидаю, что результирующий токен будет выглядеть следующим образом:

 {
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"user@example.com",
  "cid":"3rd_client_that_conducted_token_exchange",
  "act":
  {
    "cid":"2nd_client_id",
    "act":
    {
      "cid":"initial_client_id"
    }
  }
}
 

Я не уверен, существует ли требуемая структура для утверждения «act» (насколько я вижу, нет). Есть ли здесь наилучшая практика? Любопытно узнать ваши мысли! 🙂

act Утверждение не имеет стандартизированной структуры, единственное, что упоминается в RFC, это то, что оно должно состоять из любой информации, которая позволила бы вам идентифицировать субъекта.

Должно ли act утверждение содержать информацию о пользователе или о клиенте, зависит от архитектуры вашей системы и от того, какая информация будет использоваться или требуется для других ваших служб. Если у вас есть сценарий, в котором права пользователя делегируются администратору, и вы хотите иметь эту информацию в токене, вы поместите данные администратора в act.sub утверждение. Но если вы хотите указать, что один клиент делегирует привилегии другому клиенту, у вас будет идентификатор клиента в act.sub утверждении. Идентификатор клиента также может быть субъектом, если делегирование выполняется между клиентами, а не пользователями.

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

Вы упоминаете, что у вас есть цепочка систем, между которыми вы хотите обмениваться токенами. Я считаю, что для этого сценария идентификатор клиента действительно станет предметом вашего act требования. Если я правильно понимаю, у вас есть ситуация, в которой у вас есть токен для пользователя X, выданный для использования в службе API 1 (в aud утверждении указано, что). Затем служба API 1 хочет получить доступ к службе 2 и должна обменять токен. Теперь он получает другой токен, где вспомогательный элемент — пользователь X, аудитория — служба 2 и act.sub служба 1, поскольку эта служба теперь действует как пользователь и хочет получить доступ к ресурсам в службе 2.