OAuth: 두 판 사이의 차이
기술노트
(CS 용어 정리 - OAuth 추가) |
(Gemini 벌크 업로더로 자동 업로드) |
||
| 1번째 줄: | 1번째 줄: | ||
== | == 🔐 OAuth == | ||
'''OAuth'''는 인터넷 사용자들이 비밀번호를 직접 제공하지 않고도, '''다른 웹사이트나 애플리케이션의 자신의 정보에 대한 접근 권한을 안전하게 부여'''할 수 있는 개방형 표준 프로토콜입니다. 주로 소셜 로그인(Social Login) 기능에서 널리 사용됩니다. | |||
OAuth는 '인증(Authentication)'이 아닌 '''허가(Authorization)'''를 위한 프로토콜입니다. 즉, "당신이 누구인지"를 증명하는 것이 아니라, "당신이 가진 특정 리소스에 접근해도 좋다"고 허락해주는 역할을 합니다. | |||
---- | |||
=== 👥 OAuth의 주요 역할자 === | |||
* '''리소스 소유자 (Resource Owner)''' : 사용자 본인. 자신의 정보에 대한 접근 권한을 가집니다. | |||
* '''클라이언트 (Client)''' : 리소스 소유자를 대신하여 보호된 리소스에 접근하려는 애플리케이션. (예: 우리가 개발하는 웹/앱 서비스) | |||
* '''인증 서버 (Authorization Server)''' : 리소스 소유자를 인증하고, 클라이언트에게 접근 토큰(Access Token)을 발급해주는 서버. (예: 구글, 카카오의 인증 서버) | |||
* '''리소스 서버 (Resource Server)''' : 보호된 리소스를 호스팅하는 서버. (예: 구글의 사용자 정보 API, 카카오의 메시지 API) | |||
---- | |||
=== | === ⚙️ OAuth 2.0 동작 방식 (Authorization Code Grant) === | ||
가장 일반적인 소셜 로그인 시나리오입니다. | |||
1. 사용자가 우리 서비스에서 "구글로 로그인" 버튼을 클릭합니다. | |||
2. 우리 서비스(클라이언트)는 사용자를 구글(인증 서버)의 로그인 페이지로 리디렉션시킵니다. | |||
3. 사용자는 구글에 아이디/비밀번호를 입력하고, 우리 서비스에 정보 제공을 동의합니다. | |||
4. 구글은 사용자를 우리 서비스로 다시 리디렉션시키면서, 임시 '인증 코드(Authorization Code)'를 함께 보내줍니다. | |||
5. 우리 서비스의 백엔드 서버는 이 인증 코드를 사용하여, 구글 인증 서버에 '접근 토큰(Access Token)'을 요청합니다. | |||
6. 구글은 접근 토큰을 발급해주고, 우리 서비스는 이 토큰을 사용하여 구글의 리소스 서버로부터 사용자 정보를 가져와 로그인을 완료시킵니다. | |||
---- | |||
=== 💡 개발자 핵심 Point === | |||
* OAuth를 사용하면 사용자의 민감한 비밀번호를 우리 서비스에 직접 저장할 필요가 없어 보안성이 크게 향상됩니다. | |||
* "구글로 로그인", "카카오로 로그인"과 같은 기능을 구현하려면 OAuth 2.0 프로토콜에 대한 이해가 필수적입니다. | |||
* '''Access Token'''은 실제 리소스에 접근할 수 있는 열쇠이며, 수명이 짧습니다. '''Refresh Token'''은 Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용하는 토큰으로, 수명이 더 깁니다. | |||
2. | |||
2025년 9월 6일 (토) 05:05 기준 최신판
🔐 OAuth
OAuth는 인터넷 사용자들이 비밀번호를 직접 제공하지 않고도, 다른 웹사이트나 애플리케이션의 자신의 정보에 대한 접근 권한을 안전하게 부여할 수 있는 개방형 표준 프로토콜입니다. 주로 소셜 로그인(Social Login) 기능에서 널리 사용됩니다.
OAuth는 '인증(Authentication)'이 아닌 허가(Authorization)를 위한 프로토콜입니다. 즉, "당신이 누구인지"를 증명하는 것이 아니라, "당신이 가진 특정 리소스에 접근해도 좋다"고 허락해주는 역할을 합니다.
👥 OAuth의 주요 역할자
- 리소스 소유자 (Resource Owner) : 사용자 본인. 자신의 정보에 대한 접근 권한을 가집니다.
- 클라이언트 (Client) : 리소스 소유자를 대신하여 보호된 리소스에 접근하려는 애플리케이션. (예: 우리가 개발하는 웹/앱 서비스)
- 인증 서버 (Authorization Server) : 리소스 소유자를 인증하고, 클라이언트에게 접근 토큰(Access Token)을 발급해주는 서버. (예: 구글, 카카오의 인증 서버)
- 리소스 서버 (Resource Server) : 보호된 리소스를 호스팅하는 서버. (예: 구글의 사용자 정보 API, 카카오의 메시지 API)
⚙️ OAuth 2.0 동작 방식 (Authorization Code Grant)
가장 일반적인 소셜 로그인 시나리오입니다.
1. 사용자가 우리 서비스에서 "구글로 로그인" 버튼을 클릭합니다. 2. 우리 서비스(클라이언트)는 사용자를 구글(인증 서버)의 로그인 페이지로 리디렉션시킵니다. 3. 사용자는 구글에 아이디/비밀번호를 입력하고, 우리 서비스에 정보 제공을 동의합니다. 4. 구글은 사용자를 우리 서비스로 다시 리디렉션시키면서, 임시 '인증 코드(Authorization Code)'를 함께 보내줍니다. 5. 우리 서비스의 백엔드 서버는 이 인증 코드를 사용하여, 구글 인증 서버에 '접근 토큰(Access Token)'을 요청합니다. 6. 구글은 접근 토큰을 발급해주고, 우리 서비스는 이 토큰을 사용하여 구글의 리소스 서버로부터 사용자 정보를 가져와 로그인을 완료시킵니다.
💡 개발자 핵심 Point
- OAuth를 사용하면 사용자의 민감한 비밀번호를 우리 서비스에 직접 저장할 필요가 없어 보안성이 크게 향상됩니다.
- "구글로 로그인", "카카오로 로그인"과 같은 기능을 구현하려면 OAuth 2.0 프로토콜에 대한 이해가 필수적입니다.
- Access Token은 실제 리소스에 접근할 수 있는 열쇠이며, 수명이 짧습니다. Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용하는 토큰으로, 수명이 더 깁니다.
