OAuth

1️⃣ OAuth 소개

: 애플리케이션이나 파일과 같이 보호를 받는 리소스에 대한 권한 인증을 제어하는 프레임워크

• 만약 ‘소셜로그인’이라는 것이 ‘카카오, 구글’ - ‘내가 사용하고 싶은 웹/앱’ 사이에서 나의 아이디와 비밀번호를 공유하는 것이라면? —> 보안상 문제 발생!
• ‘카카오, 구글’ - OAuth - ‘내가 사용하고 싶은 웹/앱
• OAuth는 카카오,구글과 내가 사용하고 싶은 웹/앱 사이에서 로그인을 중개해주며 서비스를 안전하게 상호작용하며 사용할 수 있게 해 준다.

2️⃣ OAuth의 accessToken

• 아이디와 비밀번호 대신에 accessToken이라는 일종의 암호를 발급한다.
• accessToken은 구글의 모든 기능이 아닌 그 중 나의 서비스가 꼭 필요한 필수기능만 부분적으로 허용하는 비밀번호이다.
• ‘내가 사용하고 싶은 서비스’는 OAuth를 통해 accessToken을 획득한 다음 그 토큰으로 구글, 카카오에 접근해서 데이터의 CRUD 작업을 할 수 있게 된다.

3️⃣ 절차

1. Client 등록
   • client(사이트)가 resource server(구글,카카오)를 이용하기 위해서는 사전 승인을 받아야 한다.
   • register : 사전 승인
   • resource server 마다 사전 승인 방법은 상이하다.
   • 공통적으로 register에서 받는 것
     1. Client ID : 내가 만들고 있는 어플리케이션을 구분하는 식별자 → 노출 무방
     2. Client Secret : Client ID에 대한 비밀번호 → 노출 금지
     3. Authorized redirect URIs : Authorized Code를 전달받을 주소
        1. Resource Server로부터 권한을 부여받는 과정에서 Authorization Code라는 값을 전달받는다.
        2. 지정된 주소 이외의 다른 주소에서 요청하면 Resource Server는 무시한다.

2. Resource Owner의 승인

   • Client가 Resource Owner에 등록하면 양쪽 모두 세 가지 핵심정보(공통적으로 register에서 받는 것 )를 알게 된다.
   • Client는 redirect URI에 대한 페이지를 구현하고 준비해놓고 있어야 한다.

   1. Resource Owner는 나의 서비스(사이트)에 접속한다.

   2. 서비스 이용 과정에서 나의 서비스가 Resource Server를 사용하는 작업을 해야 한다면 Resouce Owner에서 소셜 로그인 버튼을 보여준다.

      • 버튼에는 리소스 서버에 client id값, 사용할 기능(Resource Server가 정해놓은 형식), 인증코드를 전달받을 redirect URI를 쿼리 파라미터로 넘기는 링크를 걸어준다.

   3. Resource Owner가 버튼을 눌러서 Resource Server로 접속을 한다.

   4. Resource Server는 Resource Owner의 현재 로그인 여부를 파악한다.

   5. Resource Owner는 로그인을 수행한다.

   6. 로그인이 완료되면 Resource Server는 비교 검증을 한다.

      • 서버 주소 뒤에 파라미터로 넘어온 client id값과 동일한 client id값이 존재하는지 확인
      • 서버가 갖고 있는 client id = ?에 해당하는 redirect URI 값이 접속을 시도하는 요청에 함께 넘어온 redirect URI와 같은지 확인

   7. Resource Owner에게 Scope(사이트가 필요로 하는 정보)에 해당하는 권한을 Client에게 부여할 것인지 확인 메세지를 전송하게 된다.

      ex - “어떤 client가 다음과 같은 항목들을 요청하는데 허락하겠습니까?”

   8. 허용 버튼을 누르면 허용했다는 정보들이 Resource Server로 전송된다.

   9. Resource Server는 회원의 허용정보를 수집한다.

3. Resource Server의 승인

   • Resource Server는 accessToken을 발급하기 전에 임시 암호인 Authorization Code를 발급한다.

   1. Resource Server는 Authorized Code를 회원에게 전송한다.

      • 전송할 때 header 값에 Location을 주는데 이는 redirection 명령에 해당한다.
      • Resource Server가 회원의 웹브라우저에게 https://client/callback?code=3이라는 주소로 이동하라고 명령한 것이다.
        → ?code=3 부분이 Authorization Code에 해당

      

   2. Resource Owner의 웹브라우저는 회원이 인식하지도 못할 만큼 은밀하게 주어진 주소로 이동한다.

      • Client는 이 주소를 바탕으로 Authorization Code를 알게 된다.

      

   3. Client는 Resource Owner을 통하지 않고 Resource Server에 직접 접속한다.

      • 지금까지 알아낸 정보와 client secret을 함께 보낸다.

   4. Resource Server는 클라이언트가 넘긴 code와 client_id, client_secret, redirect_uri
      4가지가 모두 일치하는지 확인하고 다음 단계로 넘어간다.

4. Access Token 발급

   1. Resource Server는 code 값을 지워야 한다. 그래야 다시 인증하지 않는다.

   2. Resource Server는 Access Token을 발급하고 Client에게 응답해준다.

   3. Client는 Access Token을 내부적으로 서버에 저장한다.

      

5. API 호출
- API : Client가 Resource Server가 알려주는 방식대로 조작해야 하는데, 여기서 그 방식
- 사용하는 방법 : Header에 “Authorization : Bearer [Access Token]” 넣는다

6. Refresh Token 발급
   - Access Token은 수명이 있다.
   - Refresh Token : Access Token이 수명을 다했을 때 새로운 토큰을 발급받는 방법
   - 방법은 Resource Server마다 다르다.
   1. Access Token을 발급할 때 Refresh Token을 발급하는 경우
   2. Refresh Token도 주기적으로 새로 발급하는 경우