목표
인증 정보는 인증 방식(Type)에 따라 달라진다.
인증 방식에는 대표적으로 2가지 방식이 있고, 방식을 비교 및 정리를 하려 한다.
HTTP 통신은 요청과 응답으로 이루어진다. 요청과 응답은 클라이언트와 서버 간에 이루어지고 있고, 클라이언트가 서버에 요청을 보내면 서버는 요청한 리소스를 보내준다.
해당 리소스를 권한이 가진 사람만이 접근이 가능하도록 하려면 클라이언트의 인증 정보(Credentials)를 확인한다. HTTP 인증 프레임워크는 RFC 7235에 정의되어 있고, Authorization: <type <credentials>과 같이 인증 헤데를 요청에 사용한다. 인증 정보에 따라 200 OK 혹은 401 Unauthorized 상태 코드로 클라이언트에게 전달된다.
방식
방식에 따른 특징과 장점/단점에 대해서 정리해보자
1. Basic 인증
특징
- 가장 기본적인 인증 방식
- 인증 정보: 사용자 ID, 비밀번호를 사용함
- 참고: RFC 7617에 정의 - 'Basic' Authentication Scheme
- ex) base64로 인코딩한 "사용자ID:비밀번호" 문자열을 Basic과 함께 인증 헤더에 입력한다.
Authorization: Basic base64({USERNAME}:{PASSWORD})장점과 단점
- 장점
- 단순하고 구축하기가 쉽다.
-HTTP 웬 서비스를 기반으로 만들어졌다.
-사용의 간단함을 가진다. 사용자 ID와 비밀번호 외에 로그인 페이지나 별도의 인증 정보를 요구하지 않는다.
- 단점
- 쉽게 복호화할 수 있는 base64를 사용하고, 노출된 인증 정보를 철회할 방법이 없다.
-서버에 사용자 목록을 저장한다. 그래서 요청된 리소스가 많거나 사용자가 많으면 목록에서 권한을 확인하는 시간이 길어진다.
-서버에 현실적으로 저장할 수 있는 데이터는 한정되어 있어서 사용자가 많거나 사용자 변화가 잦은 서비스가 Basic 인증을 사용하면 서버에 부담이 커진다.
-사용자 권한을 정교하게(디테일하게) 제어할 수 없다. 사용자가 꼭 필요한 리소스에만 권한을 주는 게 좋은데, Basic 인증 방식은 세세하게 사용하기 위해서 사용자의 권한을 설정하려면 추가 구현이 필요하다.
-다소 구시대적인 인증 방식이다.
2. Bearer 인증
특징
- OAuth 2.0 프레임워크에서 사용하는 토큰 인증 방식
- "Bearer"는 소유자라는 뜻을 가진다. 즉, 이 토큰의 소유자에게 권한을 부여해줘라는 의미로 붙여진 것이다.
- ex) Bearer와 토큰을 인증 헤더에 입력한다.
- 참고: RFC 6750에 정의 - The "Bearer" OAuth Access Token Type
Authorization: Bearer <token>장점과 단점
-
장점
1.안전하고 확장이 다소 쉽다.
-쉽게 복호화가 불가능하며, OAuth는 프레임워크의 인증 및 리소스 서버는 SSL/TLS를 필수로 사용한다. 또한, 서버에서 토큰의 리소스 접근 권한을 쉽게 철회할 수 있고, 토큰의 유효기간을 설정하여 안전하게 리소스를 보호할 수 가 있다. 마지막으로 제한적으로 리소스 접근을 정교하게 설정할 수 있다.
2.서버에 저장을 하지 않아도 된다.
-Bearer 토큰 자체가 메타데이터를 가지고 있어서 서버는 토큰을 발급만 하고 보관할 필요가 없다. 그래서 사용자가 많아도 토큰을 검증하는 과정은 같은 시간이 소요된다. 또한 여러 서비스 및 서버 간에 토큰을 공유할 수 있어서 사용자에게 편리한 경험을 제공해준다. -
단점
1.보안 문제 발생 우려
-충분히 복잡한 알고리즘이지만, 외부로 토큰이 노출되면 리소스 접근이 가능해져 보안 위험이 증가된다. 하지만 서버가 OAuth 프레임워크에 정의된 보안 장치를 잘 구축하면 문제가 없고 노출이 발견되면 해당 토큰의 권한을 철회가 가능하다.
