본문 바로가기

카테고리 없음

[사이드프로젝트] Oauth 회원가입 및 로그인 - 카카오

728x90

2022.10.01 - [분류 전체보기] - [사이드프로젝트] 프로젝트 설정 - CloudWatch / EC2 배포

 

[사이드프로젝트] 프로젝트 설정 - CloudWatch / EC2 배포

2022.09.29 - [분류 전체보기] - [사이드프로젝트] 프로젝트 설정 - CI/CD [사이드프로젝트] 프로젝트 설정 - CI/CD 2022.09.28 - [분류 전체보기] - [사이드프로젝트] 사전 준비 [사이드프로젝트] 사전 준비

juna-dev.tistory.com

OAuth를 활용해 프로젝트 유저를 구현하기로 했다. 우선 접근하기 가장 쉬운 카카오를 사용하기로 하였고, 해당 문서를 참고했다.

카카오 OAuth

우선 OAuth에 관해 간단히 흐름을 보자면

  1. Client(웹)에서 Authorization Server(카카오 인증 서버)에 redirect uri, client id, response type등을 명시하여 요청을 한다
  2. Authorization Server는 Resource Owner(사용자)에게 Client가 요청한 정보에 대해 접근 허용을 할 것인지 확인한다
  3. Resource Owner가 허용했다면 Authroization Server는 Redirect URI로 Authorization code를 전달해준다
  4. Redirect URI를 받은 서버(내가 운영하는 서버)는 인증 코드를 가지고 Authroization Server에 access token을 요청한다
  5. AUthroization Server는 code를 체크하여 valid하면 access token을 발급해준다
  6. access token을 받으면 Resource Server(카카오 회원 서버)에 해당 access token을 가지고 Resource Owner 정보를 가져온다.

용어를 다시 정리하자면,

  • Resource Owner :  사용자 (애플리케이션이 원하는 데이터를 소유하고 있는 주체)
  • Client : 애플리케이션
  • Authorization Server : 데이터 접근 권한에 대해 허용할 지 말지 유저에게 묻는 서버
  • Resource Server : client가 실제로 얻고 싶은 데이터를 가지고 잇는 서버
  • Redirect URI : Authorization Server 가 끝나면 Authorization code를 받을 url
  • Access Token : 허용받은 데이터를 가지고 오기 위해 사용하는  열쇠
  • Authorization Code : Authorization Server가 던져주는 것, 이것을 가지고 Redirect URL은 다시 Authorization Server에게 Access Token을 달라고 한다.

여기서 의문이 드는게 Authorization code와 access token을 왜 분리하고 있는지 이다. 사용자의 동의를 받았으면 바로 access token을 발급받고, resource server에 요청할 수 있지 않을까 싶은것 이다.

하지만 이는 Back / front channel의 장점을 최대화하기 위해서 사용한다고 한다.

 

Back Channel(highly Secure channel) : 본인 서버 내부에서만 동작하는 API or 타 서버에 api 요청하는 서버 → 보통 백엔드 서버

Front Channel(less Secure channel) : 브라우저에 보여지는 서버 → 보통 클라이언트 서버

 

Front Channel이 Redirect URI, Response Type, Scope등을 query param에 담아서 Authorization Server로 유저가 로그인하도록 request (Full Page Redirect) → redirect uri로 쿼리 파라미터로 auth code가 전달되는데, 이걸 누군가 보더라도 문제 없다.

하지만 back channel 내부에서 다른 api를 요청하는 것은 외부에 보이지 않는다.

back channel에서 auth server에 access token 요청 -> post로 secret key와 함께 보안적으로 보낸다 -> auth code가 탈취당하더라도 secret 코드가 검증이 된다. Secret key가 필요해서 back channel 사용하는 이유도 있다.

Resource server로 보내는 것도 back channel 담당 -> access token 탈취당하면 안되기 때문이다.

 

개인적인 생각으로는 이러한 방식은 보안 및 속도(?) 측면에서 이점을 가지지만, client id를 front, back channel이 모두 관리해야한다는 단점이 존재하는 것 같다. 혹시라도 client id가 바뀐다면 front/back 모두 변경이 필요할 것이다.

 

그래서 카카오 로그인 가이드 문서에는 이렇게 나와있나 싶다.

Kakao Developers

 

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

front channel에서 바로 auth server를 호출하는게 아닌 back channel에 위임하여 auth server로 전달함으로써, back channel에서만 카카오 로그인에 관한 관리 포인트를 가져가는 것이 아닌가 싶다. (front channel이 앱이 포함되어 있다면 back channel에서 모두 해야될 수밖에 없다.. 하위 버전에서는 client id를 바꿀수가 없기에)

 

우선은 정석대로 redirect uri를 서버에서 받아서 그 이후 작업을 수행하는 것으로 구현하고, 나중에 좀 더 고민해보고 카카오 방식으로 바꿀지 해야겠다. (클라이언트는 웹밖에 없음) 단, 카카오는 secret 키를 사용은 optional이기 때문에, front channel에서 인가 코드를 받도록 하면 노출이 되기때문에 back channel에서 모두 구현하거나, secret 키를 활성화 해야된다.

 

참고 자료 :

OAuth 2.0 and OpenID Connect (in plain English)

 

728x90