OAuth2 возвращает JWT вместо access_token

Я в настоящее время находится в процессе создания поставщика OAuth2, используя библиотеку PHP bshaffer here.OAuth2 возвращает JWT вместо access_token

Я нашел IETF draft specifications, в котором описываются реализации, которые специально указывают использование веб-токенов JSON в качестве разрешения на авторизацию и аутентификации клиента.

Реализация, которая меня интересует, однако, возвращает JWT вместо обычного токена доступа, как видно here. В случае мертвой ссылки ответ на токен доступа будет вставлен ниже.

{  
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZCI6IjYzMjIwNzg0YzUzODA3ZjVmZTc2Yjg4ZjZkNjdlMmExZTIxODlhZTEiLCJjbGllbnRfaWQiOiJUZXN0IENsaWVudCBJRCIsInVzZXJfaWQiOm51bGwsImV4cGlyZXMiOjEzODAwNDQ1NDIsInRva2VuX3R5cGUiOiJiZWFyZXIiLCJzY29wZSI6bnVsbH0.PcC4k8Q_etpU-J4yGFEuBUdeyMJhtpZFkVQ__sXpe78eSi7xTniqOOtgfWa62Y4sj5Npta8xPuDglH8Fueh_APZX4wGCiRE1P4nT4APQCOTbgcuCNXwjmP8znk9F76ID2WxThaMbmpsTTEkuyyUYQKCCdxlIcSbVvcLZUGKZ6-g", 
    "client_id":"CLIENT_ID", 
    "user_id":null, 
    "expires":1382630473, 
    "scope":null 
}

Он возвращает JWT вместо регулярно созданного токена доступа для обычных разрешений на авторизацию. Гранты учетных данных для клиентов и пользователей более важны для меня, поскольку мы имеем дело только с доступом 1-й стороны API.

Эта реализация кажется идеальной, потому что мне не нужно поддерживать хранилище сгенерированных токенов, ограничивая объем необходимой инфраструктуры. В какой-то момент, если мы откроем API для сторонних разработчиков, нам понадобится ключ-магазин для различных пабов/приватных ключей для проверки токенов каждого клиента и ограничения риска, если какая-то гнусная сторона украдет ключ шифрования.

Я считаю, что это хорошая реализация, основанная на асимметричном шифровании и SSL/TLS. Однако есть ли потенциальные риски безопасности, которые я пропустил?

источник

2014-10-29 Jamie

Tangental на ваш вопрос, в примере с маркером у вас нет стандартных требований JWT. Например, у него есть 'client_id', а не' sub' (вероятно, из старой спецификации, текущее требование здесь: https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 # section-3) – stash

Спасибо! Документация, на которую я вытащила ответ, должна быть устаревшей, v1.5 генерирует токен с «sub», «iss» и т. Д. Однако оцените тщательную проверку. – Jamie

Недостатком является то, что вы не можете отменить выданные токены JWT без базы данных токенов. –

Подпись на JWT будет защищать только любые претензии внутри токен от несанкционированного доступа, но не может защищать претензии, внешние по отношению к токену. Поэтому поле expires в вашей структуре не защищено и может быть изменено.

Для защиты от несанкционированного доступа вы хотите использовать exp claim.

два действительных решения:

двойная проверка expires против exp
падение expires и просто использовать exp

Вы можете предпочесть один над другим в зависимости от ваших требований. Лично я бы сохранил это просто и пошел с (2)

источник

2014-10-30 16:42:40 stash

Мне нравится ваше предложение об экспорте. Вопрос: Если я реализую поток refresh_token, должен ли я добавить токен обновления в качестве претензии в JWT или добавить его как свойство refresh_token JSON? –

Я бы порекомендовал вам добавить его как refresh_token JSON Property. При выходе из системы вы можете отменить access_token или refresh_token – Vikash

OAuth2 возвращает JWT вместо access_token

ответ

Смежные вопросы