React 29장 - 로그인 구현하기 (4)
포스트
취소

React 29장 - 로그인 구현하기 (4)

React

인증/보안 OAuth

image

  • 특정 웹 앱의 서비스를 이용하기 위해선 해당 웹 앱에 회원가입을 해야하는 번거로운 절차가 필요했지만, 현재는 소셜 로그인이 보편화 되었다.
  • 서비스를 구현하는 개발자도 신규 회원가입이나 회원 관리를 신경 쓰지 않아도 되기 때문에 사용자와 기업 모두 소셜 로그인을 선호하는 추세이다.
  • 검증되지 않은 App에서 OAuth를 사용하여 로그인 한다면, 인증 권한에 대해 미리 유저에게 허락을 구해야하기 때문에 보안상으로도 이점을 갖는다.

작동 매커니즘

  • Resouce Owner
    • 소셜 로그인을 하고 싶어 하는 사용자를 말한다.
    • Resouce는 사용자의 이름, 전화번호 등의 정볼르 뜻한다.
  • Resouce Server & Authorization Server
    • 사용자가 소셜 로그인을 하기 위해서 이미 사용중인 서비스 서버 중 사용자의 정보를 저장하고 있는 서버를 특정해서 Resource Server라고 부른다.
    • 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버를 Authoriztion Server라고 부른다.
  • Application
    • 사용자가 소셜 로그인을 활용해 이용하고자하는 새로운 서비스를 말한다.
    • 경우에 따라서 Client와 Server로 세분화해서 지칭하기도 한다.

OAuth 인증 방식의 종류와 흐름

  • Grant Type : Authorization Server에서 Access Token을 받아오는 방식

Implicit Grant Type

image

  1. 사용자가 Application에 접손한다.
  2. Application에서 Authorization Server로 인증 요청을 보낸다.
  3. Authorization Server는 유효한 인증 요청인지 확인한 후 액세스 토큰을 발급한다.
  4. Authorization Server에서 Application으로 액세스 토큰을 전달한다.
  5. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.
  6. Resource Server는 Application에게서 전달 받은 액세스 토큰이 유효한 토큰인지 확인한다.
  7. 유효한 토큰이라면 Application이 요청한 사용자의 정보를 전달한다.
  • 기존 서비스에 로그인만 되어있다면 새로운 서비스에 바로 액세스 토큰을 내어주기 때문에 보안성이 조금 떨어진다는 문제점을 갖고 있으며, 잘 사용하지 않는 방식이다.

Authorization Code Grant Type

image

  1. 사용자가 Application에 접속한다.
  2. Application에서 Authorization Server로 인증 요청을 보낸다.
  3. Authorization Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급한다.
  4. Authorization Server에서 Application으로 Authorization Code를 전달한다.
  5. Application이 Authorization Code으로 발급받은 Authorization Code를 전달한다.
  6. Authorization Server는 유효한 Authorization Code인지 확인한 후 액세스 토큰을 발급한다.
  7. Authorization Server에서 Application으로 액세스 토큰을 전달한다.
  8. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.
  9. Resource Server는 Application에서 전달 받은 액세스 토큰이 유효한 토큰인지 확인한다.
  10. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.
  • Implicit Grant Type과 비교해보면,Authorization Code를 사용한 인증 단계가 추가되었기 때문에 비교적 더 안전하다.
  • 또한 토큰을 Application의 Client에 노출시키지 않고 Server에서만 관리하도록 만들 수도 있기 때문에 소셜 로그인을 구현하는 방식의 선택지가 늘어나게 된다.
  • 새로운 서비스를 이용하다가 액세스 토큰이 만료되었을 때, 액세스 토큰을 다시 발급받기에는 편의성에 있어서 좋지 않다.
  • 액세스 토큰을 발급해줄 때 리프레시 토큰을 같이 발급해주는 인증 방식인 Refresh Token Grant Type이 있다.

Refresh Token Grant Type

image

  1. Authorization Server로 리프레시 토큰을 보내준다.
  2. Authorization Server는 리프레시 토큰을 검증한 다음 액세스 토큰을 다시 발급한다.
  3. Application은 다시 발급 받은 액세스 토큰을 사용해서 Resource Server에서 사용자의 정보를 받아오게 된다.

OAuth의 장점

  • 쉽고 안전하게 새로운 서비스를 이용할 수 있다.
    • 정보를 일일이 입력하지 않아도 손쉽게 가입할 수 있다.
    • 정보를 해당 서비스에 노출하는 것이 아니기에 직접 가입하는 것보다 안전하다.
    • Application 입장에서도 회원 정보를 직접 가지고 있지 않아도 되기 때문에 유출의 위험성을 줄일 수 있다.
  • 권한 영역을 설정할 수 있다.
    • 사용자가 원하는 정보에만 접근을 허락할 수 있다.
    • 설정 페이지에서 Application에 필요한 정보를 선택할 수 있다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.