OAuth에 대한 설명 은 개발자 면접에서 자주 나오는 질문 중의 하나!

1. Oauth

1) 오해

SNS 로그인 = OAuth ( X )
Session / Cookie 방식, 토큰 기반 인증 방식(JWT) 을 완전히 대체 ( X )

OAuth 프로토콜의 기능 中 SNS 로그인이 있음 ( O )
SNS 로그인 기능을 넣더라도, Session / Cookie 방식 또는 토큰 기반 인증 방식(JWT)을 활용해 인증 ( O )

2) 정의

• 외부서비스의 인증 및 권한부여를 관리하는 범용적인 프로토콜
  - 외부서비스 : 우리가 만드는 서비스 --> 외부 서비스를 위한 서비스인 OAuth는 서비스의 인증 및 권한부여 관리를 대행함
  - 권한 : 인증 + 권한 관리 --> 사용자의 권한에 따라 접근할 수 있는 데이터가 다르게 설정 가능
  - 프로토콜 : 일종의 '규격'(특정한 프로그램을 지칭 X) --> Facebook, Google, Naver 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행관리함

• Oauth 도 Access Token + Refresh Token 방식으로 진행됨

3) 예시

사용처: 페이스북, 네이버 로그인 등...

교보문고에 로그인을 할 때
교보문고에서 별도의 회원가입을 하지 않고도, 네이버나 카카오톡의 아이디로 로그인이 가능하다.

2. OAuth 2.0 의 인증 방식

1. Authorization Code Grant --> 가장 多 사용

2. Implicit Grant

3. Resource Owner Password Credentials Grant

4. Client Credentials Grant

1) OAuth 2.0 & SNS 로그인 의 동작순서

Authorization Code Grant 방식

순서 5. 에서
초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 얻게되는 자원이 달라진다.
(프로필 이미지, 이메일 주소, 이름 등... 을 얻을 수도 있음)

순서 6. 에서
(예를 들면 페이스북의 경우)
Resource Server 를 사용하지 않는다. 즉, Access Token을 인증수단으로 사용하지 않는다.
대신, Authorization Server로 부터 얻는 고유 id값을 활용해서 DB에 회원관리를 진행한다.

(1) 구성

• Resource Owner : User, 즉 일반 사용자를 칭한다.

• Client : 우리가 관리하는 어플리케이션 서버 (주의! User가 아니다.)

• Authorization Server
  - 권한을 관리하는 서버
  - Access Token, Refresh Token을 (재)발급 해주는 역할

• Resource Server
  - OAuth2.0을 관리하는 서버(Google, Facebook, Naver 등...) 의 자원을 관리하는 서버
  - 주의!
  우리가 만드는 서버의 자원을 관리하는 곳 ( X )
  Oauth 2.0 관리 서버의 자체 API를 의미 (Oauth를 관리하는 서버의 일부) ( O )

=> Authorization Server + Resource Server 를 묶어서, OAuth 2.0

2) SNS 로그인

(1) 정의

• SNS 로그인을 제공하는 Google, Facebook, Naver 등... 은 모두 OAuth2.0 프레임워크를 통해 로그인 API를 제공
• 간단히, OAuth2.0 + 서버 인증(세션/쿠키, 토큰기반 인증)으로 구성

(2) 장점

• 번거로운 회원가입 절차 생략 가능

  • 빠른 회원가입이 가능해짐

• 사용자가 미리 권한을 확인하고, 허락한 정보에 한해서 접근이 가능

  • 결론적으로, 이 정보들에 한해서는 쉽게 접근이 가능해진다.

3. Access Token + Refresh Token VS OAuth 2.0

• Access Token, Refresh Token 인증 방식 : 한 서버에서 모두 관리
• OAuth : Authorization Server에서 인증 + 권한 관리를, Resource Server에서는 자원 관리만 함