Вопрос или проблема
После множества исследований о аутентификации и авторизации, я пришел к следующему, но не уверен, что это правильно, поэтому, пожалуйста, помогите мне:
Аутентификация — это то, кто вы. Авторизация — это то, что вы можете делать!
- OAuth предназначен для авторизации
- OpenID предназначен для аутентификации
- НО вы можете использовать OpenID Connect, который является дополнительным уровнем поверх OAuth2 для достижения авторизации с псевдо-аутентификацией (мы предполагаем, что если у этого человека есть права делать это, значит, он и есть тот самый человек)
Итак, использовать OpenID Connect не лучшее решение, так как это не настоящая аутентификация, но затем я продолжил искать лучшие способы аутентификации и не нашел ничего, кроме HTTP Basic (с SSL, чтобы избавиться от атаки человека посередине) или API-ключей, которые оба не так уж и безопасны с технической точки зрения.
Я как-то потерялся, правильно ли я понял эти концепции и что мне на самом деле использовать.
OpenID Connect — это протокол федеративной идентификации. Важно, что он определяет id_token, который является подтверждением идентичности, аналогичным утверждению SAML. Он сообщает, кто аутентифицировал (т.е. субъект), кто являетсяIssuer этого утверждения (т.е. IDP), как пользователь аутентифицировался (т.е. acr или AuthnContextClassRef), когда пользователь был аутентифицирован, когда истекает утверждение и многие другие важные детали. OAuth не определяет такого подтверждения идентичности. SAML и OpenID Connect также определяют “метаданные” — т.е. как провайдер идентичности и полагающаяся сторона определяют конечную точку, ключи и криптографию, необходимые для валидации утверждения. Например, как был подписан id_token? С каким алгоритмом подписи? OAuth не имеет комментариев по этой теме. Таким образом, без OpenID Connect вам пришлось бы самим придумывать и определять все это. OpenID Connect стандартизирует этот протокол идентичности с использованием OAuth, поэтому мы можем иметь стандартное клиентское программное обеспечение и реализации IDP, которые взаимозаменяемы. Было бы печально, если бы вам нужно было знать разные API аутентификации для каждого IDP. Прочитайте старую книгу O’Reilly об OAuth, которая расскажет вам, как аутентифицироваться на Google, а затем как аутентифицироваться на Facebook, чтобы получить представление о том, насколько ужасным был бы этот мир! А это всего лишь два сайта.
Ответ или решение
Ваша интерпретация понятий аутентификации и авторизации, а также их связи с протоколами OAuth 2.0, OpenID и OpenID Connect в целом верна, но давайте углубимся в детали для более точного понимания.
Аутентификация и авторизация
Правильно подмечено, что аутентификация — это процесс подтверждения вашей личности, тогда как авторизация касается того, что вы имеете право делать. В контексте web-технологий эти два процесса часто переплетены, но важно понимать, что они выполняют разные функции.
OAuth 2.0
OAuth 2.0 — это протокол авторизации, который позволяет третьим лицам получать ограниченный доступ к ресурсам пользователя на стороннем сервисе без передачи пароля. Например, это может быть доступ к вашим данным в социальной сети, не передавая ваши учетные данные стороннему приложению. OAuth 2.0 сам по себе не занимается аутентификацией и не предоставляет информации о том, кто пользователь. Его основная задача — предоставление авторизации, что позволяет создавать многоуровневые механизмы доступа.
OpenID
OpenID — это более ранний протокол, который в основном использовался для аутентификации. Он позволяет пользователям использовать одну и ту же учетную запись для входа на различные сайты, минимизируя необходимость запоминать большое количество паролей. Однако OpenID, как и OAuth, не был предназначен для управления правами доступа и авторизации.
OpenID Connect
OpenID Connect — это протокол, который фактически расширяет функциональность OAuth 2.0, добавляя слой аутентификации. Он использует токены идентификации (ID Token), которые предоставляют информацию об аутентификации пользователя, такую как время входа, идентификатор пользователя и другие параметры. Это делает OpenID Connect более масштабируемым и совместимым с современными требованиями к безопасности и управлению идентичностью.
Таким образом, паттерн работы с OpenID Connect выглядит следующим образом:
- Пользователь инициирует вход в приложение, которое использует OpenID Connect.
- Аппаратный интерфейс перенаправляет пользователя на страницу аутентификации Identity Provider (IdP).
- Если аутентификация успешна, IdP отправляет ID токен в приложение.
- Приложение может проверять этот токен для подтверждения личности пользователя и далее использовать OAuth 2.0 для авторизации доступа к ресурсам.
Оценка безопасности
Вы правильно заметили, что подходы, такие как HTTP Basic и API Keys, имеют свои ограничения. Для современных систем рекомендуется использовать подходы, основанные на OAuth 2.0 и OpenID Connect, благодаря их большей безопасности и удобству.
Рекомендации
- Используйте OpenID Connect для аутентификации. Это дает возможность не только идентифицировать пользователя, но и интегрироваться с его авторизационными данными в рамках OAuth 2.0.
- Изучите другие протоколы аутентификации. Например, SAML (Security Assertion Markup Language) также часто используется в корпоративных средах.
- Обратите внимание на безопасность ваших реализаций. Это включает использование HTTPS, управление жизненным циклом токенов и регулярные обновления.
В итоге, вы правильно поняли общие принципы, но стоит учесть нюансы, которые могут значительно улучшить безопасность и эффективность ваших систем аутентификации и авторизации. Если у вас возникнут дополнительные вопросы или потребуется более глубокое обсуждение, не стесняйтесь задавать их.