OAuth 2.0 개요

- OAuth 2.0은 인터넷 사용자들이 서비스 제공자에게 사용자 정보에 대한 접근 권한을 위임하기 위해 사용하는 표준 인증 프로토콜
- 이를 통해 사용자는 자신의 자격 증명을 서비스 제공자에게 직접 공유하지 않고, 안전하게 다른 애플리케이션이나 서비스가 자신의 정보에 접근할 수 있도록 한다.
주요 구성 요소
1. Resource Owner (자원 소유자)
- 일반적으로 사용자를 지칭한다.
- 자신의 자원에 대한 접근 권한을 부여하는 주체
2. Client (클라이언트)
- Resource Owner가 접근 권한을 부여한 애플리케이션 또는 서비스
3. Authorization Server (인증 서버)
- Resource Owner를 대신해 클라이언트를 인증하고, Access Token을 발급
4. Resource Server (자원 서버)
- 보호된 자원을 호스팅하며, 클라이언트가 Access Token을 통해 접근할 수 있다.
OAuth 2.0 Grant Types (인증 방식)
- OAuth 2.0은 다양한 인증 방식을 제공한다.
- 각 방식은 특정 시나리오에 적합하도록 설계됐다.
1. Authorization Code Grant
- 가장 많이 사용되는 방식으로, 클라이언트가 사용자 대신 권한을 얻기 위해 사용된다.
- 주로 서버 간 통신에서 사용된다.
1. 클라이언트 -> 인증 서버: Authorization Request
2. 사용자 인증 -> 인증 코드 발급
3. 클라이언트 -> 인증 서버: Token Request (Authorization Code 포함)
4. 인증 서버 -> 클라이언트: Access Token 발급
1. 클라이언트가 인증 서버로부터 인증 코드(Authorization Code)를 요청한다.
2. 사용자가 인증 서버에서 인증하고, 인증 코드를 클라이언트에 전달한다.
3. 클라이언트는 인증 코드를 사용하여 인증 서버에서 Access Token을 요청한다.
4. 인증 서버는 클라이언트에게 Access Token을 발급한다.
2. Implicit Grant
- 단순한 클라이언트, 주로 브라우저 기반 애플리케이션(SPA)에서 사용된다.
- 인증 코드를 거치지 않고 Access Token을 직접 발급받는다.
1. 클라이언트 -> 인증 서버: Authorization Request
2. 사용자 인증 -> Access Token 발급 및 전달
1. 클라이언트가 인증 서버로부터 Access Token을 직접 요청한다.
2. 사용자가 인증 서버에서 인증하고, Access Token이 클라이언트로 전달된다.
3. Resource Owner Password Credentials Grant
- 신뢰할 수 있는 클라이언트에서 사용자의 자격 증명(사용자 이름과 비밀번호)을 직접 수집하여 Access Token을 요청한다.
1. 사용자 -> 클라이언트: 사용자 이름 및 비밀번호 제공
2. 클라이언트 -> 인증 서버: Token Request (자격 증명 포함)
3. 인증 서버 -> 클라이언트: Access Token 발급
1. 사용자가 클라이언트에게 자신의 자격 증명을 입력한다.
2. 클라이언트는 이 자격 증명을 사용하여 인증 서버에서 Access Token을 요청한다.
3. 인증 서버는 Access Token을 발급한다.
4. Client Credentials Grant
- 클라이언트 자체가 리소스 서버에 접근해야 할 때 사용된다.
- 클라이언트는 자체 자격 증명을 사용하여 Access Token을 요청한다.
1. 클라이언트 -> 인증 서버: Token Request (클라이언트 자격 증명 포함)
2. 인증 서버 -> 클라이언트: Access Token 발급
1. 클라이언트가 인증 서버에 자격 증명을 사용하여 Access Token을 요청한다.
2. 인증 서버는 Access Token을 발급한다.
주요 토큰
1. Access Token
- 보호된 리소스에 접근하기 위해 클라이언트에게 발급되는 토큰
- 짧은 수명
2. Refresh Token
- Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용하는 토큰
- 더 긴 수명
보안 고려사항
1. HTTPS 사용
- 모든 통신을 HTTPS를 통해 암호화하여 토큰의 중간 탈취를 방지한다.
2. 토큰 저장
- Access Token과 Refresh Token을 안전한 저장소에 보관한다.
3. 토큰 수명 관리
- Access Token의 수명을 짧게 설정하고, Refresh Token을 주기적으로 회전시킨다.
4. 권한 최소화
- 토큰의 권한을 최소한으로 제한하여 필요 없는 리소스 접근을 방지한다.
5. 토큰 무효화
- 사용되지 않거나 유출된 토큰을 즉시 무효화하는 메커니즘을 갖춘다.
요약
- OAuth 2.0은 다양한 인증 시나리오를 지원하는 유연한 인증 프로토콜
- Access Token과 Refresh Token을 사용하여 안전하게 리소스에 접근할 수 있으며, 이를 구현할 때 보안 고려사항을 철저히 지켜야 한다.
- 각 Grant Type은 특정한 사용 사례에 적합하도록 설계되었으며, 이를 올바르게 이해하고 사용하는 것이 중요하다.
'CS' 카테고리의 다른 글
PCI DSS (0) | 2024.07.31 |
---|---|
데이터 모델링(Data Modeling) (3) | 2024.07.25 |
DBMS와 SQL (0) | 2024.07.02 |
IA란? (0) | 2024.06.28 |
UX와 CX의 개념 차이점 (0) | 2024.06.26 |
OAuth 2.0 개요

