OAuth

✅ OAuth(Open Authorization) : 개방형 접근 권한 위임 표준

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

웹 서핑을 하다 보면 Google과 Facebook 및 Twitter 등의 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있습니다.

클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라, 연동되는 외부 웹 어플리케이션에서 Facebook 및 Twitter 등이 제공하는 기능을 간편하게 사용할 수 있다는 장점이 있습니다.

예를 들어, 외부 웹 어플리케이션에 Google로 로그인하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있습니다.

✅ OAuth 참여자

OAuth 동작에 관여하는 참여자는 크게 세 가지로 구분할 수 있습니다.

1. Resource Server(인가 서버) : Client가 제어하고자 하는 자원을 보유하고 있는 서버입니다.
   Facebook, Google, Twitter 등이 이에 속합니다.

2. Resource Owner : 자원의 소유자입니다.
   Client가 제공하는 서비스를 통해 로그인하는 실제 유저가 이에 속합니다.

3. Client : Resoure Server에 접속해서 정보를 가져오고자 하는 클라이언트(웹 어플리케이션)입니다.

---

1. Resource Server(인가 서버)

• 인가 서버는 클라이언트에서 client ID, client Secret을 받습니다.
  (이것들은 클라이언트의 백엔드 서버에 미리 저장해둔다)
  =>접근 권한 위임을 받으려는 수많은 서비스중 해당 클라이언트를 특정 짓고,
  리퀘스트가 해당 클라이언트에서 온다는 것을 증명하기 위해 필요한 값이다.
  
• Scope를 정한다.(유저로부터 넘겨받으려는 권한의 범위)
  서비스 입장에서는 필요한 최소한의 권한을 미리설정해두고,
  유저 입장에서는 스코프가 넓게 설정된 서비스에는 권한을 위임해 주면 안된다!

OAuth 워크플로우

접근 권한을 특정 방식으로 주고 받기 위해서 각 주체들이 해야되는 작업들과 그 순서.

1. 유저가 접근 허용 버튼을 클릭

2. 클라이언트는 인가 서버에 리퀘스트를 보내 유저에 대한 접근 권한 위임을 요청
   

3. 이걸 받은 인가서버는 유저를 로그인 페이지로 리디렉트 시킨다.
   
   3-1. 이메일과 비밀번호는 유저를 확인하기 위해 필요한 내용.
   3-2. 이메일 위의 문장은 어떤 권한을 넘겨주는지에 대한 스코프를 확인시켜주는 내용.

4. 유저가 본인의 이메일과 비밀번호를 입력해서 인증 하면

5. 인가서버는 클라이언트에 Authorization Code 발행
   * Authorization Code : 유저 본인이 권한 위임을 원한다는 걸 확인시켜주는 데이터

6. 클라이언트 프론트엔드는 백엔드에 Authorization Code를 리퀘스트로 보낸다.

7. 그럼 백엔드는 다시 인가서버에 Authorization Code(유저확인)+ Client ID+ Client Secret(서비스확인)을 권한 위임 요청 리퀘스트로 보낸다.

8. 데이터가 모두 유효하다는게 확인되면, 인가서버는 백엔드에게 리스폰스로 accese token을 전달(스코프에 대한 내용도 포함)

• 토큰 형식은 정해져있지않다.

9. 백엔드는 accese token을 사용해서 스코프에 저장된 범위의 작업들을 요청한다.

10. 리소스 서버가 권한 내용을 확인하고, 이 범위 안에 있는 작업들만 승인해준다.

11. 토큰이 만료되면 워크플로우 가장 앞 단계부터 다시 시작하면된다.