프론트엔드 Oauth 인증
서비스 개발 과정에서 로그인이 필요해졌다. 유저의 플레이리스트를 저장해야하고, 중복 등록을 막아야 하기 때문이다. 로그인 정책에도 여러 방식이 있다. 자체 인증 과정을 만들 수도 있으며, 구글과 카카오 같은 플랫폼을 통해 인증하는 방법도 있다. 우리 기술 수준에서는 자체적으로 보안을 철저하게 지킬 수 없다는 판단을 했다. 사용자는 보통 같은 아이디와 비밀번호를 사용하는 경우가 많다. 따라서 만약 우리 서비스로부터 사용자 정보가 해킹당한다면, 다른 사이트에서도 해킹될 수 있는 가능성이 높다. 현재 팀의 기술 수준으로 보았을 때 보안을 철저하게 지킬 수 없다 생각하여 Oauth를 통해 거대 플랫폼에 위임하는 방식이 낫다고 판단하였다.
위의 Oauth 플로우는 서버(인증 클라이언트)와 인증 서버와의 플로우다. 이번에는 우리 서비스의 Client와 Server와의 플로우를 확인해보면 다음과 같다.
- 클라이언트에서 카카오나 구글에서 제공해주는 Oauth 인증 페이지로 리다이렉트시켜준다.
- 해당 페이지에서 유저가 로그인을 하면 지정해준 리다이렉트 페이지에 인증 코드가 담긴 URL을 보내준다.
- 클라이언트에서 인증 코드를 받아서 서버에 요청을 보낸다.
- 서버는 카카오나 구글에 인증 코드를 보내준다.
- 카카오나 구글에서 인증 코드를 확인 후에 유효하면 access token을 보내준다.
- 서버에서 해당 access token을 확인한 후에 자체적으로 access token을 다시 만든다. 이때 주의할 점은 전자의 access token은 카카오나 구글에 대한 인증 정보를 담은 토큰이고, 후자는 서버에 대한 인증 정보를 담은 토큰이다. 그리고 서버는 클라이언트에게 응답으로 access token을 담아 보낸다.
로그인이 도입된 이후 사용자 경우의 수가 굉장히 많아졌다. access token, refresh token을 기준으로 여러 상태가 있고 이를 고려해야하기 때문이다.
| access token | refresh token | 결과 |
|---|---|---|
| 유효 | - | 본 요청 / 인증 성공 |
| 기간 만료X | ||
| but, 회원 정보가 틀린 경우 (탈퇴 등으로 인하여) | 유효 | 본 요청 / 401 |
| 기간 만료 | 유효 | 갱신 요청 / 인증 성공 |
| 본 요청 / 인증 성공 | ||
| 기간 만료 | 기간 만료 및 유효 X | 갱신 요청 / 401 |
이를 그림으로 그리면 다음과 같다.
