OAuth 2.0
OAuth 2.0 (RFC 6749) — фреймворк делегирования доступа. Не путать с аутентификацией — OAuth про "приложение X может действовать от имени юзера в сервисе Y". Аутентификация — это OIDC поверх OAuth.
Роли
- Resource Owner — юзер
- Client — приложение
- Authorization Server — выдаёт токены
- Resource Server — API за токеном
Grant types (flows)
| Grant | Для чего | Актуален? |
|---|---|---|
| Authorization Code + PKCE | web + mobile + SPA | да, дефолт |
| Authorization Code (без PKCE) | server-side web | устарел без PKCE |
| Implicit | SPA | deprecated |
| Password (ROPC) | legacy | deprecated |
| Client Credentials | machine-to-machine | да |
| Device Code (RFC 8628) | TV, CLI | да |
| Refresh Token | обновление access | да |
Authorization Code Flow (упрощённо)
1. Client → AS: GET /authorize?client_id=X&redirect_uri=Y&code_challenge=Z
2. Юзер логинится, подтверждает scopes
3. AS → Client: 302 redirect_uri?code=abc
4. Client → AS: POST /token code=abc, code_verifier=...
5. AS → Client: {access_token, refresh_token, expires_in}
6. Client → RS: GET /api Authorization: Bearer <access_token>Токены
- Access token — короткоживущий (15 мин), для API. Часто JWT или opaque.
- Refresh token — долгоживущий (недели/месяцы), для обновления access. См. refresh.
Scopes
Ограничение доступа: read:profile, write:posts. Юзер видит и подтверждает.
Bearer token — критичный минус
Кто держит токен — тот может юзать. Нет привязки к клиенту. Решение: mTLS (RFC 8705) или DPoP (RFC 9449).
OAuth 2.1 (draft)
Актуализация: PKCE обязателен, Implicit и Password убраны, refresh token rotation обязательна.
См. также
- OIDC, PKCE, JWT, refresh tokens, DPoP