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

Question

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

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

Refre sh token:

{
"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": "airports-all@example.com",
"auth_time": 1530739970,
"rev_sig": "4c3b3810",
"iat": 1530739971,
"exp": 1530783171,
"iss": "https://192.168.50.6:8443/oauth/token",
"zid": "uaa",
"aud": [
    "openid",
    "airports"
]
}

Что такое стандарт? Поставить другую сферу?

Answer 1

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

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

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

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