OAuth2 개요

OAuth 2

• 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해주고, Resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 통해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식
• 사용자의 크리덴셜을 이중으로 관리할 필요가 없음
  - 관리하는 크리덴셜이 줄어들기 때문에, 보안성 향상
  
  - OAuth 2에 대해
  - https://www.rfc-editor.org/rfc/rfc6749

 

OAuth 2를 사용하는 애플리케이션 유형

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

** 애플리케이션에서 사용자의 크리덴셜을 따로 관리하고 싶지 않을 경우, OAuth 2 방식을 적용시켜 로그인하면 된다.

 

 

OAuth 2 컴포넌트 간의 인증 처리 흐름

 

메인 OAuth 컴포넌트 간의 인증 처리 흐름

 

1. Resource Owner가 Client 역할을 하는 웹 애플리케이션에게 OAuth 2 인증을 요청
   - Resource Owner : Google 등의 서비스를 이용하는 사용자를 뜻함
2. Client는 써드 파티 애플리케이션에 로그인 할 수 있도록 써드 파티 애플리케이션의 로그인 페이지로 리다이렉트
   - Client : 어떤 서비스를 이용하고자 하는 쪽으로, Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션을 뜻함
3. Resource Owner가 로그인을 진행하고 인증에 성공
4. Authorization Sever가 Resource Owner의 로그인 인증이 성공적으로 수행됨을 증명하는 Access Token을 Client 애플리케이션에게 전송
   - Authorization Server : Client가 Resource Sever에 접근 권한을 부여하는 서버
5. Resource Server에게 Resource Owner 소유의 Resource를 요청
   - Resource Server : Client 애플리케이션의 요청을 수락하고 Resource Owner에게 해당 Resource를 제공하는 서버
6. Resource Server가 Resourece Owner의 Resource를 Client 애플리케이션에게 전송

** Client 애플리케이션은 특정 Resource를 소유하고 있는 Resource Owner와 Resource Server 간의 중계 대리인 역할을 수행한다.

 

Authorization Server와 Resource Server로서 API Gateway의 역할 및 처리 흐름

 

OAuth 2 인증 프로토콜에서 사용되는 용어

• Authorization Grant
  - Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜을 의미
  - Client 애플리케이션이 Access Token을 얻기 위한 수단
  - 4가지 타입
  - Authorization Code
  - Implicit
  - Resource Owner Password Credentials
  - Client Credentials
• Access Token
  - Client 애플리케이션이 Resource Server에 있는 Resource를 불러오기 위해 사용하는 자격 증명용 토큰
  - Authorization Code와 Client Secret을 이용해 얻음
• Scope
  - 주어진 Access Token을 이용해 접근할 수 있는 Resource의 범위를 의미

 

Authorization Code 타입

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

- ** 가장 많이 쓰이는 방식

- Refresh Token 사용 가능

- 응답 타입(response_type)을 code로 지정하여 권한 부여 승인 요청

 

Authorization Code Grant 방식의 인증 처리 흐름 (Microsoft 인증 플랫폼을 이용)

 

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 발급을 요청
   - AccessToken을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorization Code를 함께 전송
6. 요청 정보를 확인하고, Redirect URI로 Access Token을 발급
7. Client 애플리케이션은 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청
8. Access Token을 확인하고, 요청받은 Resource를 Client에게 전달

 

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

- ** Authorization Code 없이 바로 Access Token을 발급하는 방식

- 스크립트 언어를 사용하는 브라우저에 최적화된 방식

- Refresh Token 사용 불가, ** Authorization Server는 Client Secret을 통한 클라이언트 인증 과정을 생략

- 응답 타입(response_type)을 token으로 지정하여 권한 부여 승인 요청

 

Implicit Grant 방식의 인증 처리 흐름 (Microsoft 인증 플랫폼을 이용)

 

1. Resource Owner가 Client 애플리케이션에게 서비스 요청
2. Client 애플리케이션이 Authorization Server에게 접근 권한 요청
   - 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송
   - Authorization Code Grant 방식과는 다르게, Authorization Code를 얻기 위한 요청이 아님
3. Resource Owner는 로그인 페이지에서 로그인 진행
4. 로그인이 성공하면, Authorization Server는 Access Token을 Client 애플리케이션에게 전달
5. Client 애플리케이션은 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청
6. Access Token을 확인하고, 요청받은 Resource를 Client에게 전달

 

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

- ** 로그인 시에 필요한 Username/Password만으로 Access Token을 발급받는 방식

- ** Authorization Server, Resource Server, Client 모두 같은 시스템에 속해있을 경우에만 사용 가능

- Refresh Token 사용 가능

- ex) 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우

 

Resource Owner Password Credential Grant 방식의 인증 처리 흐름 (Microsoft 인증 플랫폼을 이용)

 

1. Resource Owner가 Client 애플리케이션에게 서비스 요청
   - Username/Password를 이용해 요청
2. Client 애플리케이션은 Resource Owner의 로그인 정보를 통해 Authorization Server에게 Access Token을 요청
   - 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송
3. 요청 정보들을 확인하고, Authorization Server는 Access Token을 Client 애플리케이션에게 전달
4. Access Token을 확인하고, 요청받은 Resource를 Client에게 전달

 

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

- ** Client 애플리케이션이 관리하는 Resource나 Authorization Server에 제한된 Resource 접근 권한이 설정되어 있는 경우 사용 가능한 방식

- Refresh Token의 사용 불가, ** 자격 증명을 안전하게 보관할 수 있는 Client 애플리케이션에서만 사용되어야 함

 

Client Credentials Grant 방식의 인증 처리 흐름 (Microsoft 인증 플랫폼을 이용)

 

 

- Ref)

- https://docs.oracle.com/cd/E50612_01/doc.11122/oauth_guide/content/oauth_intro.html

- https://www.rfc-editor.org/rfc/rfc6749

- https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow