OAuth 2.0 개요 ( 권한부여승인코드 방식 )

OAuth( Open Authorization ) :
。신용도 있는 업체 ( Google 등 )이 인증 서비스를 제공함으로써 인증에 관한 책임을 위임받아 대신 수행하는 기능
▶ 고객이 인증 요청 시 백엔드는 해당 인증 여부를 Authorization Server에 검증을 위임.

。인증에 관한 책임은 모두 Google이 지며, 백엔드 개발자는 인증서비스를 사용하는 클라이언트가 된다.

。사용자의 자격증명을 특정 어플리케이션 서버에 직접 제공하지 않아도, 서버의 자원( 사용자 개인 정보 )에 안전하게 접근 가능
▶ 사용자가 자신의 계정정보를 노출하지 않고도 다른 서비스와 안전하게 연동

。타 인증 서비스에 개인정보 취급을 위임함으로서 어플리케이션 서버에서는 인가작업 및 개인정보를 관리하지 않아도 되는 장점이 존재.

• Resource Server에서 사용자 정보는 보수적으로 최소한으로 가져오는게 좋다.
  。 개인정보( 생일 / 연령대 / 출생연도 / 휴대전화 등 )의 경우 DB에 저장 중, 노출되는 경우 책임을 개발자가 지므로.
  
  
• 보통 OAuth2.0은 로그인 인증만 수행하며, 로그인 상태 유지는 Session / JWT Token 등을 선택해서 유지
  。 구글 인증서비스를 통해 로그인만 수행하고, 로그인 해서 개인정보만 받아오면 구글에서 발급받은 Access Token을 바로 폐기
  ▶ 다른 구글서비스를 사용할 필요가 없으므로, Access Token을 refresh할 필요가 없다.
  
  。이후 로그인 상태 유지는 백엔드 서버에서 따로 Access Token과 Refresh Token을 구현해서 로그인 상태를 유지
  
  
• OAuth 2.0으로 클라이언트에서 로그인 시 클라이언트 쪽에서 로그아웃은 불가능.
  。이미 OAuth Provider에서 발급된 Access Token에 의해 로그인 상태가 유지되므로.
  
  。localhost:8080/logout 호출해도 안되는 이유는 Spring Security에서 로그아웃되는거지 OAuth Provider에서 로그아웃하는건 아니기 때문.

OAuth 로그인 서비스 구현 시 주의사항

• 회원의 사용자정보를 추가로 요청하기 위해서는 사업자 등록 또는 추가 정보 입력 페이지를 추가 구현
  。추가정보 입력페이지를 사용 시 OAuth 로그인이 완료 시 표시되도록 설정
  ▶ 추가정보 입력 완료까지 로그인 과정을 끝내지 않고, 추가 계속 리디렉션을 수행
  
  
• 중복 회원을 방지하기 위해 식별자를 email로서 활용
  。OAuth 2.0 구현 시 보통 이메일을 식별용 아이디로서 데이터의 유일한 식별자 역할을 수행
  
  。동일한 이메일이 존재하는 경우 다른 Provider의 이메일인지 확인하는 로직을 작성
  ex) naver의 wjdtn747@naver.com이 등록된 상태에서 google의 wjdtn747@naver.com로 로그인 시 차단
  
  。 카카오는 사업자로 등록되지 않으면 이메일 계정을 요청할 수 없으므로 서브ID로서 ID + @kakao.com을 설정하여 유일하게 식별하도록 설정

@Column(unique = true, nullable = false)
private String email;
  //
private String provider;

▶ Entity 설계 시 OAuth Provider 정보와 함께 다음처럼 설정

OAuth 2.0 구성요소

• Resource Owner :
  。사용자로서 자원 ( 개인정보 )의 주인
  ▶ API를 통해 보호된 Resource를 소유한 주체.
  ex) Google Drive의 파일을 소유하고 있는 클라이언트
  
  
• Client :
  。Resource Owner 대신 API를 호출하는 백엔드 어플리케이션
  
  ex) Google Drive 파일에 접근하고자 하는 Spring Application
  ex) Google 로그인 서비스를 이용하는 웹사이트
  
  
• Authorization Server :
  。클라이언트의 인증을 담당 및 인증된 클라이언트에 대해 Access Token을 발급하는 서버
  ex) Google OAuth Server
  
  
• Resource Server :
  。OAuth2.0 Authentication을 기반으로 Authenticated된 사용자에 대해서만 접근할 수 있도록 보호된 API를 제공하는 개인정보를 보관하는 자원서버
  ▶ 자원을 저장하는 역할을 수행
  
  。인증된 Access Token을 포함한 HTTP Request만 허용하는 서버
  ▶ Access Token을 검증하여 HTTP Request를 허용 또는 거부.
  ex) 접근하려는 Google Drive 파일을 보관하는 Server( = Google Drive )

권한부여승인코드
。Client Application이 Resource Owner에 대한 정보를 획득하기 위해 Resource Server로부터 모든 자원 ( = 개인정보 ) 중 동의한 내용의 개인정보에 접근할 수 있는 권한을 포함하는 Access Token을 요청하는 코드

권한부여승인코드를 활용한 OAuth 2.0 로그인 과정

。Spring Security는 1번 ~ 8번까지 YML 파일을 정의하여 자동으로 수행
▶ 8번 ~ 9번 구간에서 백엔드 개발자가 요청한 자원( = 개인정보 )을 활용해서 요청 처리


1. 사용자 ( = Resource Owner )에서 백엔드 서버로 인증 요청


2. 백엔드 서버( = Client )에서 구글인증서버로 권한부여 승인코드 요청
。 사용자 개인정보( = Resource )를 요구하는 권한부여승인코드를 전송

。이후 구글 인증 서버 ( = Authorization Server )는 사용자에게 로그인 페이지를 출력


3. 사용자는 구글 로그인 페이지를 통해 인증을 수행


4. 인증이 완료된 경우, 구글 인증 서버에서 백엔드 서버로 권한부여승인코드를 응답


5, 6. 백엔드 서버는 권한부여승인코드를 기반으로 구글인증서버로 Access Token을 요청 및 응답


7, 8. 백엔드 서버는 구글 자원 서버로 해당 Access Token에 정의된 접근 권한에 해당하는 자원( 개인정보 )을 Access Token을 요청에 포함하여 전송 및 응답
。구글 인증 서버는 해당 Access Token을 검증 후 이상이 없는 경우 구글 자원 서버로 접근을 허용

。백엔드 서버는 전달받은 자원을 내부 어플리케이션에서 활용


9. 인증이 끝난 이후 로그인 상태를 유지
。 구글 인증서비스를 통해 로그인만 수행하므로, 로그인 해서 개인정보만 받아오면, 구글에서 발급받은 Access Token을 바로 폐기
▶ 다른 구글서비스를 사용할 필요가 없으므로, Access Token을 refresh할 필요가 없다.

。이후 로그인 상태 유지는 백엔드 서버에서 따로 Access Token과 Refresh Token을 구현해서 로그인 상태를 유지
▶ 로그인은 OAuth, 로그인 상태 유지는 우리의 백엔드 서버에서 수행