Корпоративні зразки для аутентифікації JWT для додатка на основі REST?

Специфікація JWT описує лише корисне навантаження та те, як він надсилається, але залишає відкритим протокол аутентифікації, що дозволяє гнучкість, але цілком, на жаль, гнучкість може призвести до антишарових моделей та неправильного проектування.

Я шукаю добре продуманий шаблон для перевірки автентичності JWT, який я міг би використати або адаптувати, але мені не вдалося знайти щось повне.

Про що я думав:

• коли жоден заголовок авторизації не виконаний, або маркер JWT недійсний або закінчився, надішліть HTTP 401
• для автентифікації використовуйте / увійдіть в REST-канал, надішліть ім'я користувача та пароль як об’єкт JSON
• щоб зберегти маркер живим, використовуйте / keepalive канал REST, викликайте його кожні N (5) хвилин, отримуйте новий JWT маркер і заміняйте існуючий після кожного дзвінка (термін закінчується через M (15) хвилин)

Однак те, що мене турбує, - це необхідність того / Keepalive каналу. З іншого боку, це змушує мене запобігати закінченню автентифікації, навіть якщо користувач відсутній (рішення, якщо ми хотіли б, щоб зберегти ще не виконано), і, звичайно, це додаткові дзвінки та додаткове ускладнення для протоколу. Що було б цікаво, це те, що сервер автоматично продовжує маркер. У середовищі, заснованому на сеансі, це відбувається шляхом скидання часової позначки, тут, однак, сервер повинен був би надсилати новий маркер, можливо, не кожен раз, але як тільки маркер закінчиться через R (скажімо, 10) хвилин. Але розміщення його у органі відповіді означало б змінити протокол відповідей JSON (отже, рішення є інвазивним та непрозорим), а розміщення додаткового заголовка HTTP, який клієнт міг би обробити, не обов'язково може бути хорошою схемою. Я '

Чи є якісь готові структури підприємств, які відповідають на мої відкриті моменти? Чи проект мого протоколу є надійною ідеєю? Я вважаю за краще використовувати щось готове, ніж дизайн з нуля.

JWT ( Intro to JSON Web Token ) - лише формат маркера, автентифікація - це щось зовсім поза сферою для цієї специфікації. Він дійсно часто використовується в системах аутентифікації, але ви також можете використовувати його для абсолютно різних сценаріїв, тому є сенс не включати в цю специфікацію специфічні обмеження для аутентифікації.

Якщо ви шукаєте поради щодо аутентифікації, зверніться до сімейних специфікацій OpenID Connect . Крім того, якщо ваша система складається з HTTP API, і ви зацікавлені в наданні делегованого доступу до цього API до вашої власної або до сторонньої клієнтської програми, тоді вам слід звернутися до специфікації OAuth 2.0 .

Існують додаткові протоколи, пов’язані з аутентифікацією, такі як SAML та WS-Federation, які все ще широко використовуються у корпоративних сценаріях, але вони значно складніші для реалізації.

Про ваші конкретні відкриті точки:

• Схема аутентифікації лексеми носія визначена в RFC 6750, який містить інструкції щодо виконання запитів та можливих кодів помилок .
• OAuth2 та OpenID Connect розглядають можливість та визначають спосіб обміну ім'ям користувача / паролем з маркером.
• Проблема продовження життя автономного / за значенням (JWT) терміну служби вирішується в рамках OpenID Connect та OAuth2 через засоби оновлення лексем .

Незважаючи на те, що OAuth2 та OpenID Connect можна зрозуміти простішими, ніж деякі попередники, вони все ще досить складні, щоб вимагати певної обережності та реалізовувати їх самостійно, якщо ви готові витратити значну кількість часу та ресурсів. Це, як правило, кращий варіант використання сторонніх бібліотек або служб, які роблять це важко за вас.

Нарешті, ці протоколи охоплюють багато сценаріїв, тому в деяких ситуаціях вони можуть бути надмірними.

Я не думаю, що вам потрібен чудовий канал. Ваша корисна навантаження може (і рекомендується) містити інформацію про термін дії, надану сервером (у expключі, відповідно до стандарту ), коли маркер генерується під час входу. Якщо використовується маркер з минулим терміном дії (який, очевидно, визначається сервером, який довіряє лише те, що є в маркері, якщо підпис підтверджується), сервер просто відкидає його за допомогою HTTP 401, спонукаючи клієнта до повторної автентифікації.

Клієнти, тим часом, можуть бути ініціативними. Розділ корисного навантаження не зашифрований, і оскільки клієнт може його прочитати, клієнт може встановити, коли запит буде надісланий з маркерів, що закінчився, і тому дзвоніть /loginще раз, якщо маркер закінчився.

Крім того, REST дозволяє надсилати інформацію про гіпермедіа як "двигун стану", тому, якщо ви хочете, ви можете фактично зробити лише одноразове використання свого JWT, а також із закінченням терміну дії. Кожен запит, таким чином, буде генерувати новий JWT, який повертається у відповідь клієнту, або у вмісті, або, швидше за все, у заголовку відповіді, як це робить hapi-auth-jwt2 .