OAuth란?

 🔗 [Knowledge/🌐 Web 지식] - 인증 / 인가

 🔗  [Knowledge/🌐 Web 지식] - 세션(Session) & 토큰(JWT)

*위 글에 이어 작성하는 글입니다.

 

이전까지 로그인에 관한 인증/ 인가의 큰 개념과 이 인증이 어떻게 유지되는지에 대해 알아보았다. 그렇다면 이제 남은 것은 무엇? 

바로 '소셜 로그인'이다. 

 

소셜 로그인에 관한 키워드를 검색해 보니 OAuth (2.0)라는 키워드가 제일 많이 언급되었다.

아직까진 아무런 정보가 없다.

 

OAuth란 정확히 무엇인지 제대로 알아보자!

---

OAuth란?

OAuth는 Open Authorization의 약자로, 제삼자 애플리케이션이 사용자 리소스에 대한 접근 권한을 얻을 수 있게 해주는
표준 인증 프로토콜이다. 

   * 우선 현대 애플리케이션은 OAuth 2.0 버전을 사용하고 있다.
    🚦OAuth 1.0에서 2.0으로 업그레이드될 때 어떤 이슈들이 개선되었는지, OAuth 개념을 확실히 이해한 후 알아보자!

 

즉, 내 프로젝트 사이트인 이음새에 적용 후, 정리하자면 다음과 같다.

OAuth는 나의 웹사이트(이음새)가 사용자의 구글 계정 정보에 접근할 때,

사용자가 구글 비밀번호를 이음새에 직접 알려주지 않고도 안전하게 필요한 정보를 공유할 수 있게 해주는 방식.

• 제삼자 애플리케이션 : 이음새
• 리소스 서버: 구글 

그렇다면, 왜 직접 알려주지 않는 걸까? (나를 못 믿나?ㅋ)  OAuth를 사용하지 않고, 직접 알려주면 어떠한 문제가 생길까?

 

OAuth 사용 전후

OAuth 사용 이전 

OAuth를 사용하지 않고 직접적인 정보를 유저가 우리에게 제공하여 직접 로그인을 하는 방식이다.

다음과 같은 문제점들이 있을 수 있다.

 

1. 유저 입장 :

   내 구글 계정으로 내 구글 포토나, 구글 드라이브의 파일들까지 다 접근하면 어떡하지?

 

2. 이음새 입장 : 

   우리 자체 회원가입 정보도 관리만으로 힘든데 구글 ID/PW 까지 어떻게 관리하지?

 

3. 구글 입장 :

 실컷 비싸고 뛰어난 개발자들 써서, 보안 철저히 해놨는데 이런 식으로 시스템이 우회된다면 무슨 의미가 있지?

 

 

이처럼 OAuth를 사용하지 않고, 이음새 사이트가 직접 관리하는 경우 모두에게 좋지 않은 문제점들이 생겨난다.

 

 

이음새가 구글 ID/PW를 요청한 이유는 무엇일까? 이 정보에 접근하려는 목적은 무엇이었을까?

소셜 로그인의 경우, 사용자의 편의를 위한 것이 주된 목적이다.
이를 통해 구글에서 제공하는 사용자의 이메일, 이름 등의 기본 정보를 쉽게 가져올 수 있다.
이는 해당 리소스에 대한 접근 권한을 획득하기 위해서이며, 일종의 인가 과정을 거치게 된다.

즉, 인가를 받기 위함이라는 것이다. 그렇다면,  인증은 사용자가 직접 수행하고, 인가는 이음새에서 받아오면 되는 것이 아닐까?
바로 이러한 과정이 OAuth의 핵심이다.

OAuth 사용 이후

 

유저가 구글에 자신의 ID와 비밀번호를 제공하여 직접 인증을 수행한다.
이때 이음새(서비스)는 구글 ID/PW에 전혀 관여하지 않습니다.

 

구글에서 유저의 인증이 유효하다고 판단하면, 이음새에게 유저의 정보를 접근할 수 있는 권한을 부여한다.
이 권한을 통해 이음새는 사용자의 기본 정보 (이메일, 이름 등)에 접근할 수 있게 됩니다.

💡 즉 인증은 유저가 직접, 권한은 서비스에게!

---

OAuth의 역할 

 

• 유저가 자신의 데이터를 클라이언트(이음새)에 제공하기 위해, 구글과 같은 권한 서버에서 인증을 수행.
• 클라이언트는 권한을 받아 유저의 데이터에 접근 가능.
• 구글은 인증과 권한 부여를 수행하며, 인가된 클라이언트에게 리소스를 제공.

