[영상후기] WEB2-OAuth

• OAuth : 사용자의 ID/PW가 아닌 accessToken 활용하여 나의 서비스가 연동하고자 하는 서비스와 연결할 수 있게 해줌

  • 사용자가 나의 서비스를 활용하여 구글 캘린더에 일정 등록 등
  • 나의 서비스가 연동하고자 하는 서비스에 접근할 수 있어야 함
  • 회원의 ID와 PW를 처음부터 보관하지 않고 회원을 식별할 수 있는 기능 구현 가능
    • 페이스북(구글) 아이디로 특정 사이트 로그인 등
  • 모든 기능을 허용하는 것이 아닌 일부 기능을 허용하는 Access Token을 얻는 과정

• 영상에서 다룬 용어 ( -> OAuth의 용어)

  • mine : 우리가 만든 서비스
    • Client : 리소스서버에 접속하여 자원을 가져가는 클라이언트
  • User(Resource Owner) : 사용자
    • Their 라는 서비스에 회원가입이 되어 있어야 함
  • Their(Resource Server) : 연동하고자 하는 서비스
    • 제어하고자 하는 자원을 가지고 있는 서버(데이터 보유)
    • Authorization Server : 인증관련된 처리를 전담하는 서버
    • 공식 메뉴얼에서는 2개로 구분하지만, 영상에서는 Resource Server로 통일

• Access Token 발행받기 위해서는 총 4개의 단계 필요, 각각의 단계로 나누지만 번호는 이어서 밑에 정리함

  • Client의 App 등록
  • Resource Owner의 client 승인
  • Resource Server의 승인
  • Access Token 발행

Client의 App 등록

(1) Client(제작 앱)에서 Resource Server에 등록(사전 승인)

• 등록 : Client(만든 서비스)가 리소스서버에 사전에 승인을 받는 것
  • 서비스마다 다르지만 3개 공통
    • Client Id : 우리가 만들고 있는 어플리케이션 식별자(노출 가능)
    • Client Secret : 어플리케이션 비밀번호 (노출되면 안됨)
    • Authorized redirect URls : 리소스 서버가 권한 부여하는 과정에서 Authorized Code라는 값을 이 주소로 전달해달라고 알려주는 URl -> 리소스 서버는 해당 url이 아닌 다른 주소로 요청시 무시

Resource Owner의 client 승인

(2) User(Resource Owner)가 만든 앱(Client)에 서비스 요청
(3) 특정 권한이 필요하다고 안내, 동의 물어봄
ex) 페이스북, 카카오톡 등 로그인 버튼 활성화
(4) 버튼을 누르면 Resource Server로 링크 접속
(4-1) 이를 확인한 서버에서는 사용자가 로그인을 하지 않은 상태면 로그인 요청
(5) 로그인 후에는 사용자가 요청한 링크가 등록된 client_Id인지 Resource Server에서 확인
(6) 정보가 맞다면 사전에 지정한 scope(권한)에 대해 사용자가 동의하는지 확인창
(6-1) 승인 시 User의 Id와 승인한 Scope를 서버에 저장
허용 메세지를 받은 리소스 서버에는 user1, A,B 권한 이런식으로 추가됨

Resource Server의 승인

• 사용자가 동의를 했더라도 바로 AccessToken을 발행하지 않고 아래의 과정을 거쳐야 함(Authorization code 활용 방식)

(7) 이전에 허용한다는 User의 메세지에 응답으로 Authorization code를 실어서 리다이렉트 하라고 응답
-> Resource Owner의 browser에게 code를 포함한 client 주소로 Redirect 하라 요청
(8) Resouce Owner의 브라우저에서는 리다이렉트하여 우리가 만든 앱(client)으로 이동
(9) client에서는 해당 Authorization code, 클라이언트 ID, 시크릿, 리다이렉트URL을 포함한 값을 리소스서버에게 바로 보냄(Resouce Owner를 거치지 않음)
(9-1) Resource Server에서는 위의 정보를 모두 확인

Access Token 발행

(10) 일치한다면 authorization code 삭제
(11) AccessToken을 서버에 저장하고 Client에게 응답

• 클라이언트 내부 AccessToken 저장 및 응답
• 의미 : Client가 해당 Access Code로 접근하면 사용자의 유효한 기능(Scope)은 허용해줌
• 그림에서 user2, 기능 A, B만 가능한 Access Token으로, 다른 기능 접근 시 불가

API 호출

• 리소스서버가 클라이언트들에게 우리를 사용하려면 이렇게 해야 한다 는 API 제공
  • 인증이 필요 -> AccessToken 활용
  • ex) 구글 캘린더로 일정 불러오기 : API주소 + 파라미터로 AccessToken 입력
  • 제공 여부, 사용 방법, API URI는 메뉴얼을 보며 확인해야 함

Refresh Token

• Refresh Token : AccessToken은 수명이 있음(1시간~60일)

  • API가 데이터를 주지 않음
  • Access Token을 새로 발급 받아야 함 -> 이전 과정을 다시 반복해야함(사용자에게 또 승인 요청)
  • 만일 Access Token이 만료되면, Refresh Token을 활용해 손쉽게 새로운 Access Token 발급
    • Refresh Token도 갱신하는 것도 있고, Refresh Token 갱신 없이 Access Token만 계속 새로 발급 방식도 있음

• Access Server마다 refresh 방식이 다르기 때문에 메뉴얼 파악 필요

• 보통 Access Token 발생 시 Refresh Token 같이 발급