카테고리 없음

DRF + ML 4일차

best_spear_man 2023. 6. 1. 11:53

OAuth를 적용하기 위해 Oauth에 대해 알아보았다.

1. OAuth

웹 서핑을 하다 보면 Google 등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있으며
이 때 사용되는 프로토콜이 OAuth(Open Authentication)이다.

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준

  1. OAuth의 참여자

    • Resource Server : Client가 제어하고자 하는 자원을 보유하고 있는 서버(구글)
    • Resource Owner : 자원의 소유자(로그인하려는 사용자)
    • Client : Resoure Server에 접속해서 정보를 가져오고자 하는 클라이언트(DRF 혹은 프론트엔드)

  2. OAuth Flow

    1. Client 등록: Client(웹 어플리케이션)가 Resource Server를 이용하기 위해서는 자신의 서비스를 등록함으로써 사전 승인을 받고 3가지 정보를 받는다.
    • Client ID : 어플리케이션을 구별할 수 있는 식별자 (노출 무방)
    • Client Secret : 비밀키 (절대 노출 금지)
    • Authorized redirect URL : Authorization Code를 전달받을 리다이렉트 주소(직접 지정)
      Google 등 외부 서비스를 통해 인증을 마치면 클라이언트를 명시된 주소로 리다이렉트 시키는데, 이 때 Query String으로 특별한 Code나 access_token이 함께 전달된다. 클라이언트는 해당 Code와 Client ID 및 Client Secret을 / access_token과 Client ID를 Resource Server에 보내, Resource Server의 자원을 사용할 수 있는 Access Token을 발급 받거나 서버의 자원을 받는다. 등록되지 않은 리다이렉트 URL을 사용하는 경우에는 인증이 거부된다.

    1. Resource Owner의 승인
      정해진 주소로 GET 요청과 필요한 파라미터들을 보낸다. 파라미터의 세부 옵션에 대한 내용은 각 서비스 제공자의 공식 문서를 참고한다. Resource Owner는 Client의 웹 어플리케이션을 이용하다가, 해당 주소로 연결되는 소셜 로그인 버튼을 클릭하고 로그인한다. 로그인이 완료되면 Resource Server는 Query String으로 넘어온 파라미터들(client_id, redirect_uri, scope, state ...)을 통해 Client를 검사하고, Client의 접근을 승인하게 된다.

    2. Resource Server의 승인
      Resource Owner의 승인이 마무리 되면 명시된 Redirect URL로 클라이언트를 리다이렉트 시킨다. 이 때 Resource Server는 Client가 자신의 자원을 사용할 수 있는 Access Token을 발급하기 전에, 임시 암호인 Authorization Code를 함께 발급한다. Client는 ID와 비밀키 및 code를 Resource Owner를 거치지 않고 Resource Server에 직접 전달하고, Resource Server는 정보를 검사한 다음, 유효한 요청이라면 Access Token을 발급하게 된다.

    3. Client는 해당 토큰을 서버에 저장해두고, Resource Server의 자원을 사용하기 위한 API 호출시 해당 토큰을 헤더에 담아 보낸다.
      이제 사용자 정보를 통해 회원가입 및 토큰 발급을 진행하면 된다.