[인증/보안] OAuth2

1. OAuth2?

특정 어플리케이션에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할만한 써드파티 애플리케이션(Google, Facebook등)에서 사용자의 인증을 대신 처리해 주고 Resource에 대한 자격 증명용 토큰을 발급 후 Client가 해당 토큰을 이용해 써드파티 애플리케이션의 서비스를 이용하게 해주는 방식이다.
또한 제공받은 인증정보를 크리덴셜 저장소에 저장하지 않는다.

써드파티 애플리케이션의 크리덴셜을 저장하지 않는 아키텍처

---

2. OAuth2 인증 컴포넌트들의 역할

• Resource Owner
  • Resource를 사용하고자 하는 소유자(서비스를 이용하는 사용자)
• Client
  • Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션
  • 예들들어 내가 A라는 애플리케이션을 통해 Google의 소셜로그인을 이용하면 애플리케이션 A가 Client가 된다.
  • Client는 서비스를 이용하고자 하는 쪽이다.
• Resource Server
  • Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버
• Authorization Server
  • Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버

OAuth2의 상호작용을 통한 인증처리 흐름

---

3. OAuth2 인증 프로토콜에서 사용되는 용어

• Authorization Grant
  • Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜을 의미한다.
• Access Token
  • Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위해 사용하는 자격 증명용 토큰이다.
• Scope
  • 주어진 액세스 토큰을 사용하여 액세스할 수 있는 Resource의 범위를 의미한다.

---

 - Authorization Grant 유형

Aithorization Grant유형에는 4가지 유형이 있다.
(Authorization Grant, Implicit Grant Type, Client Credentials, Resource Owner Password Credentials)

• Authorization Code Grant : 권한 부여 승인 코드 방식
  • 권한 부여 승인을 위해 자체 생성한 Authorization Code 를 전달하는 방식으로 가장 많이 쓰이고 기본이 되는 방식이다.
  • Refresh Token를 사용할 수 있다.

Authorization Code Grant 인증 처리 흐름

1. Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client에게 전송한다.
2. Client는 Authorization Server에 Authorization Code를 요청한다. 이 때 미리생성한 Client Id, Redirect URI, 응답타입을 함께 전송한다.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.
4. 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에서 전달한다.(이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달한다.)
5. Client는 전달받은 Authorization Code를 이용해 Access Token 발급을 요청한다. Access Token을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한부여방식, Authorization Code를 함께 전송한다.
6. 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급한다.
7. Client는 발급받은 Access Token을 이용해 Resource Sercer에 Resource를 요청한다.
8. Access Token을 확인한 후 요청받은 Resource를 Client에게 전달한다.
9. 완료!

---

• Implicit Grant :  암묵적 승인 방식
  • Authorization Code없이 바로 Access Token을 발급하는 방식
     - 자격증명을 안전하게 저장하기 힘든 Client에게 최적화된 방식이다.
     - Refresh Token은 사용이 불가능하며, 이 방식에서 Authorization Sercer는 Client Secret을 통해 클라이언트 인증과정을 생략한다.

Implicit Grant 인증 처리 흐름

1. Resource Owner는 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송한다.
2. Client는 Authorization Server에게 접근 권한을 요청한다. 요청과 함께 미리 생성한 Client ID, Redirect URI, 응답타입을 전송한다.(이 때에는 Authorization code를 획득하기 위한 요청이 아니다.)
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.
4. 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달한다.
5. Client는 Access Token을 이용해 Resource Server에게 Resource를 요청한다. 
6. Access Token을 확인한 후 요청받은 Resource를 전달한다.
7. 완료!

---

• Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식
  • 간단하게 로그인 시 필요한 정보(username, password)로 Access Token을 발급받는 방식이다.
  • 예를들어, 네이버 계정으로 네이버 웹툰, 카카오 계정으로 카카오 맵 등의 애플리케이션에 로그인하는 경우가 Resource Owner Password Credential Grant에 해당한다.

1. Resource Owner는 로그인 버튼을 누르는 등의 서비스 요청을 Client에게 전송한다. 이 때 로그인에 필요한 정보(Username, Password)를 이용해 요청한다.
2. Client에서는 Resource Owner에게서 전달받ㄷ은 로그인 정보를 통해 Authotization Server에 Access Token을 요청한다.
3. 요청과 함께 온 정보들을 확인한 후 Client에게 Access Token을 전달한다.
4. Client는 Access Token을 이용하여 Resource Server에게 Resource를 요청한다.
5. Access Token을 확인한 후 요청받은 Resource를 전달한다.
6. 완료!

---

• Client Credentials Grant : 클라이언트 자격 증명 승인 방식
  • Client 자신이 관리하는 Resource, Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 서러정되어 있는 경우 사용 가능한 방식이다.
     - 이 방식은 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야 하고, Refresh Token은 사용 불가하다.

1. Client가 Authorization Server에 Access Token을 요청한다.
2. 요청된 토큰을 Client에게 다시 전달해 준다.
3. Client가 Access Token을 이용해 Resource Server에게 Resource를 요청한다.
4. Access Token을 확인한 후 요청 받은 Resource를 전달한다.