🌈 [Section4] 5. [ Spring Security ] OAuth2 1

📕 오늘 배운 내용!

• OAuth 2
• OAuth 2 사용 애플리케이션 유형
• OAuth 2 인증 컴포넌트들의 역할
• OAuth 2 기본 동작 흐름
• Authorization Grant / Access Token / Scope

---

✏️ OAuth 2 인증 프로토콜

( OAuth = Open Authorization )

• 사용자가 특정 서비스를 이용하기 위해 신뢰할 만한 벤더에게 대신 인증 처리를 위임하는 방식

• 사용자 정보를 보유하고 있는 신뢰할만한 third party 애플리케이션에서 사용자의 인증을 대신 처리해주고,
  Resource에 대한 자격 증명용 토큰을 발급한 후,
  Client가 해당 토큰을 이용해 third party 애플리케이션의 서비스를 사용하게 해주는 방식
  Ex. GitHub, Google, Facebook 등

  💬 Third Party Application :
  우리가 대신 인증처리 해줄게.
  OK 너 인증 됐으니까 자격 증명용 토큰 발급해줄게.
  너 이제 우리 서비스 사용해도 됨.

  ---

  Ex. 로그인 자체는 Google 로그인 인증을 사용하고,
  Google 로그인에 성공하면 Access Token을 전달받아서
  Google Calendar API를 사용하기 위해 Access Token 이용

• 사용자의 크리덴셜을 이중으로 관리하지 않아도 됨
  ➜ 보안성 향상

[참고]
https://www.rfc-editor.org/rfc/rfc6749#section-1.1

❗ jwt 방식은 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜을 서버 or DB에서 직접 관리했음

💡 기존 방식에 Google Calendar API를 사용한다고 할 때 문제점 ( OAuth 2 사용 X ),
⠀
➜ 서버가 사용자의 크리덴셜을 관리해야함은 물론이고,
Google의 Calender API 이용을 위해 Google에서 사용하는 사용자의 크리덴셜까지 일정 관리 서비스와 공유해야함
⠀
이 경우,

• 가장 중요한 정보인 크리덴셜이 두개나 관리되어야 함
• Google에서 password 변경을 해도, 일정 관리 서비스 애플리케이션에 password를 또 따로 업데이트해줘야 함
• 일정 관리 애플리케이션이 Google 사이트에서 사용하는 크리덴셜을 직접적으로 가지고 있음
  ⠀
  👉 OAuth 2 인증 프로토콜을 이용하여, Google에서 사용하는 사용자의 크리덴셜을 일정 관리 서비스 애플리케이션에서 직접적으로 관리하지 않으면서도 Google Calendar API를 이용할 수 있게 해야함

---

✏️ OAuth 2 사용 애플리케이션 유형

1. third party 애플리케이션에서 제공하는 API의 직접적인 사용할 경우

• 사용자가 OAuth 2 인증 프로토콜을 이용해 third party 애플리케이션에 대한 인증에 성공하면,
  third party 애플리케이션에서 제공하는 API를 활용한 Custom 서비스를 제공하는 것

2. 추가적인 인증 서비스 제공 용도로 사용할 경우

• 일반적으로 제공하는 아이디/패스워드 로그인 인증 이외에 OAuth 2를 이용한 로그인 인증 방법을 추가적으로 제공하는 것
  ⠀
  ( 특정 서비스를 제공하는 애플리케이션에서 사용자의 크리덴셜을 남기고 싶지 않을 경우, OAuth 2 로그인 인증 방법으로 로그인하면 됨 )

---

✏️ OAuth 2 인증 컴포넌트 (구성 요소)

( Resource를 기준으로 구성요소의 이름이 바뀜 )

✔️ Resource Owner ( 사용자 )

• 사용하고자 하는 Resource의 소유자
  ( 로그인해서 Google 등의 서비스를 이용하는 사용자 )

  Ex. A라는 사용자가 Google에 로그인하여 Google의 서비스(Resource)를 이용하고 있다면 A가 Google 서비스라는 Resource에 대한 Resource Owner

