1. 기본 개념
용어 | 의미 |
Authentication | 인증. 로그인 등으로 누구인지 확인하는 것 |
Authorization | 인가. 권한을 주는 것, 즉 접근 허락 여부 결정 |
Access Token | 자원 접근용 토큰. 일정 시간만 유효함 |
Refresh Token | Access Token이 만료됐을 때 새로 발급 받는 데 사용하는 토큰 |
인증과 인가의 차이점
- 인증은 누구인지 확인하는 것
- 인가는 확인된 사람한테 권한을 부여하는 것
2. OAuth2의 4가지 역할
역할 | 설명 |
Resource Owner | 자원 소유자 = 사용자 |
Client | 자원에 접근하려는 앱 또는 프론트 |
Resource Server | 실제 데이터를 갖고 있는 서버 |
Authorization Server | 인증/인가를 처리하고 토큰 발급하는 서버 |
OAuth 2.0 역할을 너(사용자) 기준으로 쉽게 설명하면:
역할 | 비유 | 설명 |
Resource Owner | 너 자신 | 보호된 데이터를 갖고 있는 사람 (예: 너의 구글 캘린더, 카카오 사진) |
Client | 네가 사용하려는 앱 | 데이터를 대신 요청하는 앱 (예: 네가 쓰는 일정 관리 앱, 채팅 백업 앱) |
Resource Server | 구글/카카오 등 데이터 저장소 | 실제로 너의 데이터를 보관하고 있는 서버 (예: 구글 캘린더, 카카오톡 서버) |
Authorization Server | 구글/카카오 로그인 서버 | 너를 로그인시키고, 접근 권한을 확인하고, 토큰을 발급하는 서버 |
3. 4가지 권한 부여 방식
① Authorization Code Grant
가장 많이 쓰임 (보안 좋음, 권장 방식)
- 누가: 일반적인 웹/앱 서비스
- 어떻게:
- 사용자 로그인 → 코드(code) 발급
- 클라이언트가 이 코드로 Access Token 받음
- 장점: Refresh Token 사용 가능
- 보안: 매우 높음
[Client] → 인증 요청 → [Auth Server] → 로그인 → code 받음 [Client] → code 제출 → Access Token + Refresh Token 받음
🔒 정리
너: "앱아, 나 카카오로 로그인할게!"앱: "좋아. 카카오야, 얘가 로그인했다는데, 이 코드 좀 확인해줘."카카오: "응, 맞는 코드니까 이 Access Token 줌"앱: "이걸로 얘 정보 좀 줘봐"카카오: "ㅇㅇ 이 사람 정보는 이거야"앱: "로그인 완료!"
② Implicit Grant
브라우저 기반 앱용 (보안 낮음)
- 누가: JS 앱, 싱글 페이지 앱 (SPA)
- 어떻게:
- 로그인 후 바로 Access Token 발급 (코드 없음)
- 단점: Refresh Token 사용 불가, URL에 노출됨
- 보안: 낮음 → 요즘은 잘 안 씀
[Client] → 인증 요청 (response_type=token) → Access Token 바로 받음
🔒 정리
너: "앱아, 나 카카오로 로그인할래"앱: "오키, 카카오 로그인 페이지 띄울게"너: (로그인 완료)카카오: "여기 Access Token 바로 줄게!"앱: "오케이! 이걸로 사용자 정보 요청해야지!"
③ Resource Owner Password Credentials Grant
자체 서비스에서만 사용 (간단하지만 위험)
- 누가: 내 앱, 내 유저만 쓰는 상황
- 어떻게:
- 유저 ID/PW를 클라이언트가 직접 받아서 서버에 전달
- 장점: 구현 간단
- 단점: ID/PW 노출 위험
- 보안: 중간
- 사용 조건: 리소스 서버와 클라이언트가 같은 회사/시스템일 때만
username/password 직접 제출 → Access Token 받음
🔒 정리
너: "앱아, 나 로그인할게. 여기 내 아이디랑 비밀번호!"
앱: "오케이, 그거 그대로 로그인 서버에 보낼게"
앱 → 로그인 서버: "얘가 이 아이디랑 비번으로 로그인하려는데 맞음?"
로그인 서버: "응, 맞아. 그럼 Access Token 줄게"
앱: "좋아! 이제 이 토큰으로 사용자 정보 요청하자"
리소스 서버: "토큰 확인 완료. 여기 사용자 정보!"
④ Client Credentials Grant
서버 간 통신용 (유저 없음)
- 누가: 백엔드 서비스 대 백엔드 서비스
- 어떻게:
- client_id + client_secret만으로 Access Token 발급
- 특징: 유저가 아예 없음, Refresh Token도 없음
- 보안: 보관만 잘하면 안전
[Client] → client_id + secret 제출 → Access Token 받음
🔒 정리
백엔드 서버: "안녕, 나 클라이언트야. 내 client_id랑 secret 줄게"
인증 서버: "ㅇㅋ, 너 신원 확인됨. Access Token 줄게"
백엔드 서버: "고마워! 이걸로 내가 관리 중인 자원에 접근할게"
리소스 서버: "토큰 유효함. 요청한 데이터 여기 있음"
4. 중요 파라미터 정리
파라미터 | 설명 |
client_id / client_secret | 클라이언트 앱을 식별하는 키쌍 |
redirect_uri | 인증 후 돌아올 주소 |
response_type | code or token (방식 선택) |
grant_type | authorization_code , password , client_credentials 등 |
state | CSRF 방지용 임의값 |
code | Authorization Code 방식에서 받는 코드 |
token_type | 보통 Bearer |
expires_in | 토큰 유효시간 (초) |
✅ 중요 파라미터 쉽게 정리
파라미터 | 쉬운 설명 |
client_id / client_secret | 앱을 구별하는 아이디와 비밀번호 같은 거. 카카오에 "나 이 앱이야!"라고 말할 때 필요함 |
redirect_uri | 로그인 끝나고 돌아갈 주소. 토큰이나 코드를 이 주소로 보내줌 |
response_type | 어떤 방식으로 로그인할 건지 말해줌
예: code 면 Authorization Code 방식,
token 이면 Implicit 방식 |
grant_type | 토큰을 요청할 때 쓰는 승인 방식 종류예: authorization_code , password , client_credentials |
state | 로그인 과정 중 위조 방지용 랜덤 값. 요청 보낼 때 같이 넣고, 응답에서도 똑같이 받아야 함 |
code | Authorization Code 방식에서 로그인 성공 시 받는 승인 코드. 이걸로 Access Token을 받아옴 |
token_type | 토큰의 종류. 대부분 Bearer 타입으로, "내가 이 토큰 있어"라고 자격 증명할 때 씀 |
expires_in | Access Token이 얼마나 오래 유효한지 (초 단위) |
5. Authorization 헤더 예시
Access Token 요청 시
Authorization
헤더는 다음과 같이 보냄:Authorization: Basic base64(client_id:client_secret)
Share article