Как отличить токен доступа JWT от токена обновления, используемого в качестве заголовка авторизации

Как определить, является ли токен JWT, используемый в Authorization: Bearer ..., токеном доступа или токеном обновления. Другими словами, что мешает пользователю использовать свой токен обновления JWT в заголовке авторизации вместо токена доступа.

Когда я смотрю на полезную нагрузку как токена доступа, так и токена обновления в этом разделе руководства, https://github.com/starkandwayne/ultimate-guide-to-uaa/blob/master/docs/refresh-tokens.md#jwt-refresh-tokens Я не вижу реального способа определить, какой из них какой.

Обновить токен:

{
"jti": "3e53955fcff6429a8a187c4c37f1b592-r",
"sub": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"scope": [
    "openid",
    "airports.all"
],
"client_id": "airports",
"cid": "airports",
"user_id": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"origin": "uaa",
"grant_type": "password",
"user_name": "airports-all",
"rev_sig": "4c3b3810",
"iat": 1530739971,
"exp": 1533331970,
"iss": "https://192.168.50.6:8443/oauth/token",
"zid": "uaa",
"aud": [
    "openid",
    "airports"
]
}

Токен доступа:

{
"jti": "fe39323464d74fb5a6fcb71d89f722c4",
"sub": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"scope": [
    "openid",
    "airports.all"
],
"client_id": "airports",
"cid": "airports",
"azp": "airports",
"user_id": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"origin": "uaa",
"grant_type": "password",
"user_name": "airports-all",
"email": "[email protected]",
"auth_time": 1530739970,
"rev_sig": "4c3b3810",
"iat": 1530739971,
"exp": 1530783171,
"iss": "https://192.168.50.6:8443/oauth/token",
"zid": "uaa",
"aud": [
    "openid",
    "airports"
]
}

Какой стандарт? Поставить другой прицел?


jwt jwt-auth oauth-2.0 oauth
person x22n    schedule 10.01.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Как и в опубликованной вами ссылке, рекомендуется использовать непрозрачные токены обновления, которые не являются JWT, и вам следует использовать эту конфигурацию.

Клиент (обычно пользовательский интерфейс) должен отправлять только токены доступа на серверную часть, а любой другой тип токена должен быть отклонен. Правильная конфигурация обеспечивает это.

Задача серверной части - проверить полученный JWT. Нестандартная установка, как указано выше, может означать, что это будет работать с токеном обновления, но это плохо по двум причинам:

  • Учетные данные сообщения API имеют очень долгий срок службы, и риски безопасности возрастают, если токен каким-то образом перехватывается.
  • Решение не переносимо и, скорее всего, сломается для клиента в будущем, или если вы когда-нибудь смените провайдера.
person Gary Archer    schedule 11.01.2020