✔️ Client ( 서버 / 애플리케이션 )

• Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션

  ❗ Client - Server 는 기준에 따라 달라지기 때문에
  여기서는 Resource를 받는 곳이 서버여서 서버가 Client가 됨

• Resource Owner의 대리인 역할 수행

  Ex. A라는 사용자가 B라는 애플리케이션을 통해 Google의 소셜 로그인을 이용한다면 애플리케이션 B가 Client

✔️ Resource Server ( 리소스(서비스) 제공 서버 )

• Client의 요청을 수락하고 Resource Owner에게 해당 Resource를 제공하는 서버

  Ex. A라는 애플리케이션(Client)이 Google Photo에서 A라는 Resource Owner의 사진(Resource)을 가져오는 경우,
  Google Photo 서비스를 제공하는 애플리케이션이 Resource Sever

✔️ Authorization Server ( 접근 권한 부여 서버 )

• Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버
  ⠀
  ➜ Resource Owner가 인증에 성공하면,
  Authorization Server가 Client에게 Access Token 형태로 Resource Owner의 Resource에 접근할 수 있는 권한 부여함

  Ex. A 사용자(Resource Owner)가 Google 로그인 인증에 성공하면,
  B 애플리케이션(Client)이 Authoriztion Server로부터 Google Photo에 저장되어 있는 A의 사진(Resource)에 접근할 수 있는 권한(Access Token)을 부여함

[참고] https://www.rfc-editor.org/rfc/rfc6749#section-1.1

---

✏️ OAuth 2 기본 동작 흐름

① Resource Owner가 웹 애플리케이션(Client)에게 OAuth2 인증 요청

( Resource Owner는 자신의 계정 정보를 관리하고 있는 써드 파티 애플리케이션에 로그인 하길 원하는 것이기에, 이 요청을 웹 애플리케이션(Client)에 전송하는 것 )

② Client사 Resource Owner가 Resource Owner의 계정 정보를 관리하고 있는 third party 애플리케이션에 로그인 할 수 있도록,
third party 애플리케이션의 로그인 페이지로 리다이렉트(Redirect)

③ Resource Owner가 로그인 인증을 진행하고 로그인 인증에 성공하면,

④ Authorization Server가 Resource Owner의 로그인 인증이 성공적으로 수행되었음을 증명하는 Access Token을 Client에게 전송

( Resource Owner가 아닌 대리인 역할을 하는 애플리케이션(Client)에게 전송하는 것 )

⑤ Access Token을 전달 받은 Client가 Resource Server에게 Resource Owner 소유의 Resource 요청

⑥ Resource Server가 Client가 전송한 Access Token을 검증 후,
검증 완료 되면( Client가 Resource Owner의 대리인으로써의 자격이 증명되면 ) Resource Owner의 Resource를 Client에게 전송

[참고]
https://learn.microsoft.com/ko-kr/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow

---

✏️ OAuth 2 관련 용어

✔ Authorization Grant

• 애플리케이션(Client)이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜(Credential)
  ➜ Client가 Access Token을 얻기 위한 수단

✔️ Authorization Grant에 따른 인증 처리 방식

• 권한 부여 승인 코드 방식 ( Authorization Code Grant )

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

  • 가장 많이 쓰임 / 기본

  • Refresh Token 사용 가능

  • 권한 부여 승인 요청시 응답 타입(response_type)을 code로 지정하여 요청
    

    ① Resource Owner(사용자)가 서비스 요청을 Client(애플리케이션)에게 전송
    ( Ex. 로그인 버튼 누르기 )

    ② Client(애플리케이션)가 Authorization Server에 Authorization Code 요청
    ( 이 때, 미리 생성한 < Client ID / Redirect URI / 응답 타입 > 함께 전송 )

    ③ Resource Owner(사용자)가 로그인 페이지를 통해 로그인 진행

    ④ 로그인이 확인되면 Authorization Server가 Authorization Code를 Client(애플리케이션)에게 전달
    ( 이 전에 요청과 함께 전달했던 Redirect URI로 Code를 전달 )

    ⑤ Client(애플리케이션)가 전달받은 Authorization Code를 이용해 Access Token 발급 요청
    ( 이 때, < Client Secret / Redirect URI / 권한 부여 방식 / Authorization Code > 함께 전송 )

    ⑥ 요청 정보를 확인 후, Redirect URI로 Access Token 발급

    ⑦ Client(애플리케이션)가 발급받은 Access Token을 이용해 Resource Server에게 Resource 요청

    ⑧ Resource Server가 Access Token 확인 후, 요청 받은 Resource를 Client(애플리케이션)에게 전달
    ⠀