- OAuth 2.0은 인터넷 사용자들이 서비스 제공자에게 사용자 정보에 대한 접근 권한을 위임하기 위해 사용하는 표준 인증 프로토콜
- 이를 통해 사용자는 자신의 자격 증명을 서비스 제공자에게 직접 공유하지 않고, 안전하게 다른 애플리케이션이나 서비스가 자신의 정보에 접근할 수 있도록 한다.
주요 구성 요소
1. Resource Owner (자원 소유자)
- 일반적으로 사용자를 지칭한다.
- 자신의 자원에 대한 접근 권한을 부여하는 주체
2. Client (클라이언트)
- Resource Owner가 접근 권한을 부여한 애플리케이션 또는 서비스
3. Authorization Server (인증 서버)
- Resource Owner를 대신해 클라이언트를 인증하고, Access Token을 발급
4. Resource Server (자원 서버)
- 보호된 자원을 호스팅하며, 클라이언트가 Access Token을 통해 접근할 수 있다.
OAuth 2.0 Grant Types (인증 방식)
- OAuth 2.0은 다양한 인증 방식을 제공한다.
- 각 방식은 특정 시나리오에 적합하도록 설계됐다.
1. Authorization Code Grant
- 가장 많이 사용되는 방식으로, 클라이언트가 사용자 대신 권한을 얻기 위해 사용된다.
- 주로 서버 간 통신에서 사용된다.
1. 클라이언트 -> 인증 서버: Authorization Request
2. 사용자 인증 -> 인증 코드 발급
3. 클라이언트 -> 인증 서버: Token Request (Authorization Code 포함)
4. 인증 서버 -> 클라이언트: Access Token 발급
1. 클라이언트가 인증 서버로부터 인증 코드(Authorization Code)를 요청한다.
2. 사용자가 인증 서버에서 인증하고, 인증 코드를 클라이언트에 전달한다.
3. 클라이언트는 인증 코드를 사용하여 인증 서버에서 Access Token을 요청한다.
4. 인증 서버는 클라이언트에게 Access Token을 발급한다.
2. Implicit Grant
- 단순한 클라이언트, 주로 브라우저 기반 애플리케이션(SPA)에서 사용된다.
- 인증 코드를 거치지 않고 Access Token을 직접 발급받는다.
1. 클라이언트 -> 인증 서버: Authorization Request
2. 사용자 인증 -> Access Token 발급 및 전달
1. 클라이언트가 인증 서버로부터 Access Token을 직접 요청한다.
2. 사용자가 인증 서버에서 인증하고, Access Token이 클라이언트로 전달된다.
3. Resource Owner Password Credentials Grant
- 신뢰할 수 있는 클라이언트에서 사용자의 자격 증명(사용자 이름과 비밀번호)을 직접 수집하여 Access Token을 요청한다.
1. 사용자 -> 클라이언트: 사용자 이름 및 비밀번호 제공
2. 클라이언트 -> 인증 서버: Token Request (자격 증명 포함)
3. 인증 서버 -> 클라이언트: Access Token 발급
1. 사용자가 클라이언트에게 자신의 자격 증명을 입력한다.
2. 클라이언트는 이 자격 증명을 사용하여 인증 서버에서 Access Token을 요청한다.
3. 인증 서버는 Access Token을 발급한다.
4. Client Credentials Grant
- 클라이언트 자체가 리소스 서버에 접근해야 할 때 사용된다.
- 클라이언트는 자체 자격 증명을 사용하여 Access Token을 요청한다.
1. 클라이언트 -> 인증 서버: Token Request (클라이언트 자격 증명 포함)
2. 인증 서버 -> 클라이언트: Access Token 발급
1. 클라이언트가 인증 서버에 자격 증명을 사용하여 Access Token을 요청한다.
2. 인증 서버는 Access Token을 발급한다.
주요 토큰
1. Access Token
- 보호된 리소스에 접근하기 위해 클라이언트에게 발급되는 토큰
- 짧은 수명
2. Refresh Token
- Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용하는 토큰
- 더 긴 수명
보안 고려사항
1. HTTPS 사용
- 모든 통신을 HTTPS를 통해 암호화하여 토큰의 중간 탈취를 방지한다.
2. 토큰 저장
- Access Token과 Refresh Token을 안전한 저장소에 보관한다.
3. 토큰 수명 관리
- Access Token의 수명을 짧게 설정하고, Refresh Token을 주기적으로 회전시킨다.
4. 권한 최소화
- 토큰의 권한을 최소한으로 제한하여 필요 없는 리소스 접근을 방지한다.
5. 토큰 무효화
- 사용되지 않거나 유출된 토큰을 즉시 무효화하는 메커니즘을 갖춘다.
요약
- OAuth 2.0은 다양한 인증 시나리오를 지원하는 유연한 인증 프로토콜
- Access Token과 Refresh Token을 사용하여 안전하게 리소스에 접근할 수 있으며, 이를 구현할 때 보안 고려사항을 철저히 지켜야 한다.
- 각 Grant Type은 특정한 사용 사례에 적합하도록 설계되었으며, 이를 올바르게 이해하고 사용하는 것이 중요하다.
'CS' 카테고리의 다른 글
PCI DSS (0) | 2024.07.31 |
---|---|
데이터 모델링(Data Modeling) (3) | 2024.07.25 |
DBMS와 SQL (0) | 2024.07.02 |
IA란? (0) | 2024.06.28 |
UX와 CX의 개념 차이점 (0) | 2024.06.26 |