사용자마다 다른 데이터를 제공하기 위해 로그인 기능을 탑재하고 있는 웹사이트는 다수 존재합니다. 그러나 사용자는 웹사이트에 탑재된 로그인 기능의 '인증 방식'까지는 신경쓰지 않습니다. 그런 웹사이트의 인증 방식에 대한 대표적인 6가지 방식을 엔지니어 Amal Shaji 씨가 설명합니다.

Web Authentication Methods Compared | TestDriven.io
https://testdriven.io/blog/web-authentication-methods/

Web Authentication Methods Compared

This article looks at the most commonly used web authentication methods.

testdriven.io


◆ 기본 인증
HTTP에 내장된 기본 인증은 가장 기본적인 인증 방식입니다. 기본 인증에는 암호화 기능은 없고, Base64로 인코딩된 사용자 ID와 암호를 클라이언트에서 서버로 전송합니다.

인증 과정은, 우선 클라이언트는 서버에 인증되지 않은 요청을 보내고 서버는 401 에러를 응답합니다. 그 후 클라이언트가 사용자 ID 및 암호를 전송하면 서버에 액세스를 할 수 있습니다.

기본 인증의 장점은 구현이 용이한 점과 많은 브라우저가 대응하고 있는 점 등을 들 수 있습니다. 반대로, 암호화 비대응이라는 점과 요청마다 매번 인증할 필요가 있다는 점 등이 단점입니다.

◆ Digest 인증
Digest 인증은 기본 인증과 마찬가지로 HTTP에 포함되어 있지만, 암호를 MD5로 해시하는 기본 인증보다 보안을 강화할 수 있다고 Shaji 씨는 설명합니다. 인증 절차는 기본 인증과 거의 동일하지만, MD5 의한 암호의 해시화에 이용되는 논스를 서버와 클라이언트가 주고받는다는 점이 다릅니다.

Digest 인증은 기본 인증의 장점 이외에도 MD5로 해시되어 보안이 향상된다는 것이 장점. 그러나 요청에 따라 인증을 해야 하는 점은 기본 인증과 변함없고, 서버 측의 사용자 ID와 암호는 일반텍스트로 저장되어 있기 때문에 서버 측의 보안은 기본 인증에 뒤떨어진다는 것. 그리고 중간자 공격에 취약하다고 설명합니다.

◆ 세션 기반 인증
세션 기반 인증은 Cookie를 사용하여 수행하는 인증 방식으로 기본 인증, Digest 인증과 같이 요청마다 사용자 ID와 암호를 송수신할 필요가 없습니다. 인증 절차로는 먼저 클라이언트에서 서버에 인증정보를 전송하고 서버 측에서 성공적으로 인증되면 서버 측에서 세션을 생성. 서버는 클라이언트 세션 Cookie를 전송하고 클라이언트는 Cookie와 함께 요청하는 한 서버에 액세스 할 수 있습니다.

세션 기반 인증의 이점은 요청마다 인증정보를 전달할 필요가 없어서 로그인 후의 처리가 빠르다는 점. 또한 다양한 프레임워크가 존재하기 때문에 구현이 쉽다는 점도 장점으로 들 수 있습니다. 단점은 서버 측에서 인증정보를 유지한다는 점과 인증이 필요 없어도 Cookie를 요청마다 보낼 필요가 있다는 점, cross-site request forgeries에 약점이 있다고 합니다.

◆ 토큰 기반 인증
토큰 기반 인증은 세션 기반 인증이 사용하는 Cookie 대신 토큰을 사용합니다. 토큰은 서버의 비밀 키로 서명되어 있으며, 클라이언트는 서버로부터 받은 토큰과 함께 요청을 제출하는 인증 과정입니다. 서버는 서명이 올바른지 확인하기만 하면 되기에 인증정보를 서버 측에서 보존할 필요가 없습니다.

토큰 기반 인증은 서버 측에서 인증정보를 유지하지 않는 stateless 인증 방식이기 때문에 고속통신을 제공할 수 있다고 Shaji 씨는 설명합니다. 마이크로 서비스와도 궁합이 좋다고 합니다.

토큰 기반 인증의 단점은 클라이언트의 정보 유지 방법에 따라 크로스 사이트 스크립팅 및 cross-site request forgeries의 피해를 받을 가능성이 있다는 점, 토큰은 유효기간이 지날 때까지 제거할 수 없기 때문에 만약 토큰이 누설된 경우에는 공격자가 악용할 수 있다고 Shaji 씨는 경고합니다.


◆ 일회용 암호
로그인을 할 때 한 번만 사용할 수 있는 비밀번호를 발급하는 방식이 일회용 암호입니다. 일회용 암호는 이메일 주소나 전화번호 등 확실히 계정 소유자만 사용할 수 있다고 신뢰할 수 있는 시스템을 이용하여 보안 레이어를 하나 추가할 수 있는 점이 특징. 온라인뱅킹 등에도 이용될 정도로 높은 보안이 장점이지만, 신뢰할 수 있는 시스템이 고장이나 배터리 방전으로 사용할 수 없게 된 경우, 인증을 할 수 없게 된다는 등의 단점도 있습니다.

◆ OAuth · OpenID
OAuth 및 OpenID 같은 인증 프로토콜 표준은 '고객이 누구인가?'라는 인증 기능 외에도 '클라이언트에게 무엇을 허가할 것인가'라는 권한관리 기능도 가지고 있습니다. Google이나 Twitter, Facebook 등 SNS 계정을 이용한 로그인 기능을 구현하는 것도 가능하며, 비밀번호를 없이도 높은 보안을 제공할 수 있다고 합니다.

OAuth 및 OpenID 인증의 장점은 높은 보안 및 새로 계정을 만들 필요가 없다는 점, 암호를 보유하지 않기 때문에 제삼자로부터의 공격을 받아도 무해하다는 점을 들 수 있습니다. 단점으로는 다른 시스템에 의존하는 부분이 생겨 버리는 점, 권한 확인을 사용자 측에서 간과하기 쉬운 점, SNS 계정을 가지고 있지 않은 사람은 이용할 수 없는 점을 들 수 있습니다.


Shaji 씨는 채용하는 인증 방식을 결정할 때 다음의 기준에 따르면 좋다고 말합니다.

· 서버 사이드의 템플릿을 사용하는 응용프로그램 : 세션 기반 인증. OAuth 및 OpenID를 추가하는 것도 좋다
· REST API : 토큰 기반 인증
· 고급 기밀 정보를 취급하는 경우 : 일회용 암호를 추가

Posted by 말총머리
,