HTTP 인증 방식

#보안

웹 서비스에서 인증은 상당히 중요한 요소라고 할 수 있다. 당연히 이게 뚫리거나 노출되면 사용자는 자신의 개인정보부터 시작해서 자산까지도 털릴 수 있기 때문이다...

HTTP 표준 규약에서 정의한 인증 처리 패턴들에 대해서 간략히 정리해보도록 하겠다.

URL에 때려박기

https://아이디:패스워드@foo.com 같은 형태로 URL에 계정 정보를 때려박는 접근법이 있다.

자주 사용되진 않고, 보안상 위험한 점이 많아서 비추천되는 방식이다.

HTTP 프로토콜 수준에서 지원되는거라서 URL 파서를 사용하면 적당히 가져와서 써먹을 수 있다.

Github은 아직도 이 인증법을 잘 제공한다..

기본적으로 인증에 대한 값은 authorization이라는 임의의 헤더로 넘겨서 처리하는 것이 국룰이다.
이게 아니면 쿠키다.

이런 식이다. 이게 bearer 인증인데, 차차 밑에서 다뤄보도록 하겠다.

이건 가장 기본적인 형태의 인증체계라고 할 수 있다.
별건 없고, 그냥 아이디랑 패스워드를 그대로 박아서 보내는 것이다.

그냥 보내지는 않고 atob(${아이디}:${패스워드})의 형태로 base64 인코딩을 해서 그 텍스트를 보낸다.

Authorization: basic atob(`${아이디}:${패스워드}`)

패스워드가 그대로 박혀서 보내지니 위험하다고 생각할 수도 있는데, 사실 HTTPS를 사용하면 헤더도 암호화되니 큰 문제는 없다.

단순하고 쉽지만 좀 구시대적인 방식이라 단점도 많은데, 보안적인 조치로 기존 로그인을 무효화하거나 하려면 세션을 도입하거나 패스워드를 바꾸거나 해야 한다.

인증 처리에 있어서는 이게 대세라고 할 수 있겠다.
JWT 같은걸로 만들어진 임시 인가 토큰을 넣어서 보내는 방식이다.

이를테면 로그인을 하면 로그인 유지를 위한 "1시간짜리 토큰"을 받고 그걸 보내서 1시간동안만 사용하는 형태가 되는 것이다.

Authorization: Bearer 토큰값

짧은 유효시간은 "refresh Token" 같은 세션 개념을 도입해서 보완하곤 한다.

표준적이거나 적극 권장되는 방법까진 아니지만, 여전히 많은 사이트들은 쿠키를 통해서 인증 정보를 브라우저에 저장하고 사용하곤 한다.
당장 네이버만 해도 이렇게

NID_AUT라는 인증값을 쿠키에 박아넣고 요청할때마다 서버에 자동으로 넘어가게 한다.

쿠키에 들어있는 값은 구현하기에 따라서 JWT 같은 임시 토큰일 수도 있고, 서버 세션과 연관된 값일 수도 있다.