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

• 일반 로그인 아이디비밀번호 인증
• 클라이언트를 완전히 신뢰할 수 있을 때 사용을 권장