Section3 / Unit7 : [Backend]OAuth

OAuth

인증을 중개해 주는 메커니즘

보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜

→ 이미 사용자 정보를 가지고 있는 웹 서비스에서 사용자의 인증을 대신해 주고,

→ 접근 권한에 대한 토큰을 발급한 후,

→ 이를 이용해 내 서버에서 인증이 가능해짐

 

OAuth는 언제, 왜 쓸까?

예전에는 특정 웹 앱의 서비스를 이용하기 위해선 해당 웹 앱에 회원가입을 하는 것이 우선이었다.

하지만 소셜 로그인(네이버, 카카오 등)이 보편화된 현재,

대부분의 사람들이 이미 가입된 계정을 이용해 빠르게 서비스에 가입하는 것을 택하고 있다.

 

뿐만 아니라 서비스를 구현하는 개발자도 신규 회원가입이나 회원 관리를 신경 쓰지 않아도 되기 때문에
사용자와 기업 모두 소셜 로그인을 선호하고 있는 추세다.

 

OAuth를 활용하면 자주 사용하고 중요한 서비스들의 ID와 비밀번호만 기억해 놓고

해당 서비스들을 통해 외부 서비스로 소셜 로그인을 할 수 있다.

 

OAuth의 보안상 이점

→ 검증되지 않은 App에서 OAuth를 사용하여 로그인한다면,

→ 유저의 민감한 정보가 직접 App에 노출될 일이 없고

→ 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다.

 

 

OAuth의 주체

• 사용자(Resource Owner)
• 새로운 서비스(Application → Client, Server)
• 사용중인 서비스(Resource Server, Authorization Server)

OAuth 작동 메커니즘

• Resource Owner
  • OAuth 인증을 통해 소셜 로그인을 하고 싶어 하는 사용자
  • Resource는 사용자의 이름, 전화번호 등의 정보
    이러한 정보의 주인이 바로 사용자이기 때문에 Resource Owner라고 한다
• Resource Server & Authorization Server
  • Resource Server
    사용자가 소셜 로그인을 하기 위해서는 사용하는, 이미 사용 중인 서비스의 서버 중
    사용자의 정보를 저장하고 있는 서버
  • Authorization Server
    이미 사용 중인 서비스의 서버 중 인증을 담당하는 서버
• Application
  • 사용자가 소셜 로그인을 활용해 이용하고자 하는 새로운 서비스
  • 경우에 따라 Application을 Client와 Server로 세분화해서 지칭

OAuth 인증 방식의 종류와 흐름

Implicit Grant Type

1. 사용자가 Application에 접속
2. Application에서 Authorization Server로 인증 요청을 보냄
3. Authorization Server는 유효한 인증 요청인지 확인한 후 액세스 토큰을 발급
4. Authorization Server에서 Application으로 액세스 토큰을 전달
5. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청
6. Resource Server는 Application에게서 전달받은 액세스 토큰이 유효한 토큰인지 확인
7. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달

Implicit Grant Type은 기존 서비스에 로그인만 되어있다면 새로운 서비스에 바로 액세스 토큰을 내어주기 때문에

보안성이 떨어진다

 

Authorization Code Grant Type

1. 사용자가 Application에 접속
2. Application에서 Authorization Server로 인증 요청을 보냄
3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급
4. Authorization Server에서 Application으로 Authorization Code를 전달
5. Application이 Authorization Code로 발급받은 Authorization Code를 전달
6. Authorizaiton Server는 유효한 Authorization Code인지 확인한 후 액세스 토큰을 발급
7. Authorization Server에서 Application으로 액세스 토큰을 전달
8. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청
9. Resource Server는 Application에게서 전달받은 액세스 토큰이 유효한 토큰인지 확인
10. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달

Authorization Code를 사용한 인증 단계가 추가로 있기 때문에 비교적 더 안전

 

Refresh Token Grant Type

Authorization Server로 리프레시 토큰을 보내주면,

Authorization Server는 리프레시 토큰을 검증한 다음 액세스 토큰을 다시 발급

Application은 다시 발급받은 액세스 토큰을 사용해서 Resource Server에서 사용자의 정보를 받아오게 된다

 

OAuth의 장점

1. 쉽고 안전하게 새로운 서비스를 이용할 수 있다.
   • 사용자는 OAuth를 통해 특정 사이트에 아이디, 비밀번호, 이름, 전화번호 등의 정보를 일일이 입력하지 않아도
     클릭 몇 번 만으로 손쉽게 가입할 수 있어 편리
   • 정보를 해당 서비스에 직접 노출하는 것이 아니기 때문에 직접 가입하는 것보다 더 안전
   • Application의 입장에서도 회원의 정보를 직접 가지고 있음으로 인해서 발생할 수 있는 회원 정보 유출의 위험성에서 부담을 덜 수 있음
2. 권한 영역을 설정할 수 있다.
   • OAuth 인증을 허가한다고 해서 새로운 서비스가 사용 중이던 서비스의 모든 정보에 접근이 가능한 것은 아님
     사용자는 원하는 정보에만 접근을 허락할 수 있어 보다 더 안전
   • OAuth 설정 페이지에서는 Application에서 필요한 정보를 선택할 수 있음.
     사용자는 이 중 원하는 정보만 선택적으로 제공 가능