next-auth 이용하기(1)-OAuth에 대해 알아보자
📌시작하며
지난 프로젝트에서는 firebase를 이용해 이메일 로그인을 구현했었다. 그 때 다음 프로젝트에서는 SNS 로그인을 구현해봐야지! 다짐했었고, 구현 중에 있다.😎
next-auth를 쓰면 정말 간단하게 다양한 제공자의 로그인 기능을 구현할 수 있는데, 구현 방법만 쭉 정리하기 보다는 OAuth 자체를 정리하면 프로젝트의 흐름을 더 잘 이해할 수 있을 것 같아서, 이렇게 먼저 자주 나오는 개념을 정리하고자 한다.
(개인적으로 공부한 내용을 정리하는 거라 잘못된 내용이 있을 수도 있다..!)
✅OAuth
먼저, OAuth가 무엇일까?
OAuth(“Open Authorization”)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. [출처: 위키백과(OAuth)]
일반적으로 로그인 할 경우 사용자는 직접 자신의 정보를 제공하지만, 보안상의 문제가 발생할 수 있지만, OAuth를 이용하면 외부 계정을 기반으로 간편하게 회원가입/로그인을 할 수 있다.
그러니까, 흔히 만나게 되는 ‘SNS로 로그인하세요’ 같은 것들이다. (네이버, 카카오, 구글과 같은!) 덕분에 우리는 훨씬 편리하고 간편하게 웹사이트에 가입하거나, 사용자를 관리할 수 있다!
✅OAuth 이해를 위한 용어
| 용어 | 설명 |
|---|---|
| 클라이언트 Client | 앱이라고도 한다. 모바일 기기에서 실행되는 앱이거나 전통적인 웹 앱일 수 있으며, 이 앱은 리소스 소유자를 대신해 리소스 서버로부터 보호된 asset에 대해 요청한다. |
| 리소스 소유자 Resource owner | 엔드(최종) 사용자라고도 한다. 일반적으로 보호된 리소스에 액세스 권한을 부여할 수 있는 사람/주체다. |
| 리소스 서버 Resource server | Facebook, Google 또는 Twitter와 같은 서비스의 파트너 서비스라고 볼 수 있다. OAuth 토큰 검증이 필요할 때 API 요청을 처리한다. |
| 인가 서버 Authorization server | OAuth 2.0 사양을 준수하여 구현된 서버로, 인가 부여를 검증하고 앱이 리소스 서버의 사용자 데이터에 액세스할 수 있도록 액세스 토큰을 발급한다. |
| 인가 부여 Authorization grant | 앱이 엔드(최종) 사용자를 대신하여 액세스 토큰을 검색할 수 있는 권한을 제공한다. |
| 액세스 토큰 Access token | 클라이언트에게 발급된 권한을 나타내는 문자열. |
| 리프레쉬 토큰 Refresh token | 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 얻기 위해 사용되며, 보안적으로 중요한 역할을 한다. |
| 보호된 리소스 Protected resource | 리소스 소유자가 소유한 데이터로, 개인정보와 같은 민감한 데이터를 말한다. |
✅OAuth 로그인 처리 과정
전체 과정은 다음과 같이 작동한다. 추가적으로, 페이코 로그인 개발자 센터에 정리되어있는 OAuth 2.0의 흐름이 한눈에 알아보기 쉬워서 헷갈릴 때 마다 보면 좋을 것 같다.
그럼 다시 정리해보자.
- Resource Owner가 Client로의 로그인을 시도한다.
- Client는 Resource Owner와 관련된 정보가 없으므로, Resource Owner의 정보를 가지고 있는 Authorization Server에 로그인 요청을 전달한다.
- Authorization Server는 요청을 받고, Resource Owner가 로그인할 수 있도록 팝업창과 같은 페이지를 표시한다.
- Resource Owner는 아이디와 비밀번호를 입력한다.
- Authorization Server는 아이디와 비밀번호가 일치하는지 확인하고, 인증된 Resource Owner에게 Authorization Code를 발급한다.
- Resource Owner는 발급받은 Authorization Code를 Client에게 전달한다.
- Client는 해당 코드와 Client ID, Client Secret을 사용하여 Access Token을 요청한다.
- Authorization Server는 요청을 확인하고, Access Token을 Client에게 전달한다.
- 로그인이 완료되었다! 😎
- Resource Owner가 서비스를 요청한다. (ex: 프로필 정보 조회 등)
- Client는 요청을 확인하고, 사용자의 정보를 가지고 있는 Resource Server에 Access Token을 사용하여 API를 호출한다.
- Resource Server는 Access Token을 검증하고, 요청된 리소스를 제공한다.
- Client는 사용자에게 요청된 리소스를 제공한다.
➡️덧붙이는 글
이렇게 쓰니까 엄청 길어보이는데😅 나름대로 이해해본 걸 덧붙이자면 이런거다.
정보의 주체(내 웹을 사용하고자 하는 사용자) = resource owner
user의 정보를 담고 있는 서버 = resource server
내가 만든 웹 = client
인가해주는(사용자 권한 확인하는) 서버 = authorization server
당연히 내가 만든 웹은 사용자의 정보를 가지고 있지 않기 때문에 로그인 요청이 들어와도 처리가 불가하므로, 사용자 정보를 가지고 인가 처리를 해줄 수 있는 서버에 부탁할 수 밖에 없다.
또한 사용자가 어떤 요청을 했을 때, 관련된 정보는 여전히 내가 만든 웹이 가지고 있지 않으므로 정보를 가지고 있는 resource server에 요청할 수 밖에 없는 거다.
📩마무리
이렇게 정리하고 나니 OAuth가 어떤 과정으로 사용자에게 권한을 부여하는지, 단순히 구현이 아니라 flow를 이해할 수 있을 것 같아 뿌듯하다.😎