OAuth와 OpenID Connect : OAuth 워크플로우

- OAuth 워크플로우의 동작 과정

- Authorization Code 플로우와 Implicit 플로우의 차이

- 각 플로우가 가지는 보안적 특성과 장단점 비교

- 실무에서 어떤 상황에 어떤 플로우를 적용해야 하는가

- 워크플로우를 통해 OAuth 인증 과정 이해

---

OAuth 워크플로우

사용자가 신뢰할 수 있는 제3자 서비스(Authorization Server)를 통해 인증을 진행하고,

애플리케이션(Client)이 Access Token을 받아 Resource Server에 접근하는 과정을 말함

 

OAuth 워크플로우는 보통 이런 형태로 이루어진다. Resource Owner는 이용 요청과 로그인 동의만 하면됨

 

 

---

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

• Authorization Grant
  • Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜(Credential)
  • Client가 Access Token을 얻기 위한 수단임
  • 네가지 유형이 존재함
    • Authorization Code
    • Implicit
    • Client Credentials
    • Resource Owner Password Credentials
• Access Token
  • Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위해 사용하는 자격 증명용 토큰
  • Authorization Code와 Client Secret을 이용해서 Authorization Server로부터 전달받는다
• Scope
  • Access Token으로 접근 가능한 Resource의 범위를 정의함
  • 최소 권한 원칙을 적용하기 위해 사용됨

 

 

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

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식

가장 많이 쓰이고 기본이 되는 방식임

Authorization Code Grant 방식에서는 Refresh Token을 사용할 수 있다

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

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 Server에게 Resource를 요청한다
8. Access Token을 확인한 후 요청받은 Resource를 Client에게 전달한다

 

 

 

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

별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식

이는 자격 증명을 안전하게 저장하기 힘든 Client(스크립트 언어를 사용하는 브라우저, 자바스크립트 등)에게 최적화된 방식임

Refresh Token 사용이 불가능하며, 이 방식에서 Authorization Server는 Client Secret을 통해 클라이언트 인증 과정을 생략한다

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

 

Implicit Grant 인증 처리 흐름, Authorization Code가 생략된다

 

1. Resource Owner는 소셜 로그인 버튼을 누르는 등 서비스 요청을 Client(앱)에게 전송함 (로그인에 필요한 정보를 통해 X)
2. Client는 Authorization Server에게 접근 권한 요청을 함.
   요청과 함께 미리 생성한 Client ID, Redirecct URI, 응답 타입을 전송한다(Authorization Code를 획득하기 위한 요청 X)
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행함
4. 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달한다
5. Client는 Access Token을 이용해 Resource Server에게 Resource를 요청함
6. Access Token을 확인한 후 요청받은 Resource를 전달한다

 

 

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

간단하게 로그인시 필요한 정보(username, password)로 Access Token을 발급받는 방식

자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식

Refresh Token의 사용이 가능하다

 

가령, 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인 하거나, 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우가 이 Resource Owner Password Credential Grant에 해당한다

 

Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해있을 때만 사용 가능함

Resource Owner Password Credential Grant 인증 처리 흐름

 

1. Resource Owner는 로그인 버튼을 누르는 등 서비스 요청을 Client에게 전송함.
   이 때 로그인에 필요한 정보(username, password)를 이용해 요청한다
2. Client에서는 Resource Owner에게서 전달받은 로그인 정보를 통해 Authorization Server에 Access Token을 요청함.
   미리 생성한 Client ID, 권한 부여 방식, 로그인 정보를 함께 전달한다
3. 요청과 함께 온 정보들을 확인 후 Client에게 Access Token을 전달함
4. Client는 Access Token을 이용하여 Resource Server에게 Resource를 요청함
5. Access Token을 확인한 후 요청받은 Resource를 전달함

 

 

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

Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용할 수 있는 방식임

이 방식은 자격 증명을 안전하게 보관할 수 있는 Client에게만 사용되어야 하며, Refresh Token의 사용은 불가능하다

Client Credentials Grant 방식 인증 처리 흐름

 

---

보안 특성 비교

플로우	보안성	특징	사례
Authorization Code	높음	서버 - 서버 통신으로 토큰 교환	백엔드 서버가 있는 웹/모바일 앱
Implicit	낮음	브라우저에서 바로 토큰을 발급	과거 SPA, 현재는 거의 사용 X

---

정리

항목	Authorization Code 플로우	Implicit 플로우
토큰 전달 방식	Authorization Code 교환 후 전달함	Access Token 직접 전달함
보안 수준	높음	낮음
적합한 환경	서버 - 서버가 통신 가능한 앱	브라우저 기반 앱
현재 권장 여부	권장(PKCE와 함께 사용함)	비추천