OAuth 2.0
인증을 위한 개방형 표준 프로토콜
사용자가 가입된 서비스(카카오, 구글 등)에서 제공하는 API를 통해 간편 로그인 기능을 제공받을 수 있다.
왜 API는 비밀번호만으로 인증하는 방법을 사용하지 않는가?
- 사용자는 애플리케이션에 비밀번호를 제공하기 싫어하며,
- 비밀 번호를 넘길 경우 보안 문제가 발생할 수 있고,
- 사용자가 비밀번호를 변경할 시에 접근이 제한된다.
OAuth 2.0 용어
- Resource Owner
: 서비스 이용자, 리소스 소유자, 사용자
- Client(어플리케이션)
: 리소스 소유자를 대신해 보호된 리소스에 접근하는 응용 프로그램, 개발 사이트
- Resource Server
: 클라이언트의 요청을 수락하고 응답할 수 있는 서버(카카오, 네이버 등)
- Authorization Server
: 리소스 소유자를 성공적으로 인증한 후 엑세스 토큰을 발급하는 서버(카카오, 네이버 등의 인증 서버)
- Access Token
: 자원 서버에 자원을 요청할 수 있는 토큰
- Refresh Token
: 권한 서버에 접근 토큰을 요청할 수 있는 토큰
인증 절차 종류 4가지
- Authorization Code Grant
: Client가 사용자 대신 리소스에 접근을 요청할 때 사용
: 보안성이 높아서 자주 사용된다.
- Implicit Grant
: 엑세스 토큰을 즉시 반환받아 인증에 이용하는 방식
- Client Credentials Grant
: Client가 컨텍스트 외부에서 엑세스 토큰을 얻어 리소스에 접근을 요청할 때 사용하는 방식
- Resource Owner Password Credentials Grant
: Client가 암호를 사용해 액세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
Authorization Code Grant
- 가장 널리 사용되는 방법.
- 클라이언트 = 서드파티 서비스의 백엔드 서버
- 사용자 인증 후 Callback을 통해 authorization code를 받고, 이를 client-id, client-secret과 함께 Access-Token으로 교환함.
- Callback 처리는 백엔드 서버에서 이루어지므로, Access-Token이 노출되지 않아 보안성이 높다.
Implicit Grant
- Access-Token이 URL에 노출되기 때문에 보안 리스크가 존재
- 백엔드 서버가 없는 제한적 상황에서만 권장
Client Credentials Grant
- Client_id, Client_secret 파라미터를 통해 Access-Token을 발급, 사용자는 이 과정에서 배제
- 백그라운드에서 이뤄지는 서버 간 상호 작용에 적용
Resource Owner Password Credentials Grant
- 일반 로그인 아이디비밀번호 인증
- 클라이언트를 완전히 신뢰할 수 있을 때 사용을 권장