Идентичность и безопасность API

Современные сервисы редко проверяют пароль сами — они делегируют. OAuth2 позволяет приложению действовать от вашего имени без ваших учётных данных, OIDC добавляет ответ на вопрос кто вошёл, а API — это место, где сервер решает, к чему конкретный вызывающий имеет право обратиться. Через всё здесь проходят два вопроса: аутентификация (кто вы) и авторизация (что вам можно). Смешайте их, доверьтесь непроверенному токену или позвольте id из запроса решать вопрос доступа — и вся граница рушится.

Сквозной вывод: сервер — единственная инстанция власти. Токены — это валюта доверия, но токен стоит ровно столько, сколько его проверка: закреплённый алгоритм, сверенные issuer и audience, живой срок жизни. А на уровне API авторизация проверяется по каждому объекту, на сервере — её нельзя делегировать спрятанной кнопке, одному лишь фильтру на шлюзе или тому id, который прислал вызывающий.

Карта темы

• OAuth2 и OIDC — делегированная авторизация против аутентификации, поток authorization-code + PKCE, state и точное сопоставление redirect_uri, audience у id_token против access_token, валидация JWT, ротация refresh-токенов и отзыв.
• Безопасность API — форма OWASP API Top 10: BOLA и авторизация уровня функций, избыточная выдача данных, mass assignment, rate limiting, учётные данные API, валидация по схеме, версионирование, GraphQL и проверка на шлюзе против сервиса.

Значение для собеседований: эти два слоя — то, вокруг чего строятся раунды по identity и API: ждите «расскажите про authorization-code flow и зачем PKCE», «как вы валидируете JWT» и «почему BOLA стоит первым в списке OWASP API». Кандидат, который держит аутентификацию и авторизацию раздельно и всегда ставит проверку на сервер, сразу выделяется.