[TIL] OAuth2 인증

👍🏻 OAuth2

  - 클라이언트 - 서버 - 제 3의 서비스 사이의 인증

  - 인증을 위한 표준 프로토콜의 한 종류

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

  - 즉, 이미 사용자 정보를 가지고 있는 웹 서비스 ( 카카오, 깃헙, 구글, 페이스북 등 )에서 사용자 인증을 대신해주고

     접근 권한에 대한 토큰을 발급한 후 이를 이용해서 내 서버에서 인증이 가능해짐

  - 인증만 다른 서비스에 맡기고 인가는 내 서버에서 !

      ① 편리한 인증       ② 보안상 이점

💡 Resource Owner 

  - 액세스 중인 리소스의 유저

  - 그림에서 User를 의미 ( User의 Facebook 계정을 이용해서 APP에 로그인 할 경우 User는 Resource Owner)

💡 Client 

  - Resource Owner를 대신하여 보호된 리소스에 엑세스 하는 응용 프로그램

  - 그림에서 APP을 의미 ( User가 A라는 애플리케이션을 Facebook의 소셜 로그인을 이용해 사용한다면 A는 클라이언트 )

💡 Resource Server 

  - User의 리소스를 가지고 있고 Client의 요청을 수락하고 응답할 수 있는 서버

  - Authorization Server를 통해 액세스 토큰을 발급받음

  - 그림에서 Facebook을 의미 ( A라는 App이 Facebook 프로필 사진을 가져오는 경우 Facebook이 리소스 서버 )

💡 Authorization Server

  - Resource Server가 액세스 토큰을 발급받는 서버

  - 그림에서 Facebook을 의미

💡 Authorization Grant

  - 클라이언트가 액세스 토큰을 얻는 방법

   ① Authorization Code Grant Type

   ② Client Credentials Grant Type

   ③ Implicit Grant Type

   ④ Resource Owner Credentials Grant Type

💡 Authorization Code

  - Access token을 발급받기 전에 필요한 코드

  - 클라이언트 ID로 이 코드를 받아온 후, 클라이언트 시크릿과 코드를 이용해 액세스 토큰 발급 가능

💡 Access Token

  - 보호된 리소스에 엑세스하는데 사용되는 인증 토큰

  - Authorization Code와 Client Secret을 이용해 받아온 액세스 토큰으로 리소스 서버에 접근

💡 Scope

  - 토큰의 권한 ( 접근 권한 지정 가능 )

  - 주어진 액세스 토큰을 사용하여 액세스 할 수 있는 리소스 범위

---

📍 OAuth2 의 동작 방식

▪️ 권한 부여 방식에 따른 프로토콜 : 인증 방식

 ▸ Authorization Code Grant : 권한 부여 승인 코드 방식 

  - 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식

  - 가장 많이 사용되고 리프레시 토큰 사용 가능

  - 권한 부여 승인 요청 시 응답 타입을 Code로 지정하여 요청

---

 ▸ Client Credentials Grant : 클라이언트 자격 증명 승인 방식

  - 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 클라이언트를 위한 제한된 리소스 접근 권한 설정되면 사용 가능

  - 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며 리프레시 토큰 사용 불가능

---

 ▸ Implicit Grant : 암묵적 승인 방식

  - 별도의 권한 부여 승인 코드 없이 바로 액세스 토큰을 발급받음

  - 자격증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식

  - 리프레시 토큰 사용 불가능 

  - Client Secret을 통해 클라이언트 인증과정을 생략

  - 권한 부여 승인 요청 시 응답타입을 token으로 지정하여 요청

---

 ▸ Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식

  - 간단하게 로그인시 필요한 정보로 액세스 토큰을 발급받는 방식

  - 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로 리프레시 토큰 사용 가능

  - 예를 들어 네이버 계정으로 네이버 웹툰에 로그인하는 경우에 해당

---

📍 Principal Details

  - UserDetails를 구현하는 객체

 

* Spring Security 세션 정보는 단 1가지 타입인 Authentication 객체만 가지고 있을 수 있음

 ▪️ Authentication 객체를 담는 2가지 필드

  ① OAuth2User

  - OAuth2로 회원가입 및 로그인을 하면 OAuth2User를 통해 처리 하게 됨

  ② UserDetails

  - 회원가입을 하면 UserDetails를 통해 처리됨

  → OAuth2User와 UserDetails에는 Member 객체를 포함하지 않음

   👉🏻 해결방법

   (1) UserDetails를 PrincipalDetails에 implements 한 뒤 Member 객체에 담게 함

     - Authentication 객체를 갖는 PrincipalDetails가 만들어지게 됨

     - PrincipalDetails 객체에는 Member가 포함됨

  (2) OAuth2User 또한 같은 문제점을 가지고 있고 일반 회원가입 및 로그인 처리와 OAuth 처리가 별도로 처리되어 문제 발생

     - PrincipalDetails implements UserDetails, OAuth2User를 통해 문제 해결

 

즉, Spring Security의 인메모리 세션 저장소인 SecurityContextHolder에 인증 객체를 저장

   → 인증 객체의 타입은 " Authentication " 타입 한 가지

 - Authentication은 AbstractAuthenticationToken으로 구현되어 있고 이를 

   UsernamePasswordAuthenticationToken과 OAuth2LoginAuthenticationToken이 구현하고 있음

 

 = AbstractAuthenticationToken = UsernamePasswordAuthenticationToken + OAuth2LoginAuthenticationToken + .. 

 

- UserDetails, OAuth2User을 반환하면 스프링이 알아서

   UserDetails는 UsernamePasswordAuthenticationToken으로,

   OAuth2User은 OAuth2LoginAuthenticationToken으로 변환

 

- UsernamePasswordAuthenticationToken과 OAuth2LoginAuthenticationToken은

   Authentication의 자식이니 SecurityContextHolder에 저장할 수 있게 됨

* FormLogin으로 로그인 하는 경우
 - 사용자가 직접 회원가입을 거친 후 로그인 하기 때문에 
   loadUserByUsername에서 회원을 찾고 정보를 반환
   
* OAuth2로 로그인 하는 경우
 - 사용자가 회원가입을 하지 않기 때문에
   loadUSerByUsername에서 회원을 찾고
    (없는 회원)이라면 회원가입 처리를
    (있는 회원)이라면 FormLogin과 동일하게 정보 반환

---

💡@AuthenticationPrincipal

  - 로그인이 필요한 애플리케이션에서 매번 사용자에게 서버에 요청을 보낼 대 마다 DB에 접근해서 데이터 가져오는 것은 비효율

  - 한 번 인증된 사용자 정보를 세션에 담아놓고 세션이 유지되는 동안 유저객체를 DB 접근 없이 가져다 쓸 수 있음

  (1) 컨트롤러에서 Principal 객체 주입받아 사용

  (2) 컨트롤러에서 @AuthenticationPrincipal 선언하여 엔티티 객체 받아오기

  (3) 컨트롤러에서 @AuthenticationPrincipal 선언하여 엔티티의 어댑터 객체 받아오기