[WEB] OAuth

🌐 웹 발전과 OAuth의 필요성

인터넷의 성장과 웹 중심 사회

• 1990년대 WWW 등장: 정보 공유가 가능해지면서 IT 산업이 급성장했고, PC통신에서 초고속 인터넷으로 발전했습니다.
• 2000년대 소셜 네트워크 등장: 페이스북 같은 SNS가 등장하며 인터넷은 정보를 얻는 곳에서 일상 공유와 소통의 장으로 변했습니다.
• 2010년대 모바일 혁명: 스마트폰 보급으로 언제 어디서나 인터넷에 접속 가능해졌으며, 다양한 온라인 서비스가 등장했습니다.

여러 서비스 간 연동에 대한 필요성 증가

• 한 사람이 다양한 온라인 서비스를 사용하는 것이 일상화되면서, 서비스 간 연동을 원하는 요구가 늘어났습니다.
• 예를 들어, 트위터의 글을 페이스북에 공유하거나, 에버노트에 구글 캘린더를 연결하는 것과 같은 작업이 필요해졌습니다.

🔒 OAuth 이전의 문제점: 취약한 인증 방식

계정 정보 공유 방식의 문제

• OAuth 이전에는 A 서비스가 B 서비스의 데이터를 이용하기 위해 사용자의 계정 정보(아이디, 비밀번호)를 직접 입력받아 인증하는 방식을 사용했습니다.
• 이는 보안에 매우 취약한 방식으로, 악의적인 해커가 사용자의 계정을 탈취하면 해당 계정을 이용해 모든 서비스에 접근할 수 있었습니다.

서비스별 독립적인 인증 체계의 비효율성

• 각 서비스는 자체 인증 체계(예: 구글의 AuthSub, 야후의 BBAuth)를 운영했지만, 각 서비스에 맞춰 인증 방식을 구현하는 것은 개발과 유지보수에 큰 부담이었습니다.
• 개발자들은 모든 서비스의 인증 체계를 각각 맞춰야 했고, 이는 보안성 또한 보장하기 어려운 구조였습니다.

🚀 OAuth의 탄생과 표준화

OAuth 탄생 배경

• 2006년, 트위터의 블레인 쿡과 소셜 북마크 사이트 Ma.gnolia의 개발자들은 OpenID를 통한 인증 방식의 한계를 인식하며, 표준적인 인증 위임 방식의 필요성을 논의하게 되었습니다.
• 이 회의를 통해 OAuth의 개념이 탄생하였고, 2007년 초안이 작성되었습니다.

OAuth의 표준화 과정

• 2008년 IETF에서 OAuth를 표준화하자는 회의가 열렸고, 2010년 OAuth 1.0이 RFC 5849로 등록되었습니다.
• 같은 해, 트위터는 모든 서드파티 앱에 OAuth 사용을 필수화하며 OAuth가 널리 사용되기 시작했습니다.
• 이후, 보안과 확장성을 개선한 OAuth 2.0이 2012년 RFC 6749와 RFC 6750으로 등록되었습니다.

🎉 OAuth의 성공과 현재

현재 대다수의 국내외 서비스들은 OAuth를 사용하여 안전하고 효율적인 인증과 권한 부여 체계를 운영하고 있습니다. OAuth를 통해 서비스 간 연동이 안전해졌으며, 비밀번호 탈취나 권한 관리 문제를 효과적으로 해결하게 되었습니다.

OAuth1.0과 OAuth2.0의 차이

OAuth와 OAuth2의 차이는 주로 프로토콜의 발전 및 보안과 기능성 측면에서 나타납니다.

두 가지 모두 사용자가 제3자 애플리케이션에 자신의 자격 증명을 제공하지 않고도 제한된 자원에 접근할 수 있도록 하는 권한 부여 프로토콜입니다. 그러나 OAuth2는 OAuth의 개선된 버전으로, 보다 안전하고 유연한 인증 방식을 제공합니다.

OAuth (1.0a)

• 서명 기반: OAuth 1.0a는 인증에 암호화된 서명을 사용합니다. 이 서명 방식은 보안이 높지만 구현이 복잡하고, 각 요청에 대해 서명을 생성해야 하므로 성능에 영향을 미칠 수 있습니다.
• 두 단계 인증: OAuth 1.0a는 토큰을 얻기 위해 요청 토큰과 엑세스 토큰의 두 단계를 거칩니다. 각 토큰을 얻기 위해서 서명으로 인증해야합니다.
• HTTP 통신: OAuth 1.0a는 모든 요청을 서명 기반으로 HTTP 통신에 의존하며, HTTPS 사용이 선택 사항이었습니다.
• 복잡한 구현: 개발자가 각 요청에 대해 서명과 검증을 처리해야 하므로 비교적 복잡한 구현이 요구됩니다.

