OAuth

등장배경

사용자가 서버에서 정보를 가져와 사용할 수 있는 가장 쉬운방법은 아래와 같음

1. 사용자가 클라이언트에 ID/PW를 입력함
2. 클라이언트는 입력받은 ID/PW를 저장해두었다가 서버접속 시 ID/PW로 인증요청
3. 서버는 클라이언트로부터 요청받은 ID/PW검증 후 클라이언트에 정보제공
4. 클라이언트는 서버로부터 받은 정보로 사용자에게 서비스 제공

하지만 이 방법은 보안에 매우 취약하여 이를 보완하기 위해 등장한 것이 OAuth

---

개념

다양한 플랫폼(구글, 페북 등) 서버의 사용자데이터에 접근하기 위해 클라이언트가 서버로부터 사용자의 접근권한을 위임받을 수 있는 표준 프로토콜

• OAuth에는 전문 용어가 존재함
  • Resource Owner : 사용자
  • Resource Server : 구글, 페이스북, 트위터와 같이 Resource Owner의 Resource(자원)을 가지고 있는 서버
  • Authorication Server : Resource Owner를 인증하고 Client에게 엑세스 토큰을 발급해주는 서버
  • Client : Resource Server의 Resource(자원)를 이용하고자 하는 서비스

위 용어들로 개념을 다시 정리하면

Resource Server에서 Resource Owner의 Resource에 접근하기 위해 Client가 Authorication Server로부터 Resource Owner의 접근권한을 위임받을 수 있는 표준 프로토콜

으로 정리할 수 있다

---

OAuth의 동작 플로우

선행작업

1. Client를 Resource Server에 등록
   • 이때 Redirect URI를 등록함
   • Redirect URI란?
     • 사용자가 처음 요청한 URL이 아닌, 사전에 등록된 다른 URL로 보내는 것을 뜻함
     • 여기선 인증이 성공한 사용자를 사전에 등록된 Redirect URI로만 리디렉션 시킴
     • Redirect URI는 기본적으로 보안을 위해 https만 허용됨
2. Client ID, Client Secret
   • 1번의 등록과정을 마치면 Client ID, Client Secret를 얻음
   • 이 발급된 Client ID, Client Secret은 Access Token을 얻는데 사용됨

동작 메커니즘

• 출처 : https://hudi.blog/oauth-2.0/

1. Resource Owner가 Client에게 로그인요청
   • 로그인버튼을 클릭
2. Client는 Authorization Server에게 로그인 요청
   • Authorization Server가 제공하는 Authorization URL에 response_type, client_id, redirect_uri, scope등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.
3. Authorization Server는 Resource Owner에게 Authorization URL 페이지 제공
   • Client가 빌드한 로그인 페이지인 Authorization URL 페이지를 제공
4. Resource Owner는 Authorization Server에게 ID/PW를 입력하여 인증요청
   • Resource Owner는 Authorization Server로 부터 제공받은 로그인 페이지인 Authorization URL에 ID/PW를 입력하여 인증요청
5. 인증 성공 시, Authorization Server는 Resource Owner에게 Authorization Code를 전달
6. 전달과 동시에 Resource Owner는 Redirect URI를 통해 Client로 리디렉션됨
   • Redirect URI에 Authorization Code를 포함하여 사용자를 리디렉션 시킴
   • Authorization Code란 Client가 Access Token을 획득하기 위해 사용하는 임시 코드이며 수명이 매우 짧음 (일반적으로 1~10분)
7. Client는 Authorization Server에게 Client ID, Client Secret, Authorization Code를 전달
   • Access Token을 발급받기 위해
8. Authorization Server는 Client에게 Access Token을 발급
   • Client는 DB에 발급받은 Resource Owner의 Access Token을 저장
   • 이후 Client는 Resource Server에서 Resource Owner의 Resource에 접근하기 위해 Access Token을 사용
9. Client가 Resource Owner에게 로그인 성공하였음을 알림
10. Resource Owner가 Client에게 Resource Server의 Resource가 필요한 기능을 요청
11. Client가 Resource Server에게 Access Token으로 API호출
    • 저장해둔 Resource Owner의 Access Token을 사용하여 Resource Server의 Resource에 접근
12. Resource Server가 Client에게 Access Token검증 및 Resource제공
    • Resource Server는 Access Token을 검증 후 Client에게 Resource를 제공
13. Client가 Resource Owner에게 Resource제공