OAuth 2 개념

⚡ 생각대로 살지 않으면 사는대로 생각한다.
⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.

OAuth 2 인증 컴포넌트(Component, 구성 요소)들의 역할

• Resource Owner : Resource 사용자
• Client : 사용자를 대신해 보호된 Resource에 액세스하는 애플리케이션
• Authorization Server : Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버
  • Resource Owner가 인증에 성공하면,
    Authorization Server는 Client에게 AccessToken형태로 Resource Owner의 Resource에 접근할 수 있는 권한을 부여한다.
• Resource Server : Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버

OAuth 2 인증 프로토콜에서 사용되는 용어

Access Token

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

Scope

• 액세스 토큰을 사용하여 액세스할 수 있는 Resource의 범위를 의미

Authorization Grant

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

Authorization Grant의 4가지 타입

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

• 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식
• 가장 많이 쓰이고 기본이 되는 방식
• 이 방식에서는 Refresh Token을 사용할 수 있다.
• 권한 부여 승인 요청시 응답 타입(response_type)을 code로 지정하여 요청

Authorization Code 방식 흐름

1. Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송
2. Client는 Authorization Server에 Authorization Code를 요청.
   이 때 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행.
4. 로그인이 확인되면 Authorization Server는 Authorization Code를 Client에게 전달. (이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달합니다.)
5. Client는 전달받은 Authorization Code를 이용해 Access Token 발급을 요청.
   AccessToken을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorization Code를 함께 전송.
6. 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급.
7. Client는 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청합니다.
8. Access Token을 확인한 후 요청 받은 Resource를 Client에게 전달

Implicit Grant Type : 암묵적 승인 방식

• 별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식
• 이 방식은 자격증명을 안전하게 저장하기 힘든 Client(자바스크립트 등 스크립트 언어를 사용하는 브라우저)에게 최적화된 방식
• Refresh Token 사용이 불가능하며, 이 방식에서 Authorization Server는 Client Secret을 통해 클라이언트 인증 과정을 생략한다.
• 권한 부여 승인 요청시 응답 타입(response_type)을 token으로 지정하여 요청.

Implicit Grant Type 방식 흐름

1. Resource Owner는 소셜 로그인 버튼을 누르는 등의 서비스 요청을 Client(애플리케이션)에게 전송.
2. Client는 Authorization Server에게 접근 권한을 요청.

• 요청과 함께 미리 생성한 Client ID, Redirect URI, 응답타입을 전송한다. (⭐ Authroization Code를 획득하기 위한 요청이 아닙니다)

3. Resource Owner는 로그인 페이지를 통해 로그인을 진행.
4. 로그인이 확인되면 Authorization Server는 Client에게 Access Token을 전달.
5. Client는 Access Token을 이용해 Resource Server에게 Resource를 요청.
6. Access Token을 확인한 후 요청 받은 Resource를 전달.

위의 Authorization Grant 유형과 다르게 Authorization Code 요청/전달을 생략.

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

• 로그인 시 필요한 정보(username, password)로 Access Token을 발급받는 방식
  • 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식으로, Refresh Token의 사용도 가능
  • 예를 들어 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인 / 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우가 이에 해당
• 다시 말해 Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용이 가능하다!

Resource Owner Password Credential Grant 방식 흐름

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 Credentials Grant : 클라이언트 자격 증명 승인 방식

• Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용 가능한 방식
• 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야 하며, Refresh Token의 사용은 불가능하다.

Client Credentials Grant 방식 흐름

1. Client가 Authorization Server로 Access Token을 요청
2. Authorization Server는 Client에게 Access Token을 전달.
3. Client는 Access Token을 이용해 Resource Server에게 Resource를 요청.
4. Access Token을 확인한 후 요청 받은 Resource를 전달.

※ 인증 처리 흐름에서 Resource Owner를 제외 하고 생각!!!

-끝-