<Step 1> OAuth 2.0 개념

 

📌 OAuth 2.0 소개

 

• OAuth = Open + Authorization
• The OAuth 2.0 Authorization Framework (RFC 6749) : OAuth 2.0 인가 프레임 워크는 애플리케이션이 사용자 대신하여 사용자의 자원에 대한 제한된 액세스를 얻기 위해 승인 상호작용을 함으로써 애플리케이션이 자체적으로 액세스 권한을 얻도록 한다.

 

 

✔ OAuth 2 이전 방식의 문제점

1.  아이디와 패스워드가 노출되어 보안에 취약
2.  Protected Resource 의 모든 서비스를 제한없이 사용 가능
3.  클라이언트 애플리케이션을 신뢰할 수 있는가?

 

✔ OAuth 2 방식

1. 아이디와 패스워드로 로그인 할 필요가 없다
2. Protected Resource의 서비스를 범위에 따라 제한할 수 있다
3. 클라이언트 어플리케이션의 신뢰 여부를 판단할 필요가 없다

 

 

 

 

 

 

 

🚩 OAuth 2.0 Roles

1. Resource Owner (자원 소유자) 

• 보호된 자원에 대한 접근 권한을 부여할 수 있는 주체, 사용자로서 계정의 일부에 대한 접근 권한을 부여 하는 사람
• 사용자를 대신하여 작동하려는 모든 클라이언트는 먼저 사용자의 허가를 받아야 한다.

 

 

2. Resource Server (보호 자원 서버)

• 타사 어플리케이션에서 접근하는 사용자의 자원이 포함된 서버를 의미한다.
• 액세스 토큰을 수락 및 검증할 수 있어야 하며 권한 체계에 따라 요청을 승인할 수 있어야 한다.

 

 

3. Authorization Server (인가 서버)

• 클라이언트가 사용자 계정에 대한 동의 및 접근을 요청할 때 상호작용하는 서버로서 클라이언트의 권한 부여 요청을 승인하거나 거부하는 서버
• 사용자가 클라이언트에게 권한 부여 요청을 승인한 후 access token 을 클라이언트에게 부여하는 역할

 

 

 

4. Client (클라이언트) 

• 사용자를 대신하여 권한을 부여받아 사용자의 리소스에 접근하려는 어플리케이션
• 사용자를 권한 부여 서버로 안내하거나 사용자의 상호작용 없이 권한 부여 서버로부터 직접 권한을 얻을 수 있다.

 

 

 

 

 

 

 

 

🚩 OAuth 2.0 Client Types

• 개요 

   : 인증 서버에 클라이언트를 등록할 때 클라이언트 자격 증명인 클라이언트 아이디와 클라이언트 암호를 받는다.

     클라이언트 암호는 비밀이고 그대로 유지되어야 하는 반면, 아이디는 공개이다.

      이 자격 증명은 인증 서버에 대한 클라이언트 ID를 증명한다.

 

 

 

 

• 공개 클라이언트 (Public Clients)  -   " implicit " flow (deprecated)  

: 공개 클라이언트는 client_secret 의 기밀을 유지할 수 없으므로 이러한 앱에는 secret이 사용되지 않는다.

브라우저(SPA)에서 실행되는 JavaScript 애플리케이션, Android 또는 iOS 모바일 앱, 데스크 톱에서 실행되는 기본 앱 뿐만 아니라 IoT / 임베디드 장치에서 실행되는 애플리케이션 등이 있다.

Chrome 개발자 콘솔이나 디스 어셈블러와 같은 디버깅 도구를 사용하여 바이너리/ 실행 코드에서 기밀 정보를 추출할 수 있기 때문에 공개로 간주된다.

서버 측이 아닌 리소스 소유자가 사용하는 장치에서 실행되는 모든 클라이언트는 공개 클라이언트로 간주되어야 한다.

 

 

 

 

 

• 기밀 클라이언트 (Confidential Clients)  -  " authorization code"  flow

 : 기밀 클라이언트는 client_secret의 기밀성을 유지할 수 있는 클라이언트를 의미한다.

일반적으로 사용자가 소스 코드에 액세스 할 수 없는 서버에서 실행되는 응용 프로그램으로 NET, Java, PHP 및 Node.JS 와 같은 서버 측 언어로 작성된다.

이러한 유형의 애플리케이션은 대부분 웹 서버에서 실행되기 때문에 일반적으로 "웹 앱" 이라고 한다.

 

 

 

 

 

 

 

 

 

 

🚩 OAuth 2.0 Token Types

 

▶ Access Token

: 클라이언트에서 사용자의 보호된 리소스에 접근하기 위해 사용하는 일종의 자격 증명으로, 리소스 소유자가 클라이언트에게 부여한 권한 부여의 표시이다.

일반적으로 JWT(Json Web Tokens) 형식을 취하지만 사양에 따라 그럴 필요는 없다.

타입에는 식별자 타입(Identifier Type)과 자체 포함 타입(Self-contained Type)이 있다.

 

< 식별자 타입 >
- 인가 서버는 데이터 저장소에 토큰의 내용을 저장하고 이 토큰에 대한 고유 식별자만 클라이언트에 다시 발행한다.
- 이 토큰을 수신하는 API는 토큰의 유효성을 검사하기 위해 인가 서버에 대한 백채널 통신을 열고 DB를 조회해야 한다.

< 자체 포함 타입 >
- JWT 토큰 형식으로 발급되며 클레임 및 만료가 있는 보호된 데이터 구조이다.
- 리소스 서버 API가 검증 키 등의 핵심 자료에 대해 알게되면 발급자와 통신할 필요없이 자체 포함된 토큰의 유효성을 검사할 수 있다.
- 특정한 암호화 알고리즘에 의해 개인키로 서명되고, 공개키로 검증할 수 있으며 만료될 때까지 유효하다.

 

 

 

 

▶ Refresh Token

: 액세스 토큰이 만료된 후 새 액세스 토큰을 얻기 위해 클라이언트 응용 프로그램에서 사용하는 자격 증명,

인증 서버는 클라이언트가 전달한 Refresh Token 의 유효성을 검사하고, 새 액세스 토큰을 발급한다.

Refresh Token은 액세스 토큰과 달리 권한 서버 토큰 엔드포인트에만 보내지고 리소스 서버에는 보내지 않는다.

 

 

 

▶ ID Token

: ID 토큰은 사용자가 인증되었음을 증명하는 결과물로서, OIDC 요청시 access token과 함께 클라이언트에게 전달되는 토큰이다.

ID 토큰은 JWT으로 표현되며, 헤더, 페이로드 및 서명으로 구성된다.

ID 토큰은 개인 키로 발급자가 서명하는 것으로 토큰의 출처를 보장하고 변조되지 않았음을 보장한다.

 

 

 

▶ Authorization Code

:  권한 부여 코드 흐름에서 사용되며, 클라이언트가 액세스 토큰과 교환할 임시 코드이다.

사용자가 클라이언트가 요청하는 정보를 확인하고 인가 서버로부터 리다이렉트 되어 받아온다.