Вхід через Znosin

Зареєструйте сайт

Установіть OAuth із каталогу Znosin, відкрийте «Мої сайти» й додайте сайт. Один акаунт може володіти 20 інтеграціями. Для організації використовуйте окремий акаунт власника, задайте пароль і перевіряйте підключені пристрої.

confidential

Сайт із сервером

Конфіденційний клієнт використовує client_secret_basic. Збережіть Client Secret у сховищі секретів на сервері: він показується лише один раз.

public

Браузерний застосунок

Публічний клієнт використовує метод автентифікації none, без Client Secret. Не передавайте PKCE verifier і токени в URL та не записуйте їх у журнали.

Укажіть до 10 точних адрес повернення. Обов’язковий HTTPS; HTTP дозволено лише для localhost, 127.0.0.1 і [::1]. Маски, фрагменти й облікові дані в URL заборонені. За можливості розділяйте інтеграції для розробки та робочого середовища.

Client ID — публічний ідентифікатор. Зміна Client Secret одразу відкликає старий секрет, коди й токени доступу. Зміна адрес повернення або вимкнення клієнта також відкликає наданий доступ. Не додавайте секрети до Git, клієнтського коду чи знімків екрана.

Налаштуйте OIDC-бібліотеку

Параметр	Значення
Issuer	`https://znosin.com`
Discovery	`https://znosin.com/.well-known/openid-configuration`
Сценарій авторизації	`authorization_code` · `response_type=code` · `response_mode=query`
Дозволи	`openid profile email`
PKCE	S256, обов’язковий для обох типів клієнта
Підпис ID-токена	RS256; відкриті ключі за jwks_uri з документа discovery

Перед перенаправленням створіть незалежні криптографічно випадкові state, nonce і code_verifier. Збережіть їх у серверній сесії відвідувача, а для публічного клієнта — у сесії браузера. State і nonce: 16–512 символів, використовуйте щонайменше 32 випадкові байти. Verifier: 43–128 незарезервованих ASCII-символів. Не використовуйте спробу входу повторно.

Запит авторизації

GET https://znosin.com/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=EXACT_REGISTERED_URL&
  response_type=code&scope=openid%20profile%20email&
  state=RANDOM_STATE&nonce=RANDOM_NONCE&
  code_challenge=BASE64URL_SHA256_VERIFIER&
  code_challenge_method=S256

Кодуйте кожне значення параметра для URL. Дозвіл openid обов’язковий. Підтримується необов’язковий prompt=consent. Прихований вхід, примусова повторна автентифікація через max_age, request objects та інші response modes не підтримуються.

Обробіть повернення на сайт

Використайте збережену спробу входу один раз. Перевірте початковий state, строк дії й точний збіг iss з issuer. За error=access_denied не створюйте сесію. Не використовуйте неперевірені параметри callback як адресу перенаправлення.
Обміняйте код протягом 60 секунд: POST із даними форми на /oauth/token. Передайте grant_type, client_id, redirect_uri, code і code_verifier. Код одноразовий. Конфіденційний клієнт також використовує HTTP Basic: окремо закодуйте Client ID і Client Secret як значення форми, з’єднайте двокрапкою й застосуйте Base64. Секрет у тілі запиту не приймається.
Через OIDC-бібліотеку перевірте підпис RS256, точний issuer, audience, строк дії, час випуску й nonce із сесії. Якщо є azp, перевірте і його. Самого декодування JWT недостатньо.
Знайдіть або створіть локального користувача за парою iss + sub, потім змініть ідентифікатор локальної сесії. Нік, ім’я й пошта можуть змінюватися та не є ключами ідентифікації.

Обмін коду · конфіденційний клієнт

POST https://znosin.com/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_FORM_ENCODED_ID_AND_SECRET

grant_type=authorization_code&
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
code=AUTHORIZATION_CODE&
code_verifier=ORIGINAL_VERIFIER

Приклад містить заповнювачі, а не справжні секрети. Публічний клієнт не передає заголовок Authorization. Для обох типів обов’язкові початковий PKCE verifier і точна зареєстрована адреса повернення. Кодуйте всі значення тіла як дані форми.

Профіль і дозволи

Відповідь містить ID-токен на 5 хвилин і непрозорий токен доступу на 1 годину. Запитуйте /oauth/userinfo з Authorization: Bearer ACCESS_TOKEN. Його sub має збігатися з перевіреним ID-токеном.

Дозвіл	Поля відповіді
`openid`	`sub`
`profile`	`name`, `preferred_username`, `picture` (публічний URL аватара)
`email`	`email`, `email_verified`

Наразі email_verified дорівнює false. Створення скриньки не є перевіркою володіння адресою. Не прив’язуйте неперевірену пошту до наявного акаунта з паролем чи іншим провайдером автоматично. Спочатку попросіть увійти в наявний акаунт.

Паролі, листування, вміст пошти, файли й права агентів не передаються. Користувач може відкликати доступ у профілі, у розділі доступу для сайтів. Це блокує UserInfo та нові обміни кодів, але не завершує сесію вашого сайту й не скасовує вже виданий ID-токен, що перевіряється без мережі. Сесіями та виходом керує ваш сайт.

Експлуатація та обмеження

CORS публічних клієнтів дозволено лише для точних origin зареєстрованих адрес повернення. Конфіденційний клієнт обмінює код між серверами. Не пересилайте Basic-заголовок на JWKS, UserInfo або під час редиректів. Зберігайте лише потрібний доступ, приховуйте коди й токени в журналах та обмежуйте частоту callback-запитів. Ліміти token endpoint діють за IP; для HTTP 429 враховуйте Retry-After.

Керування потребує браузерної сесії власника Znosin з перевіркою Origin. Токени агентів не дозволяють реєструвати сайти або підтверджувати доступ. Самостійна реєстрація проходить через OAuth-застосунок, а не анонімну динамічну реєстрацію клієнтів. Назву задає власник; це не знак перевірки. Під час надання згоди показується фактичний origin адреси повернення.

Реалізовано обмежений профіль OIDC code flow, без сертифікації OpenID Conformance. Refresh tokens, спільний вихід із сайтів, PAR, DPoP та автоматична ротація RSA-ключів поки не реалізовані. Наявні публічні клієнти підтримуються.

Специфікації протоколів

OAuth Security Best Current Practice ↗OpenID Connect Core ↗

Вхід через Znosin

01Зареєструйте сайт