---

OAuth Setting

 

 

 

OAuth 2.0 인증을 위해 클라이언트 ID와 클라이언트 비밀번호는 애플리케이션이
Google 인증 서버와 통신할 때 필요한 고유한 식별자와 비밀 키이다.
이 정보는 OAuth 인증 과정에서 애플리케이션이 누구인지 증명하는 데 사용된다.

또한, 리디렉션 URI는 인증이 완료된 후 사용자가 돌아갈 애플리케이션의 URL을 지정하는 중요한 요소이다.
구글은 이 URI로 인증 코드를 보내고, 애플리케이션은 이를 통해 최종적으로 액세스 토큰을 받아 사용자 데이터를 접근할 수 있다.

---

OAuth Flow(승인-접근 흐름)

 

Authorization Grant (권한 부여)

 

 

 

1. 사용자(Resource Owner)가 클라이언트(Client)에게 OAuth 요청을 합니다.

2. 클라이언트는 사용자에게 로그인 페이지 URL을 제공

/oauth2/authorization/google

3. 사용자는 인증 서버(Authorization Server)의 로그인 페이지에 접근한다.
4. 인증 서버는 로그인 페이지를 사용자에게 보여준다.

 

5. 사용자가 인증을 완료하고, 클라이언트에게 권한을 부여한다.

6. 인증 서버는 클라이언트에게 인증 코드를 전달한다.

http://localhost:8080/login/oauth2/code/google //리다이렉트 url을 통해 전달

7. 클라이언트는 이 인증 코드를 사용해 인증 서버에 액세스 토큰을 요청한다.

8. 인증 서버는 클라이언트에게 액세스 토큰(및 리프레시 토큰)을 발급한다.

사용자가 인증 서버에서 직접 인증하고, 클라이언트에게 권한을 부여한다. 이를 바탕으로 클라이언트는 액세스 토큰을 획득한다.

 

Using Resource(자원 이용)

 

1. 리소스 소유자(사용자)가 클라이언트에게 서비스를 요청한다.
2. 클라이언트는 이미 획득한 액세스 토큰을 사용해 인증 서버에 리소스를 요청한다.
3. 인증 서버는 액세스 토큰을 검증한 후, 요청된 리소스에 대한 접근을 허용하고 클라이언트에게 반환한다.

획득한 액세스 토큰을 사용하여 클라이언트는 인증 서버를 통해 사용자의 보호된 리소스에 안전하게 접근할 수 있다.

---

 

Spring Security + OAuth 

 

다음은 Spring Security + OAuth 적용시킨 파일 구조이다.

 

 

 

OAuth 2.0 로그인 흐름에서, CustomOAuth2 UserService는 Authorization Code로 Access Token을 받고,
이를 통해 사용자 정보를 소셜 제공자(Google, Naver) API에서 가져옵니다.

가져온 정보는 OAuth2 Response라는 공통 응답 객체로 처리되며, 각각 GoogleResponse, NaverResponse로 매핑됩니다.

CustomSuccessHandler는 로그인 성공 후 추가 작업을 처리하며,

최종적으로 사용자 인증이 완료되고 Spring Security와 통합되어 JWT 토큰이 생성된다.

인증은 사용자가 직접, 권한은 서비스가 안전하게 위임받는다!!

 

---

🙇‍♂️ 결론

OAuth에 대해 공부하면서 소셜 로그인 구현에 적용해 보았다.

주로 소셜 로그인을 위주로 학습했지만, 같은 원리가 Google 캘린더 API, Dropbox 파일 접근, GitHub 리포지토리 관리 등 다양한 서비스 연동에도 적용된다는 점을 인식하게 되었다.

이 과정에서 OAuth의 기본 흐름을 직접 프로젝트에 적용하고 코드의 동작 방식을 이해하는 데 중점을 두었다.

비록 많은 부분이 이미 정형화된 코드 구조를 따르지만, 이를 실제로 구현해 보면서 인증과 인가의 중요성,
특히 보안 측면의 핵심적인 역할을 깨달았다.

CORS(Cross-Origin Resource Sharing)와 같은 보안 설정이나 Spring Security의 내부 구조에 대한
깊이 있는 이해의 필요성을 느꼈다.
이러한 기술들이 OAuth와 어떻게 상호작용하며, 전체적인 보안 구조를 형성하는지에 대해 더 자세히 탐구할 계획이다.

로그인과 회원가입 기능을 직접 구현해 본 것은 매우 뿌듯했다. 앞으로의 프로젝트에서 더 폭넓게 활용할 수 있을 것 같아 기대된다!