🌿With Spring/Spring Security

OAuth2 알아보기

코딩베이비 2022. 11. 25. 15:17

OAuth2란?

  • Open Standard for Authorization
  • 인터넷 사용자들이 로그인 자격증명(ID/Password 등)을 전송하지 않고도 다른 웹사이트에 있는 자신의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있도록 하는 것
  • 특정 애플리케이션(Client)에서 사용자의 인증을 직접 처리하는 것이 아닌, 사용자 정보를 보유하고 있는 신뢰할 만한 third-party application(Google, Github 등)에서 사용자의 인증을 대신 처리해주고 resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 이용해 third-part application의 서비스를 사용하게 해주는 방식

 

예를 들자면, 일정 관리 애플리케이션을 만들기 위해 Google Calendar API를 사용할 때, 애플리케이션을 사용하는 사용자의 Google 전용 credential은 일정 관 애플리케이션에 직접적으로 제공되지 않아도 된다. 로그인 자체는 구글 로그인 인증을 이용하고, 구글 로그인에 성공 시 Access Token을 전달 받아서 Google Calendar API를 사용하기 위해 Access Token을 이용하게 된다.

OAuth2 사용 유형

3rd party application에서 제공하는 API의 직접적인 사용

  • Google, Github 등 신뢰할 만한 third-party application에서 제공하는 API를 직접적으로 사용하는 애플리케이션 구현
  • 사용자가 OAuth2 인증 프로토콜을 통해 third-party application에 대한 인증 성공 시, third-party application에서 제공하는 API를 활용한 커스텀 서비스 제공

추가적인 인증 서비스 제공

  • 일반적으로 제공하는 Id/Password 로그인 인증 외에 OAuth2를 이용한 로그인 방법을 추가 제공
  • 특정 서비스를 제공하는 애플리케이션에서 사용자의 credential을 남기고 싶지 않을 때 사용 가능

 

 

OAuth2 인증 컴포넌트들의 역할

Resource Owner

- 사용하고자 하는 Resource의 소유자(Google 등의 서비스를 이용하는 사용자)

- Resource에 대한 접근을 허가해 줄 수 있는 주체

- '코베'라는 사용자가 구글 계정으로 로그인 해서 구글 서비스(resource)를 이용한다면 코베가 구글 서비스(resource)의 Resource Owner이다.

 

Client

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

- Resource Server에서 제공하는 resource를 사용하는 애플리케이션

- 서버, 데스크탑, 모바일, 기타 장치 등에서 실행될 수 있음

- Resource Owner는 Client를 통해 서비스에 로그인한다.

- '코베'라는 사용자가 일정 관리 애플리케이션을 사용할 때 구글 계정으로 로그인 한다면 일정 관리 애플리케이션이 Client이다.

 

Resource Server

- OAuth2 인증 처리 과정에서 Client의 요청을 수락하고 Resource Owner에게 resource를 제공하는 서버

- 자원을 호스팅하는 서버

- 일정 관리 애플리케이션이 Google Calendar에서 '코베'라는 사용자의 일정(resource)을 가져올 경우, Google Calendar 서비스를 제공해주는 곳이 Resource Server가 된다.

 

Authorization Server

- OAuth2 인증 처리 과정에서 Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버

- Resource Owner가 인증에 성공하면 Authorization Server는 Client에게 Access Token 형태로 권한을 부여

- '코베'라는 사용자가 구글 로그인에 성공하면, 일정 관리 애플리케이션은 Authorization Server로부터 Google Calendar에 있는 '코베'의 일정들(resource)에 접근할 수 있는 권한을 부여받는다.

 

OAuth2 인증 처리 과정

1. Resource Owner는 Client역할을 하는 웹 애플리케이션에게 OAuth2 인증을 요청한다.

 

2. Client는 자체적인 로그인 화면을 제공하는 것이 아닌, Resource Owner가 자신의 계정 정보를 관리하고 있는 third-party application에 로그인 할 수 있도록 third-party application의 로그인 페이지로 redirect한다.

 

3. Resource Owner는 로그인 인증 진행 후 인증에 성공할 경우,

 

