[OAuth] 1. OAuth 2.0의 핵심 개념과 권한 부여 방식 4가지

Jun 27, 2025

[OAuth] 1. OAuth 2.0의 핵심 개념과 권한 부여 방식 4가지

Contents

1. 기본 개념 2. OAuth2의 4가지 역할 3. 4가지 권한 부여 방식 4. 중요 파라미터 정리 5. Authorization 헤더 예시

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)

OAuth 2.0

[OAuth] 1. OAuth 2.0의 핵심 개념과 권한 부여 방식 4가지

백하림

Jun 27, 2025

Contents

1. 기본 개념 2. OAuth2의 4가지 역할 3. 4가지 권한 부여 방식 4. 중요 파라미터 정리 5. Authorization 헤더 예시

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)