1.OAuth(Open Authorization)
인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
이를 통해 사용자는 각기 다른 사이트에 개별적으로 로그인하지 않아도 되며,
개인 정보를 안전하게 보호할 수 있다.
1-1.OAuth의 사용처
간단하게 인증과 권한을 획득하게 할수있다.
다음처럼 외부 소셜계정으로 간편하게 회원가입,로그인 할수있게 하는것을 볼수있다.
이때 사용되는 프로토콜이 OAuth다.
1-2.OAuth 사용이유?
보안 강화 | OAuth는 사용자의 비밀번호를 제3자 서비스에 직접 노출시키지 않고 안전하게 인증할 수 있도록 한다. 인증 프로세스를 통해 액세스 토큰을 발급하여 보안을 강화한다. |
사용자 편의성 | 사용자는 다른 서비스에 로그인하여 권한을 부여하는 번거로운 과정 없이도 편리하게 서비스를 이용할 수 있다. |
중앙 집중화 | 사용자는 하나의 인증 정보를 여러 서비스에서 사용할 수 있으며, 인증 정보를 관리하는 부담을 줄일 수 있다. |
유연성과 확장성 | 다양한 플랫폼 및 언어에서 지원되며, 다른 인증 방식과 통합하기 쉽다. 다양한 서비스 및 애플리케이션에 대한 통합을 간편하게 만들어준다. |
권한 관리 | OAuth를 사용하면 사용자는 소비자에게 부여되는 권한을 관리할 수 있다. 사용자는 자신의 데이터에 대한 접근 권한을 선택적으로 부여하거나 취소할 수 있다. |
API 보호 | 액세스 토큰을 통해 API에 접근하는 클라이언트를 식별하고 제어할 수 있으며, 액세스 토큰의 유효기간을 설정하여 보안을 강화할 수 있습니다. |
2.OAuth구성요소
2-1.Resource Owner (리소스 소유자)
보호되는 리소스(사용자의 데이터 또는 정보)의 소유자 또는 사용자
서비스를 이용하려는 사용자
2-2.Client (클라이언트)
OAuth를 통해 액세스하려는 보호된 리소스에 접근하려는 애플리케이션 또는 서비스,
인증 및 인가 프로세스를 수행하는 앱이나 서비스
ex) 접속하는 서비스 (웹사이트 또는 앱)
2-3.Resource Server (리소스 서버)
보호된 리소스를 호스팅하고 관리하는 서버
ex) 접속하는 서비스의 데이터베이스(사용자 정보, 게시물 등을 저장하는 서버)
2-4.Authorization Server (인가 서버)
클라이언트 애플리케이션이 리소스에 대한 액세스 권한을 얻을 수 있도록 돕는 서버
ex) 페이스북 인가 서버: 페이스북이 제공하는 OAuth 인증 서버
2-5.User Agent (사용자 에이전트)
사용자가 사용하는 웹 브라우저
3.과정
- 사용자가 "어떤" 서비스에 접속합니다.
- "어떤" 서비스는 사용자에게 페이스북 로그인 옵션을 제공합니다.
- 사용자는 "페이스북으로 로그인" 버튼을 클릭합니다.
- "어떤" 서비스는 사용자를 페이스북 인가 서버로 리다이렉션합니다. 이때, "어떤" 서비스가 요청하는 권한(예: 프로필 정보에 대한 읽기 권한)과 함께 요청을 보냅니다.
- 페이스북 인가 서버는 사용자로부터 로그인을 요청받고, 사용자에게 페이스북 로그인 페이지를 표시합니다.
- 사용자는 자신의 페이스북 계정 정보(아이디와 비밀번호)를 입력하여 로그인합니다.
- 페이스북 인가 서버는 사용자의 동의를 받고, "어떤" 서비스에 대한 사용자의 페이스북 프로필 정보에 대한 액세스 권한을 부여합니다.
- 페이스북 인가 서버는 인가 코드를 생성하여 "어떤" 서비스에게 전달합니다.
- "어떤" 서비스는 받은 인가 코드를 사용하여 페이스북 인가 서버로부터 액세스 토큰을 요청합니다.
- 페이스북 인가 서버는 검증된 인가 코드를 받고, "어떤" 서비스에게 액세스 토큰을 발급합니다.
- "어떤" 서비스는 받은 액세스 토큰을 사용하여 사용자의 페이스북 프로필 정보에 접근하고, 사용자를 로그인합니다.
- 이후 "어떤" 서비스는 사용자의 페이스북 프로필 정보를 활용하여 서비스를 제공합니다.
4.OAuth 2.0의 인증 방식
4-1.Authorization Code Grant
웹 애플리케이션과 서버 사이의 안전한 인증을 위해 설계된 방식
서버 측의 안전한 인증이 필요한 경우, 웹 애플리케이션에서 주로 사용됩니다.
1. 사용자는 먼저 클라이언트 애플리케이션에 로그인
2. 서버는 사용자의 동의를 얻기 위해 인증 코드를 리다이렉트
3. 클라이언트 애플리케이션은 이 인증 코드를 사용하여 서버에서 액세스 토큰을 요청
4-2.Implicit Grant
주로 웹 클라이언트(예: JavaScript로 작성된 애플리케이션)에서 사용
클라이언트 측에서만 인증이 필요한 경우, 주로 웹 프론트엔드에서 사용
사용자는 액세스 토큰을 바로 받고, 별도의 인증 코드 교환 단계 없이 토큰을 받게 된다.
이 흐름은 클라이언트 측에서만 실행되며, 서버 측에서는 사용되지 않습니다.
4-3.Resource Owner Password Credentials Grant
신뢰할 수 있는 클라이언트와 보안이 보장된 서버 간의 통신을 위해 사용
사용자가 자격 증명을 직접 제공하여 인증하는 경우, 주로 서버 간 통신에서 사용됩니다.
사용자의 직접적인 자격 증명(사용자 이름 및 비밀번호)을 사용하여 액세스 토큰을 받는다.
보안상의 이유로 권장되지 않는다.
4-4.Client Credentials Grant
클라이언트 자체의 자격 증명으로 서버에서 액세스 토큰을 얻는 데 사용
클라이언트 애플리케이션이 자체적으로 인증되어 서버와 통신해야 하는 경우, 주로 서버 간 통신에서 사용됩니다.
사용자의 인증이 아닌 클라이언트 애플리케이션 자체의 인증에만 사용
🎈참고자료
https://ko.wikipedia.org/wiki/OAuth
https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
'Computer Science > Security' 카테고리의 다른 글
[보안] CSRF(Cross Site Request Forgery) (0) | 2024.06.17 |
---|---|
[보안] SQL 인젝션(SQL Injection) (0) | 2024.06.16 |
[보안] XSS(Cross Site Scripting) (0) | 2024.06.16 |