여러 블로그를 돌다가 든 생각은,
카카오나 구글, 페이스북 등 OAuth 토큰을 발급 받고 DB에 회원 정보를 구축하는 단계에서 좋지 않은 방법으로 비밀번호를 생성하는것 같다.
OAuth제공자의 DB가 가지고있는 유저 Identifier와 유저의 이메일 정보를 조합하여 non-null의 비밀번호를 생성하는데,
보안 레이어에서 내가 만든 웹 어플리케이션과 OAuth 제공자가 연관성을 띈다면 향후 확장성이나 디자인 측면은 제껴두더라도, 기분이 좋지 않다.
OAuth을 거친 회원들은 DB상으로 password에 null값을 가질 수 있고, 일반 회원은 null이 될수 없게 만들면 좋을것 같다.
필자가 TradingView에서 카카오 회원가입을 한 후 비밀번호를 수정하니 일반 로그인이 가능했던것으로 미뤄봤을때, Trading View도 대충 이런식으로 작동하는것 같다.
몇가지 시나리오를 가정하여 구상해보려고 한다.
클라이언트단에서 form의 input에 required 속성을 추가할 때:
일반 사용자가 OAuth인증을 거친 회원의 아이디를 알아내서 null값의 비밀번호로 로그인하는 상황을 만들어선 안된다. required 속성을 추가하여 input란이 null값일 때 클라이언트단에서 submit을 할 수 없게 만든다.
임의로 제작한 HTTP Request로 null값을 보낼때:
Postman으로 테스트를 해보았다. raw하게 JSON으로 요청하면 crypting단에서 null값을 거절하는데, form 방식으로 보내면 왜인지 모르게 암호화를 해버린다. 빈 문자를 그대로 받는것 같다.
만약 빈 문자가 들어온다면 crypting 이전에 null로 치환하거나, null과 “”에 대해 예뢰처리를 하는 방식을 고려해보아야 한다.
OAuth 제공자의 종류
구글, 페이스북, 네이버, 카카오 등 다양한 OAuth 제공자들이 있는데, 사용자가 가입하고 인증한 경로의 제공자를 유저 정보에 집어넣을 필요가 있을까?
유저는 각 제공자에게 받아온 토큰으로 인증처리가 되기 때문에 유저정보가 한데 모여 뒤섞여 일어나는 불상사는 없을것 같다.
애플리케이션이 이를 구분하여 서비스에 차이를 둔다면 필요하겠지만, 그렇지 않다면 자원낭비이다.
하지만 차후 기능을 추가할 일이 생긴다면 그때 가서야 유저 정보를 전부 수정한다는것 또한 리스크일것이다.
