OAuth2.0 플로우
OAuth2.0 이해하기
사용자가 가입된 서비스(구글, 페이스북, 카카오, 네이버 등)에서 제공하는 API를 이용하여 사용자 데이터에 접근하기 위해서는 사용자로부터 권한을 위임 받아야 한다. 이 때 사용자의 패스워드 없이도 권한을 위임 받을 수 있는 방법이 필요한데, OAuth2.0(Open Authorization, Open Authentication 2) 라는 표준 인증 프로토콜을 통해 처리한다.
- 왜 API는 비밀번호만으로 인증하는 방법을 사용하지 않는가?
- 신뢰 — 사용자는 애플리케이션에 비밀번호를 제공하기 꺼려함
- 불필요하게 넓은 접근 범위 — 사용자가 애플리케이션에 비밀번호를 제공하면 애플리케이션에 필요한 데이터 뿐만 아니라 사용자 계정 안에 있는 모든 데이터에 접근할 수 있음
- 사용성 — 사용자가 비밀번호를 바꾸면 애플리케이션은 더는 해당 데이터에 접근하지 못함
- OAuth 주요 용어 4가지
- Resource Owner — 서비스를 이용하는 사용자이자, 리소스 소유자
- Client (어플리케이션) — 리소스 소유자를 대신하여 보호된 리소스에 액세스하는 응용 프로그램
- Resource Server — 보호받는 리소스를 호스팅하고 액세스 토큰을 사용하는 클라이언트의 요청을 수락하고 응답할 수 있는 서버 (카카오, 네이버 등의 리소스 서버)
- Authorization Server — 클라이언트 및 리소스 소유자를 성공적으로 인증한 후 액세스 토큰을 발급하는 서버 (카카오, 네이버 등의 인증 서버)
OAuth2.0에서 Client는 Authorization server에게 4가지 방법으로 토큰 발생을 요청할 수 있다.
Authorization Code Grant
- OAuth2.0에서 가장 중요하고, 널리 사용되는 인증 방법 — 이 방법에서 클라이언트는 써드파티 서비스의 백엔드 서버가 됨
- 백엔드 서버가 존재하는 웹/모바일 서비스에 적합함
- 사용자 인증 후 Callback을 통해 authorization code를 받고, 이를 client-id, client-secret과 함께 Access-Token으로 교환함
- Callback 처리는 백엔드 서버에서 이루어지기 때문에, Access-Token이 외부에 노출되지 않음 (보안상 안전)
- 4단계 처리 Flow
- Authorization Request — 클라이언트는 사용자를 Authorization Server로 리다이렉션
- response_type — code 고정
- client_id — Authorization Server에서 클라이언트를 식별하기 위한 식별키
- redirect_uri — Authorization Server에서 처리 완료 후 리다이렉션 하기 위한 URL
- scope — 클라이언트가 요구하는 리소스를 정의
- state — 클라이언트는 임의의 문자열을 생성하여 CSRF 공격을 방지함
- Authorization Response — 클라이언트에서 요구하는 리소스에 대해 사용자 동의를 받고, 요청과 함께 전달된 redirect_uri로 리다이렉션
- code — Access-Token 교환을 위한 승인 코드
- state — 요청과 함께 전달 된 임의의 문자열
- Token Request — 승인 코드를 Access-Token으로 교환
- grant_type — authorization_code 고정
- code — 앞 단계에서 전달 받은 코드
- client_id — Authorization Server에서 클라이언트를 식별하기 위한 식별키
- client_secret — 클라이언트 비밀키
- Token Response — Access-Token 및 부가정보 획득
- access_token — 리소스 요청에 필요한 토큰 (보통 짧은 생명주기를 지니고 있음)
- refresh_token — Access-Token을 갱신하기 위한 토큰
Implicit Grant
- Authorization Code Grant 방식과 비교했을 때, Authorization Response 단계에서 Access-Token이 전달되고 Token Request 단계가 생략됨
- Access-Token이 URL에 노출되기 때문에 보안상 리스크가 있음
- 백엔드 서버가 없는 제한적인 환경에서만 사용을 권장함
- 브라우저에서 자바스크립트와 같은 스크립트 언어로 동작하는 클라이언트
Client Credentials Grant
- client_id, client_secret 파리미터만 가지고 Access-Token을 발급할 수 있으며, 사용자는 전혀 관여하지 않음
- 사용자의 직접적인 상호 작용 없이 백그라운드에서 실행해야 하는 서버 간 상호 작용에 사용
Resource Owner Password Credentials Grant
- Client Credentials Grant 방식과 매유 유사하지만, client_id, client_secret 대신 사용자 비밀번호로 인증됨
- 즉, 일반 로그인 아이디/비밀번호 인증
- 클라이언트를 완전히 신뢰할 수 있을 때 사용
