OAuth : 워크플로우

오뜨를 까보자

 

 - OAuth 워크플로우의 전반적인 동작 과정

 - Authorization Code 플로우?? 와 Implicit?? 플로우의 차이 알기

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

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

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

 

---

 

OAuth 워크플로우

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

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

Resource Owner - Client - Authorization Server - Resource Server 얘네가 어떻게 주고받는가?

OAuth 워크플로우

 

Resource Owner가 Client에게 서비스 이용 요청 - > Client가 Authorization Server에 인증 요청(리다이렉트)

- > Client가 리다이렉트 시켜준 곳에서 Resource Owner가 로그인 및 동의

- > Authorization Server가 Client에게 Access Token 전달 - > Client가 Resource Server에 Access Token으로 자원 요청

- > Resource Server가 Client에게 요청한 자원을 반환해줌

 

---

 

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 인증 처리 흐름

 

 - Resource Owner는 소셜 로그인 버튼을 누르는 등 서비스 요청을 Client에게 전송함

 - Client는 Authorization Server에 Authorization Code를 요청함. 이 때 미리 생성한 Client ID, Redirect URI, 응답 타입 전송

 - Resource Owner는 리다이렉트한 로그인 페이지를 통해서 로그인을 진행함

 - 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에게 전달함

(이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달함)

 - Client는 전달받은 Authorization Code를 이용해서 Access Token 발급을 요청함.

Access Token을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorization Code를 함께 전송함

 - 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급함

 - Client는 발급받은 Access Token을 이용해서 Resource Server에 Resource를 요청함

 - Access Token을 확인한 후 요청받은 Resource를 Client에게 전달함

 

 

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

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

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

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

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

Implicit Grant 방식 인증 처리 흐름

 

 - Resource Owner가 소셜 로그인 버튼을 누르는 등 서비스 요청을 Client에게 전송함

 - Client가 Authorization Server에게 접근 권한 요청을 함

요청과 함께 미리 생성한 Client ID, Redirect URI, 응답 타입을 전송함

* Authorization Code를 획득하기 위한 요청이 아니다!

 - Resource Owner는 로그인 페이지를 통해 로그인을 진행함

 - 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달함

 - Client는 Access Token을 이용해서 Resource Server에게 Resource를 요청함

 - Access Token을 확인한 후 요청받은 Resource를 Client에게 전달함

 

 

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

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

자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로, Refresh Token의 사용도 가능

 - 가령 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인, 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우

Resource Owner Password Credential Grant에 해당함

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

Resource Owner Password Credential Grant 방식 인증 처리 흐름

 

 - Resource Owner는 로그인 버튼을 누르는 등 서비스 요청을 Client에게 전송함

이 때 로그인에 필요한 정보(username, password)를 이용해서 요청함

 - Client에선 Resource Owner에게서 받은 로그인 정보를 통해 Authorization Server에 Access Token을 요청함

미리 생성한 Client ID, 권한 부여 방식, 로그인 정보를 함께 전달함

 - 요청과 함께 온 정보들을 확인하고 Client에게 Access Token 전달

 - Client는 Access Token을 이용해서 Resource Server에게 Resource를 요청함

 - Resource Server는 Access Token을 확인하고 요청받은 Resource를 Client에게 전달함

 

 

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

Client 자신이 관리하는 Resource 혹은 Authorization Server에

해당 Client를 위한 제한된 Resource 접근 권한이 설정된 경우, 사용할 수 있는 방식

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

 

Client Credentials Grant, 클라이언트 자격 증명 승인 방식 워크플로우

 

Client가 Authorization Server에게 엑세스 토큰 요청 - > 인증, 인가 후 Authorization Server가 Client에게 엑세스 토큰 전달

- > Client가 Resource Server에게 자원 요청 - > Resource Server가 Client로부터 받은 엑세스토큰을 보고 자원 전달

 

* Client Credentials Grant에서는 Resource Owner가 개입하지 않는다

 

보안 특성 비교

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

 

 

정 - 리

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

 

* PKCE(Proof Key for Code Exchange)

Authorization Code flow에 대한 확장 기능으로 원래 모바일 앱에서 인증 코드 플로우를 보호하기 위해 설계되었는데,

단일 페이지 앱에서도 사용되는게 권장됨

 

출처 : https://blog.logto.io/ko/how-pkce-protects-the-authorization-code-flow-for-native-apps