SEB_BE 66일차 - OAuth2 인증 1

💡 오늘의 학습목표

• OAuth2란?
• OAuth2의 동작 방식

📔 OAuth2 란?

• 전통적으로 서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜을 직접적으로 관리하는 것이 일반적.

• OAuth2는 특정 애플리케이션(Client)에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할만한 써드 파티 애플리케이션 (google, GitHub 등) 에서 사용자의 인증을 대신 처리해 주고 Resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식.

📖 OAuth2를 사용하는 애플리케이션 유형

1. 써드 파티 애플리케이션에서 제공하는 API의 직접적인 사용
2. 추가적인 인증 서비스 제공 용도
   일반적으로 제공하는 아이디/패스워드 로그인 인증 이외에 OAuth2를 이용한 인증 방법을 추가적으로 제공하는 것

📔 OAuth2의 동작 방식

📖 OAuth2 인증 컴포넌트(구성요소) 들의 역할

• Resource Owner
  • 사용하고자 하는 Resource의 소유자
    Google 등의 서비스를 이용하는 사용자
• Client
  • Resource Owner를 대신하여 보호된 Resource에 액세스하는 애플리케이션
    서버, 데스크탑, 모바일 또는 기타 장치에서 실행되는 애플리케이션이 될 수 있다.
• Resource Server
  • OAuth2 인증 처리 흐름 상에서의 리소스서버는 Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버
    ( A 애플리케이션이 Google Photo에서 J라는 Resource Owner의 사진을 가져오는 경우 Google Photo 서비스를 제공하는 애플리케이션이 리소스 서버가 됨.)
• Authorization Server
  • OAuth2 인증 처리 흐름에서는 Client가 리소스 서버에 접근할 수 있는 권한을 부여하는 서버
    Resource Owner가 인증에 성공하면 Authorization Server는 Client 에게 Access Token 형태로 Resource Owner의 Resource에 접근할 수 있는 권한을 부여함.
    
    
• 컴포넌트 간의 상호 작용을 통한 인증 처리 흐름

• (1) Resource Owner는 Client 역할을 하는 웹 애플리케이션에게 OAuth2 인증을 요청
• (2) Client는 리소스 오너의 계정 정보를 관리하고 있는 써드 파티 애플리케이션에 로그인 할 수 있도록 써드 파티 애플리케이션의 로그인 페이지로 리다이렉트
• (3) 리소스 오너는 로그인 인증을 진행하고 성공하면
• (4) Authorization Server가 리소스 오너의 인증이 성공하였음을 증명하는 Access Token 을 Client에 전송
  Authorization Server가 Access Token을 전송하는 것이 아니라 Client 애플리케이션에 전송하는 것
• (5) Access Token을 전달받은 Client는 리소스 오너의 대리인 역할을 수행할 수 있게 되었음. 리소스 서버에게 리소스 오너 소유의 리소스를 요청
• (6) 리소스 서버는 Client가 전송한 Access Token을 검증해서 Client가 리소스 오너의 대리인으로써 자격이 증명되면 리소스 오너의 리소스를 Client에게 전송

📖 OAuth2 인증 프로토콜 용어

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

📖 Authorization Grant 유형

1. Authorization Code Grant : 권한 부여 승인 코드 방식

• 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식, 가장 많이 쓰이고 기본이 되는 방식
• Refresh Token 사용 가능
• 권한 부여 승인 요청시 응답 타입(response_type)을 code로 지정하여 요청
  

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

2. Implicit Grant : 암묵적 승인 방식

• 별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식
  자격증명을 안전하게 저장하기 힘든 Client (스크립트 언어를 사용하는 브라우저) 에게 최적화된 방식
  Refresh Token 사용이 불가, Authorization Server는 Client Secret을 통해 인증 과정 생략
• 권한 부여 승인 요청시 응답 타입 을 token으로 지정하여 요청

3. Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식

• 로그인 시 필요한 정보 (username, password)로 Access Token을 발급받는 방식, 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식, Refresh Token의 사용 가능
• ex) 네이버 계정으로 네이버 웹툰 애플리케이션 로그인
• Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때 사용 가능

4. Client Credential Grant : 클라이언트 자격 증명 승인 방식

• Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용 가능한 방식
• 자격증명을 안전하게 보관할 수 있는 Client에서만 사용, Refresh Token의 사용은 불가능