OAuth2

• 토큰 기반: OAuth2는 서명 대신 액세스 토큰을 사용하여 인증을 처리합니다. 이 토큰은 일반적으로 Bearer 토큰 형태로 전달됩니다.
• 단일 단계 인증: OAuth2는 OAuth1과 달리 요청 토큰과 엑세스 토큰의 두 단계가 아닌 단일 단계로 엑세스 토큰을 얻을 수 있습니다.
• HTTPS 필수: OAuth2는 HTTPS 사용을 강제하여 전송 중 데이터의 안전성을 보장합니다.
• 다양한 인증 방식: OAuth2는 여러 인증 방식을 제공합니다. 예를 들어, 권한 부여 코드(Authorization Code), 암시적 흐름(Implicit Grant), 클라이언트 자격 증명(Client Credentials) 및 리소스 소유자 암호 자격 증명(Resource Owner Password Credentials) 등 다양한 시나리오에 적합한 인증 방식을 제공합니다.
• 더 유연한 설계: OAuth2는 확장 가능하고 다양한 환경에 맞출 수 있는 설계를 제공하며, JSON 기반의 응답을 사용할 수 있어 OAuth1보다 직관적입니다.

주요 차이점 요약

• 인증 방식: OAuth는 서명 기반, OAuth2는 토큰 기반입니다.
• 보안: OAuth2는 HTTPS 사용을 필수화하여 보안을 강화했습니다.
• 사용 편의성: OAuth2는 OAuth1에 비해 구현이 더 간단하고 유연합니다.
• 표준화된 프로세스: OAuth2는 여러 인증 흐름을 지원하여 다양한 시나리오에서 사용 가능합니다.

OAuth2는 보안성과 유연성을 크게 개선한 OAuth의 후속 프로토콜이라고 볼 수 있습니다.

🚀 OAuth 2.0 플로우 (Authorization Code Grant)

아래 플로우는 Authorization Code Grant 방식입니다. OAuth에서 가장 보편적으로 사용되는 방식으로, 클라이언트 애플리케이션이 Access Token을 발급받아 리소스에 접근할 수 있도록 합니다.

🎯 OAuth의 주요 요소

• 클라이언트 (Client): 사용자 정보를 얻고자 하는 외부 애플리케이션입니다. 이 클라이언트는 권한 서버를 통해 사용자의 데이터를 안전하게 요청합니다.
• 리소스 소유자 (Resource Owner): 서비스 계정을 소유하는 사용자입니다. 사용자는 외부 애플리케이션이 자신의 계정에 접근하는 것을 승인합니다.
• 권한 서버 (Authorization Server): 사용자의 권한을 검증하는 서버입니다. 일반적으로 Authorization Code를 발급하며, 이 코드를 클라이언트가 제출하면 Access Token을 반환합니다.
• 리소스 서버 (Resource Server): 사용자의 데이터를 보유하고 있는 서버로, Access Token을 가진 클라이언트만이 접근할 수 있습니다.

단계별 플로우 설명

1. 로그인 요청: 사용자가 클라이언트 애플리케이션(예: 앱)에 로그인합니다.
2. Authorization Request: 클라이언트는 사용자를 권한 서버의 로그인 페이지로 리다이렉트하여 권한을 요청합니다.
3. 사용자 권한 확인: 권한 서버는 사용자가 애플리케이션에 자신의 정보를 제공할지 여부를 결정하도록 합니다.
4. 사용자 승인: 사용자가 정보를 제공하기로 승인하면, 권한 서버는 이를 수락합니다.
5. Authorization Code 발급: 권한 서버는 클라이언트에게 Authorization Code를 반환합니다.
6. Access Token 요청: 클라이언트는 Authorization Code를 사용해 권한 서버로부터 Access Token을 요청합니다.
7. Access Token 발급: 권한 서버는 클라이언트에게 Access Token을 발급합니다.
8. Access Resource: 클라이언트는 Access Token을 사용해 리소스 서버에 접근합니다.
9. 리소스 반환: 리소스 서버는 사용자가 허용한 데이터나 기능을 클라이언트에 반환합니다.

이 흐름은 사용자 비밀번호를 직접 공유하지 않고도 사용자가 애플리케이션에 안전하게 접근할 수 있게 해줍니다.
OAuth의 단계별 흐름과 각 요소의 역할을 이해하는 데 도움이 되기를 바랍니다!