4. Authorization Server가 Resource Owner의 로그인 인증이 성공적으로 진행됐음을 증명하는 Access Token을 Client에게 전송한다. (Resource Owner에게 토큰을 주는 것이 아닌 Client에게 전송하는 것. Client가 대리인 역할 수행중)

 

5. Access Token을 받은 Client는 이제 Resource Owner의 대리인 역할을 수행할 수 있게 되어 Resource Server에게 Resource Owner의 resouce를 요청한다.

 

6. Resource Server는 Client가 전송한 Access Token을 검증 후 자격이 증명되면 Resource Owner의 resource를 Client에게 전송해준다.

 

 

Oauth2 인증 프로토콜 속 용어들

Authorization Grant

- Client 애플리케이션이 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 Credential

- Client가 Access Token을 얻기 위한 수단

  1. Authorization Code
  2. Implicit Grant Type
  3. Client Credentials
  4. Resource Owner Password Credentials
더보기

1️⃣Authorization Code Grant(권한 부여 승인 코드 방식)

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

- 가장 많이 쓰이며 기본이 되는 방식

- Refresh Token 사용 가능

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

1. Resource Owner는 Client 애플리케이션에게 서비스 사용 요청 전송한다.

 

2. Client는 Authorization Server에 Authorization Code를 요청한다.
이 때 미리 생성한 Client ID/Redirect URI/response type을 함께 전송한다.

 

3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.

 

4. 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에게 전달한다.

이 때 요청과 함께 전달된 Redirect URI로 Code를 전달한다.

 

5. Client는 전달 받은 Authorization Code로 Access Token을 요청한다.

Access Token을 요청할 때 미리 생성한 Secret/Redirect URI/권한부여 방식/Authorization Code를 함께 전달한다.

 

6. 요청을 확인 후 Redirect URI로 Access Token을 전달한다.

 

7. Client는 발급받은 Access Token을 이용해 Resource Server에 resource를 요청한다.

 

8. Access Token을 확인 후 요청 받은 resource를 Client에게 전달한다.

 

 

2️⃣Implicit Grant(암묵적 승인 방식)

- 별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식

- 안전한 자격증명 저장이 힘든 Client에게 최적화된 방식

- Refresh 토큰 사용 불가능

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

1. Resource Owner는 Client 애플리케이션에게 서비스 사용 요청을 전송한다.

 

2. Client는 Authorization Server에게 접급 권한을 요청한다.

이 때 미리 생성한 Client ID/Redirect URI/response type을 함께 전송한다.

(1️⃣과는 다르게 Authorization Code를 획득하기 위한 요청이 아님)

 

3. Resource Owner는 로그인 페이지를 통해 로그인한다.

 

4. 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달한다.

 

5. Client는 Access Token을 이용해 Resource Server에게 resource를 요청한다.

 

6. Access Token을 확인 후 요청 받은 resource를 Client에게 전달한다.

 

 

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

- 간단한 로그인 시 필요한 정보로 Access Token을 발급받는 방식

- 자신의 서비스에서 제공하는 애플리케이션인 경우에만 사용

- Client, Authorization Server, Resource Server가 모두 같은 시스템에 속해 있을 때만 사용 가능

- Refresh Token 사용 가능

1. Resource Owner는 Client 애플리케이션에게 서비스 사용 요청을 전송한다.
이 때 로그인에 필요한 정보(Username/Password)를 이용해 요청한다.

 

2. Client는 Resource Owner에게서 전달받은 로그인 정보로 Authorization Server에게 Access Token을 요청한다.

이 때 미리 생성한 Client ID/권한부여 방식/로그인 정보를 함께 전달한다.

 

3. 요청과 함께 온 정보들을 확인 후 Client에게 Access Token을 전달한다.

 

4. Client는 Access Token을 이용해 Resource Server에게 resource를 요청한다.

 

5. Access Token을 확인 후 요청 받은 resource를 Client에게 전달한다.

 

 

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

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

- 자격 증명을 안전하게 보관 가능한 Client에서만 사용되어야 함

- Refresh Token 사용 불가능

Access Token

- Client가 Resource Server에 있는 보호된 resource에 액세스 하기 위해 사용되는 자격 증명용 토큰

 

Scope

- 주어진 Access Token을 사용해서 액세스 할 수 있는 resource의 범위