• 암묵적 승인 방식 ( Implicit Grant )

  • Authorization Code 없이 바로 Access Token을 발급하는 방식
    ➜ Authorization Server가 Client Secret을 통한 클라이언트 인증 과정 생략

  • 자격증명을 안전하게 저장하기 힘든 Client에게 최적화된 방식
    Ex. 스크립트 언어를 사용하는 브라우저 ( 자바스크립트 등 )

  • Refresh Token 사용 불가

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

    ① Resource Owner(사용자)가 서비스 요청을 Client(애플리케이션)에게 전송
    ( Ex. 로그인 버튼 누르기 )

    ② Client(애플리케이션)가 Authorization Server에게 접근 권한 요청
    ( 이 때, 미리 생성한 < Client ID / Redirect URI / 응답타입 > 함께 전송 )
    ( ❗ Authroization Code를 획득을 위한 요청 X )

    ③ Resource Owner(사용자)가 로그인 페이지를 통해 로그인 진행

    ④ 로그인 확인되면, Authorization Server가 Client(애플리케이션)에게 Access Token 전달

    ⑤ Client(애플리케이션)가 받은 Access Token을 이용해 Resource Server에게 Resource 요청

    ⑥ Resource Server가 Access Token 확인 후, 요청 받은 Resource를 Client(애플리케이션)에게 전달
    ⠀

• 클라이언트 자격 증명 승인 방식 ( Client Credentials Grant )

  • 간단하게 로그인 시 필요한 정보(username, password)로 Access Token을 발급받는 방식

  • 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식
    ➜ Authorization Server / Resource Server / Client 가 모두 같은 시스템에 속해 있을 때만 사용이 가능
    Ex. 카카오 계정으로 카카오택시 애플리케이션 로그인하는 경우

  • Refresh Token 사용 가능
    

    ① Resource Owner(사용자)가 서비스 요청을 Client(애플리케이션)에게 전송
    ( Ex. 로그인 버튼 누르기 )
    ( 이 때, 로그인에 필요한 정보(Username / Password)를 이용해 요청 )

    ② Client(애플리케이션)가 Resource Owner에게서 전달받은 로그인 정보를 통해 Authorization Server에 Access Token 요청
    ( 이 때, 미리 생성한 < Client ID / 권한 부여 방식 / 로그인 정보 > 함께 전송 )

    ③ 요청과 함께 온 정보들 확인 후, Client(애플리케이션)에게 Access Token 전달

    ④ Client(애플리케이션)가 발급받은 Access Token을 이용해 Resource Server에게 Resource 요청

    ⑤ Resource Server가 Access Token 확인 후, 요청 받은 Resource를 Client(애플리케이션)에게 전달
    ⠀

• 자원 소유자 자격 증명 승인 방식 ( Resource Owner Password Credential Grant )

  • Client 자신이 관리하는 Resource / Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용 가능한 방식

  • 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야함

  • Refresh Token 사용 불가
    
    

[참고] https://www.rfc-editor.org/rfc/rfc6749#page-23

✔ Access Token

• Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위해 사용하는 자격 증명용 토큰
  ➜ Authorization Code와 Client Secret을 이용해 Authorization Server로 부터 전달 받은 Access Token으로 자격을 증명하면 Resource Server에 접근 가능

✔ Scope

• 주어진 액세스 토큰을 사용하여 액세스할 수 있는 Resource의 범위

---

🌈 느낀점

실습이 아니라 아직까지는 할만하다..!
개념 잘 익히고 주말동안 열공해야지