16일
결국, Project 에서 Basic Auth을 쓰지 않기로 결정한 경험담
- Basic auth 는 HTTP/HTTPS 의 가장 기본이 되는 인증 방법이다.
- 사용자는 ID/PW를 Base64 encoding 해서 매 request에 Header에 실어 보내게 된다.
- 이 과정은 Browser 에 의해 처리 되며, 사용자는 Browser의 ID/PW 입력창을 보게 된다.
- 별도의 암호화나 expired method는 제공 되지 않는다.
- Basic Auth 장점
- Cookie Free 로 만들수 있다.
- 엄밀하게 말하면 Cookie와 유사한 별도의 header를 사용 하는 것이므로, 기술적으로는 cookie 와 차이가 없다.
- EU의 Cookie 법률 같이 Cookie 에만 집중하는 법률은 회피할수 있다.
- Stateless 구조로 만들수 있다.
- 구현이 간단하다.
- Basic Auth의 한계점
- 종단간 암호화가 되지 않는 HTTP 에서는 header에 ID/PW가 그대로 노출되므로, HTTPS에서만 사용 하여야 한다.
- Expired method가 제공되지 않아, 한번 노출된 PW로 지속 접근이 가능하다.
- 물론 이를 극복하기 위해 짧은기간만 사용가능한 별도의 Password를 받아 사용 하는 방안도 고려해볼수 있다.
- Password를 마치 token 처럼 사용 하는 것인데, 이를 위해서는 별도의 token 관리를 구현해야 한다.
- 인증 과정이 Browser 마다 구현이 다를수 있다.
- 예를 들어, chrome 에서는 인증정보를 URL 에 넣는 방식을 지원하지 않는다.
- 잘못 구현된다면 모든 request 마다 인증정보를 넣어야 할수도 있다.
- Page 이동마다, API 마다 ID/PW를 입력하는것은 사용성이 좋지 않다.
- 왜 Basic auth 를 쓰려고 했는가.
- Login 기능을 가지고 있지만, Cookie free Website를 만들어 보고 싶었다.
- 웹을 장악한 cookie 관련 동의 버튼이 싫었음.
- SPA(single page application) 으로 만들고, Session storage 등을 사용하는 방안도 있었지만, 되도록 JS를 사용하지 않는 환경을 만들고 싶었음.
- 잊혀진 기술을 사용해서 어디까지 확장할수 있을지 도전 하고 싶었음.
- Stateless를 위해 JWT,Session Storage, 등을 도입해서 복잡한 구현을 가져가야 할지 의문이 들었음.
- 왜 Basic auth 를 쓰지 않기로 결정했는가?
- 로그인 된 상태인지 확인이 어려움.
- 대부분의 Browser 구현은
401 response(with WWW-Authenticate header) 를 받기 전에는 인증정보를 보내지 않음.
- Browser 입장에서는 당연한데, 굳이 인증이 필요없는 Page에 인증 정보를 보내서 인증정보가 노출되는 위험을 감수할 필요가 없음.
- Auth 정보를 이미 사용자에게서 받아서 browser 가 가지고 있더라도
401 response가 오기 전에는 보내지 않음.
- Login 되었을때 Page의 일부만 내용이 바뀐다면, Server 입장에서는
401응답을 보내 인증정보를 보내라고 요청할지 200 응답으로 로그인 하지 않고도 볼수 있는 Page 를 Rendering 할지 결정이 어려움.
401 response를 보냈는데 사용자가 정말 guest 라면, 사용자는 입력할수 있는 인증정보가 없는데, 인증을 하라는 상황이 됨.
- 인증 없이 볼수 있는 content 가 있음에도 읽지 못함
200 response를 보냈는데 사용자가 Login 된 정보에 접근 해야 한다면, 사용자 입장에서는 해당 정보에 접근할 방법이 사라짐
- API 로 별도 요청을 하거나 하는 등 별도로 관리할수 있으나
- Login 실패에 대한 사용자 경험이 좋지 않음
- 인증정보를 기입하는 창에서 잘못 입력한 경우, 사용자는 인증 정보를 입력하는 modal을 다시 마주하게됨.
- 해당 modal은 잘못된 인증 정보라는 내용을 전달하기 어려움.
- Spec상에 Error시 보여줄 메세지 등이 정의 되지 않았기 때문.
- 사용자는 올바르게 입력했다고 생각했기 때문에 서버의 오류라고 인지할수도 있음.
- 매우 old 한 modal 은 이런 생각을 강화함.
- Scope가 없음.
- 어느 페이지에서 인증정보가 필요한지 Basic Auth에서 지정되는 방법이 없음.
- Realm 이 이를 위한 값이긴 하나, Realm 을 얻기 위해서는 요청을 보내
WWW-Authenticate header의 값을 봐야 함.
- 이는 매 페이지마다 request without auth header -> 401 -> request with auth header -> 200 의 Step 을 밟을수 밖에 없다는 의미임.
- Cookie 는 명시적으로 매 요청마다 보내도록 되어 있어 이런 문제가 없음.
- Basic Auth는 이에 대한 표준이 없기 때문에 Browser마다 동작이 차이가 날수도 있음.
- Login Modal 을 표시하는 것에 대한 주도권이 개발자에게 주어지지 않음.
- Basic Auth 는 API 호출에 대해서도 사용자 Modal을 띄울수 있음.
- 이는 API 호출 시점을 자유롭게 할수 없게 하고, API 의 인증 적용 자체를 꺼려지게 할수 있음.
- 이에 대한 개선 아이디어들은 있으나 진행되지는 않음.
- API 에 대해서는 Basic Auth 대신 Baerer Token 등으로 처리할수 있으나 그러려면 사용자가 두번 로그인 하거나 별도의 Token 발급 과정등 사실상 Basic Auth가 필요 없는 상황이 됨.
- 어떤 Project 에서 Basic Auth 를 선택 해야 하는가?
- Login 된 유저와 Login 되어 있지 않는 유져의 접속경로가 명확히 URL 로 구분되는 Project
- 한 URL 에서 서로 다른 Page 를 Render 하지 않는 Static Page 만 서빙 하는 case등
- 이미 다른 방식등으로 Token 등을 발급 받고 이를 이용해서 Basic Auth 를 하는 경우
- 즉 응답으로
WWW-Authenticate header를 주지 않아 사용자에게 인증정보 입력 Modal 을 띄우지 않는 Project
19일
29일
31일