인프라

생활코딩 OAuth 2.0 강의와 놀토의 OAuth

newwisdom 2021. 8. 20. 00:33
반응형

개요

나의 서비스가 사용자를 대신해 그들의 서비스의 기능에 접근한다.

  • 사용자로부터 그 사용자가 사용하고 있는 그들의 서비스에 접근할 수 있도록 허가를 받아야 함
  • 근데 사용자 입장에서는 처음 보는 서비스에게 그들의 서비스 인증정보를 맡기긴 무서움 제 삼자가 내 인증정보를 가지고 있는 것임
  • OAuth 프로토콜을 써보자!
    • 그들의 서비스가 accessToken을 발급해줌 (아이디와 비번이 아님)
    • 나의 서비스가 필수적으로 필요한 기능만 허용함
    • 우리의 서비스는 accessToken를 통해 그들의 서비스를 이용할 수 있음
    • 회원의 아디와 비번을 가지지 않아도 됨

역할

Resource Owner

  • User
  • 우리의 서비스를 이용하는 사용자
  • 우리가 제어하고자 하는 자원의 소유자
  • 나의 서비스를 이용하는 클라이언트

Client

  • Resource Server에 접속해 정보를 가져감
  • 나의 서비스

Resource Server

  • 우리가 제어하고자 하는 자원을 가진 서버
  • 데이터를 가진 서버
  • 나의 서비스가 연동하려는 그들의 서비스

Authorization Server

  • 인증과 관련되 처리를 전담하는 서버
  • 사실 Resource Server랑 퉁쳐서 말함

등록

  • 클라이언트가 Resource Server를 이용하기 위해서는 리소스 서버의 승인을 사전에 받아놓아야 함
  • 서비스마다 등록하는 방법은 다르지만 공통 요소가 있음

필요 정보

Client ID

  • 클라이언트의 식별자
  • 노출되어도 상관없음

Clinet Secret

  • 이것에 대한 비밀번호
  • 절대 노출되어서는 안됨

Authorized redirect URIs

  • 리소스 서버가 권한을 부여하는 과정에서 code를 주는데, 해당 url로 정달해달라는 명시

인증

  • 등록을 하게 되면 리소스 서버와 클라이언트는 Client ID, Client Secret는 동시에 알고 있는 상태가 됨
  • 클라이언트는 Authorized redirect URI에 대한 페이지를 구현하고 있어야 함
  • 최소한의 기능에 대해서만 인증을 받고 싶음

  • 리소스 오너는 클라이언트에 접속한다.
  • 접속을 하는 과정에서 리소스 서버를 사용해야하는 상황이 온다.
    • ex) 페이스북 글 게시 등...
  • 그러면 소셜 로그인 창으로 이동한다. 소셜 인증이 필요함
  • 리소스 오너가 리소스 서버로 접속하면 리소스 서버는 로그인 여부를 확인함
  • 로그인이 안되어 있으면 로그인 창으로 유도
  • 로그인 성공하면 리소스 오너가 보낸 클라이언트 id 값과 같은 클라이언트 id가 있는지 확인
  • 요청의 Authorized redirect URI과 리소스 서버가 가진 Authorized redirect URI이 같은지 확인
    • 다르면 작업 끝냄
  • 같으면 리소스 오너에게 어디까지 권한을 허용할건지 물어봄
  • 허용 버튼을 누르면 리소스 서버에 그 정보를 전송
    • 필수 기능에 대한 권한을 허용하였다는 정보를 처리 (SCOPE)

Resource Server의 승인

사용자가 승인 버튼을 눌렀을 때, 리소스 서버가 권한을 획득하게 된다.

이제는 리소스 서버가 승인을 해주어야 하는데, 이 때 액세스 토큰을 바로 발급하지 않는다. 
authorization이라는 임시 비밀번호를 사용한다. 
authorization를 리소스 서버가 리소스 오너에게 Location 헤더 값으로 전달한다.

그러면 리소스 오너는 모르는 사이에 저 Location으로 리다이렉트를 하게 된다.

그러면 클라이언트는 authorization를 얻게 된다.
그러면 클라이언트는 리소스 서버에 직접 접근을 하게 된다.

authorization과 client secret을 함께 전송한다.
이 때 리소스 서버는  client id에 해당하는 authorization와  secret 등 모든 정보가 일치하는지 검증한다. 

액세스 토큰 발급

리소스 서버는 authorization를 통해 인증을 했기 때문에 이를 지워도 된다. 

이후 리소스 서버는 accessToken을 클라이언트에게 발급한다. 
클라이언트는 이 accessToken을 내부적으로 저장하게 된다.

리소스 서버는 이 accessToken을 보고  userId 1번에 대한 사용자에 대해 유효한 범위 정보에 대해 허용을 해야겠다라고 생각하고 동작하게 한다.

놀토의 OAuth 흐름

참고로 레벨 3 프로젝트에서는 Spring Security 사용이 제한되어 있었다. 
때문에 Spring Security를 사용하지 않고 OAuth를 구현하기 위해 다음과 같은 흐름을 가져가게 되었다. 

  1. 프론트에서 소셜 로그인 버튼(GITHUB/GOOGLE)을 누르면 해당 소셜 타입을 path parameter에 담아 요청을 보낸다. 
  2. 백엔드에서는 소셜 타입에 해당하는 client_id, redirect_uri, scope, response_type을 DTO로 응답해준다. 
  3. 프론트에서는 해당 정보들을 query param에 담아 해당 소셜 로그인 페이지로 요청을 보낸다.
  4. 소셜은 callback url에 authorization을 의미하는 code를 담아 보낸다. 
  5. 프론트에서는 소셜이 리다이렉트 시킨 callback url에 대한 임시 방편 페이지에서 code를 추출한다.
  6. 추출한 code를 가지고 백엔드에게 회원가입 또는 로그인을 의미하는 요청을 보낸다.
  7. 백엔드는 해당 code를 가지고 소셜에 유저 정보를 요청한다. 
  8. 백엔드는 응답받은 유저 정보로 이미 존재하는 회원인지 확인한다.
  9. 존재하지 않다면 저장(회원 가입)한다.
  10. 해당 정보를 가지고 accessToken을 만들어 프론트에게 응답한다.

참고자료

생활코딩

반응형
저작자표시