Посібник з OAuth
Усі виклики API потребують авторизації та виконуються від імені авторизованого користувача Ahrefs. Для цього ваш застосунок має отримати токен доступу API для цього користувача.
Ahrefs Connect використовує OAuth 2.0 Authorization Code Flow з Proof Key for Code Exchange (PKCE). Процес складається з двох основних кроків:
1. Авторизуйте застосунок
Перенаправте користувача на:
https://app.ahrefs.com/web/oauth/authorize?response_type=code&client_id={client_id}&scope=apiv3-integration-apps&redirect_uri={redirect_uri}&code_challenge={code_challenge}&code_challenge_method=s256&state={state}
Параметри:
{client_id}: URL-encoded Client ID з розділу Ahrefs Connect у ваших налаштуваннях облікового запису.{redirect_uri}: URL-encoded Redirect URI, який ви зареєстрували в тому самому розділі.{code_challenge}: Отримується з code verifier за допомогою методу S256:- Згенеруйте code verifier — випадковий рядок довжиною 43–128 символів за допомогою криптографічно безпечного генератора. Дозволені символи:
[A-Z] [a-z] [0-9] - . _ ~(див. RFC7636 Section 4.1). - Обчисліть хеш SHA-256 для code verifier.
- Закодуйте хеш у форматі Base64-URL.
- Використайте це закодоване значення як
code_challenge(див. RFC7636 Section 4.2).
- Згенеруйте code verifier — випадковий рядок довжиною 43–128 символів за допомогою криптографічно безпечного генератора. Дозволені символи:
{state}: Згенеруйте непрозоре значення, щоб зберегти стан між запитом і зворотним викликом. Сервер авторизації додасть це значення під час перенаправлення користувача назад у ваш застосунок. (див. RFC6749 Section 4.1.1)
info
Примітка для розробників застарілих застосунків:
І застаріла інтеграція (API v2), і новий Ahrefs Connect (API v3) використовують одного й того самого OAuth-клієнта. Це означає, що вони також мають спільний Redirect URI — ви не можете налаштувати окремі production Redirect URI для старої та нової версій вашого застосунку.
Радимо оновлювати продакшн Redirect URI в налаштуваннях акаунта лише після того, як ваш новий застосунок буде перевірено й активовано Ahrefs і ви будете готові випустити його.
Якщо ви хочете й надалі використовувати один і той самий Redirect URI для обох версій, можна скористатися параметром {state}, щоб розрізняти запити. Наприклад, додайте унікальний рядок для застарілого застосунку та інший — для нового. Оскільки під час перенаправлення користувачів назад до вашого застосунку OAuth-сервер повертає те саме значення {state}, ваш сервер може вибирати потрібну логіку залежно від цього значення. Так користувачі зможуть і далі генерувати токени для обох версій, не ламаючи наявну інтеграцію.

Досвід користувача:
- Користувач бачить екран згоди на авторизацію Ahrefs.
- Вони надають вашому застосунку дозвіл на доступ до Ahrefs API від свого імені.
- Ahrefs перенаправляє їх на ваш Redirect URI з:
- параметром
code— використовується на кроці 2 - параметром
state— перевірте, що він збігається з вашим початковим запитом.
- параметром
2. Отримайте access_token
Обміняйте code на access_token, надіславши запит POST на https://ahrefs.com/oauth/token .
Передайте параметри в тілі запиту у форматі application/x-www-form-urlencoded (див. RFC6749, розділ 4.1.3):
grant_type:authorization_codeclient_id:{client_id}(має збігатися з тим, що вказано на кроці 1)redirect_uri:{redirect_uri}(має збігатися з тим, що вказано на кроці 1)code:{code}(з кроку 1)code_verifier:{original_code_verifier}(значення з кроку 1 без перетворень)client_secret:{client_secret}(лише для вебзастосунків — знаходиться в розділі Ahrefs Connect у налаштуваннях акаунта). Для десктопних застосунків не вказуйте.)
Приклад відповіді:
{
"access_token": "\<токен для використання в API-запитах>",
"expires_in": \<час дії access_token у секундах>,
"token_type": "Bearer",
"scope": "apiv3-integration-apps"
}
Термін дії токена та повторне підключення
- Refresh токен не видається.
- Access токен дійсний протягом 1 року. Після завершення терміну дії користувач має підключитися знову (повторно авторизуватися) через OAuth.
info
Примітка щодо безпеки:
- Ніколи не розкривайте
access_tokenкінцевим користувачам ані під час авторизації, ані пізніше (у UI, логах, URL-адресах або клієнтському коді). - Для вебзастосунків зберігайте
client_secretлише на стороні сервера. - У межах процесу затвердження вам потрібно буде продемонструвати безпечну обробку токенів.