OAuth2.0 이란?

(1) OAuth2.0이란?

(2) Spring Security와 OAuth 2.0으로 로그인 구현하기(SpringBoot + React)

(3) Spring Security OAuth 2.0 단위테스트

(4) Spring Security가 OAuth 로그인을 처리하는 방법

알고 있으면 이해하는데 도움이 되는 개념들

- 인증과 인가

- Access Token

OAuth 2.0 이란?

OAuth란 Open Authorization의 약자로 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜입니다.

 

제3의 앱(내가 만든 애플리케이션)이 자원의 소유자인 서비스 이용자를 대신하여 서비스(구글, 네이버, 카카오 등)를 요청할 수 있도록 자원 접근 권한을 위임하는 방법입니다.

 

즉, 어떤 서비스를 이용할 때 페이스북이나 구글 아이디로 회원가입이 가능한 것을 떠올리면 됩니다.

 

사용자에게 인증을 제공하지만 주된 목적으로는 인증된 사용자의 이름이나 이메일을 가져오는 등의 권한을 제공해줍니다.

 

OAuth의 등장 배경

제3의 앱에서 네이버의 서비스를 사용하고 싶다면 어떻게 해야 할까요?

가장 간단한 방법은 고객에게 네이버 아이디/비밀번호를 받아서 로그인하면 됩니다.

 

하지만 이 방법은 세 가지 문제점이 존재합니다.

1. 네이버가 내가 만든 애플리케이션을 신뢰하지 못한다. 

2. 내가 만든 애플리케이션에서 네이버의 정보를 관리하는 게 부담스럽다. (보안적으로 신경 쓸 포인트가 증가한다)

3. 사용자는 내가 만든 애플리케이션을 신뢰할 수 없다. (무엇을 믿고 나의 네이버 아이디와 비밀번호를 알려줄까?)

 

따라서 다른 서비스의 자원(로그인, 프로필 조회, 카페, 캘린더, 배송지 정보 등)을 안전하게 사용하기 위해서 등장하게 되었습니다.

 

어떻게 OAuth가 다른 서비스의 회원 정보를 안전하게 사용할 수 있는지에 대해서는 밑에서 동작 과정을 보면서 알아보겠습니다.

 

OAuth 2.0와 OAuth 1.0의 차이점

OAuth 옆에 버전이 붙어있는 것으로 보아 1.0 버전 2.0 버전이 존재함을 알 수 있습니다.

둘의 차이점은 다음과 같습니다.

https://velog.io/@devsh/OAuth-2.0-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

간단하게 요약하자면 다음과 같습니다.

• 반드시 HTTPS 사용
• 웹이 아닌 애플리케이션도 지원
• 역할 명칭 변경
• 서비스제공자 -> 자원, 권한 서버로 분리

 

시작 전 용어 정리

사용자 : Resource Owner
ex) 일반 사용자

클라이언트 : Client
ex) 구글, 페이스북 아이디로 로그인이 가능한 서비스. 제 3의 서비스(내가 만든 애플리케이션)

API 서버 : Resource Server
ex) 이름, 나이 등 아이디 관련 정보를 제공하는 서버. 구글, 페이스북 등.

권한 부여 서버 : Authorization Server
ex) 로그인을 통해 인증 후 권한을 부여하는 서버. 구글, 페이스북 등.

인증 서버 : Authentication Server
ex) 실제로 로그인 서비스를 제공하는 서버. 구글, 페이스북 등

 

Authorization Code Grant 방식을 통한 인증 과정

OAuth 2.0은 총 4가지 인증 방법을 가지고 있습니다.

그중 비교적 안전한 Authorization code grant 방식의 인증 방법을 소개하겠습니다.

https://meetup.toast.com/posts/105

핵심 로직은 다음과 같습니다

1. 제3의 서비스는 사용자로부터 Authorization code를 받습니다.

2. 제3의 서비스는 Authorization Server(네이버의 인증 서버)에게 Authorization code로 Access Token을 발급받습니다.

3. 제 3의 서비스는 Access Token으로  Resource Server(네이버의 자원 서버)에게 자원을 요청합니다.

4. 사용자에게 제공합니다.

Authorization Code Grant 방식이 안전한 이유

Client Application에게 access token을 넘겨주는 방식이 아니라 Authorization Code를 넘겨줍니다.

그리고 백엔드에게 Authorization Code를 넘겨주고 허가된 리소스 요청을 받습니다.

즉, Access 토큰을 백엔드에서 관리하기 때문에 탈취당할 위험이 사라집니다.

 

예를들어 Implicit 방식이 존재하는데 이는 Access Token을 Front-end에서 관리하기 때문에 보안적 위험성이 더 커집니다.

 

 

프런트엔드의 역할

- OAuth 서버로 로그인 요청 후, Authorization code를 발급받아 백엔드에 전달

 

백엔드의 역할

- Authorization code로 OAuth 서버에 Access Token 요청

- Access Token으로 이름, 이메일 등의 정보 요청

- DB에 존재하지 않는 유저라면 새로 등록, DB에 존재하는 유저라면 정보 업데이트

- 이후 프런트엔드에게 Access Token과 Refresh Token을 반환한다.

 

더 나아가서

OAuth의 다양한 인증 방식들과 OAuth2.1, GNAP* 등에도 관심이 있다면 다음영상을 추천드립니다.

https://www.youtube.com/watch?v=DQFv0AxTEgM&t=1692s 

 

 

참고자료

https://meetup.toast.com/posts/105

OAuth 2.0 대표 취약점과 보안 고려 사항 알아보기 : NHN Cloud Meetup

 

http://daplus.net/oauth-oauth-2%EB%8A%94-oauth-1%EA%B3%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8B%A4%EB%A6%85%EB%8B%88-%EA%B9%8C/

[oauth] OAuth 2는 OAuth 1과 어떻게 다릅니 까? - 리뷰나라

https://velog.io/@devsh/OAuth-2.0-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

OAuth 2.0 에 대하여

https://velog.io/@undefcat/OAuth-2.0-%EA%B0%84%EB%8B%A8%EC%A0%95%EB%A6%AC

[OAuth 2.0] OAuth란?

https://blog.naver.com/mds_datasecurity/222182943542

OAuth 2.0 동작 방식의 이해