로그인을 할 때 소셜 로그인을 선호하시나요 직접 회원가입을 선호하시나요?
저는 소셜 로그인을 더 선호합니다. 2020년 자료이긴 하지만 소비자연맹이 조사한 결과에 따르면 64% 정도의 사용자가 소셜로그인을 주로 사용한다고 대답했네요.
이번 소셜 로그인 파트에서는 가장 많이 사용되는 top 3의 소셜 로그인을 구현하는 방법을 정리해 볼 예정입니다. 오늘은 개발 전 OAuth란 무엇인지 알아보고, 어떤 식으로 동작하는지 이해해볼 것입니다. 구현 전 4챕터를 확인하시는 걸 추천드립니다.
목차는 아래와 같습니다.
1. OAuth란?
2. OAuth 탄생 이유
3. OAuth와 OAuth 2.0의 차이점
4. OAuth 2.0 표준 동작 방식 (OAuth 2.1 간단 알아보기)
OAuth란?
OAuth는 액세스 위임을 위한 개방형 표준 인가 프로토콜입니다. 복잡하게 보일 수 있지만 하나 하나 뜻을 생각해본다면 쉽게 이해할 수 있습니다.
프로토콜이란 정보를 교환할 때 따르는 규칙인데요. 즉, OAuth란 인증 위임 시 필요한 규칙 모음집이라고 쉽게 이해할 수 있습니다.
IETF(국제 인터넷 표준화 기구)에서 만들었으며 공식 문서를 기준으로 더 자세히 알아보도록 합시다.
OAuth 탄생 이유
생각해보면 직접 회원가입은 매우 위험한 방식입니다.
저희는 직접 회원가입을 할 때 회원가입 시 사용되는 정보들이 어느 곳에서 사용되는지도 모르고 정보를 입력하곤 합니다.
그런데 그 사이트가 해킹되거나, 서비스의 주인이 나쁜 마음을 먹으면 어떻게 될까요? 상상만해도 무섭습니다.
이런 불안함을 잠재워줄 수 있는 게 바로 소셜 로그인입니다.
모두가 아는 서비스에서 인증을 대신 진행해주기 때문에 보안이 강화되고 편리합니다. 사이트에서는 저희가 제공한 정보만 가져갈 수 있기 때문에 내 개인 정보가 어디에 쓰일지에 대한 불안함도 없어지죠.
OAuth가 정의되지 않았을 시절 구글은 AuthSub, 야후는 BBAuth 등 각자 회사가 개발한 소셜 로그인 방법을 사용하였습니다. 하지만 방식들이 표준화 되어있지 않았기 때문에 개발과 유지보수가 아주 힘들었습니다. 😭
표준이 필요하다는 의견들이 커지며 2007년에 OAuth1.0이 비공식으로 만들어졌고, OAuth 1.0은 2010년 IETF에 의해 표준 프로토콜이 되었습니다.
OAuth1.0과 OAuth 2.0의 차이점
OAuth 1.0은 사실 인증 방식이 매우 복잡했습니다. 보안을 위해 요청마다 암호화 서명을 생성해야했고 토큰 갱신 기능도 없었기 때문에 매번 토큰을 새로 발급받아야 했습니다. 더불어 보안을 위해 암호화 서명을 강제했지만 HTTPS 사용은 필수가 아니었기에 취약점도 존재하였습니다. (OAuth 1.0은 모바일 환경에서의 사용도 어려움이 있었습니다.)
이런 단점들이 있었기 때문에 OAuth 1.0이 나오고 2년 뒤 개선된 OAuth 2.0이 발표되었습니다.
OAuth 2.0에서는 많은 것들이 바뀌었는데, 가장 큰 부분은 인증 방식의 다양화와 간편화입니다.
앞서 말했듯 1.0에서는 암호화 서명이 필수적이었지만, OAuth 2.0에서는 단순 문자열 토큰을 사용하여 훨씬 간편한 요청이 가능해졌습니다. Refersh Token도 도입하여 토큰을 재발급할 수 있어 더 편리해지기도 했습니다. 달라진 점을 간단히 정리해볼까요?
1) 토큰 재발급이 가능하다.
2) 여러 인증 흐름을 지원한다. (ex 서버 로그인, 클라이언트 로그인)
3) 다양한 환경에서 사용이 가능해졌다.
또한 1.0의 취약점을 보완하기 위하여 인증 서버와 리소스 서버의 HTTPS 사용이 필수가 되었으니 개발 시 알아두셔야 합니다. ⚒️ HTTPS의 필수 사용 뿐만 아니라 PKCE(Proof Key for Code Exchange)같은 보안 강화 기능도 추가되어 더 보안에 신경쓸 수 있게 되었습니다. PKCE같은 경우 PKCE를 필수로 채택한 OAuth 2.1이 현재 활발히 논의되는 중입니다.
OAuth 2.0 표준 동작 방식
이제 표준 동작 방식을 정리해보려고 합니다. OAuth 2.1이 아닌 2.0으로 정리를 하는 이유는 2.1이 아직 공식으로 발표되지 않았기 때문입니다. 아래에 간단한 차이점을 정리해두었으니 참고해주세요.
인증 흐름 정리 전 알아야 할 '역할'들을 먼저 정리해보겠습니다.
1) Resource Owner
리소스 소유자로 사용자의 계정을 말합니다.
2) Client
사용자의 권한을 위임받아 보호된 리소스에 접근합니다. Authorization Server에 접근하는 주체로 저희 서비스의 앱, 웹, 서버 등이 될 수 있습니다.
3) Authorization Server
클라이언트에게 Authorization Code 또는 Token을 발급하는 서버로 Google이나 FaceBook 등을 생각하시면 됩니다.
4) Resource Server
데이터를 제공하는 서버로 Authorization Server에서 발급해준 Token을 통하여 접근이 가능합니다. Google의 리소스를 응답해주는 서버를 생각하실 수 있습니다. 개념적으로 구분되며 Authorization Server와 동일한 서버에서 동작할 수도 있습니다.
앞서 말했다시피 OAuth 2.0은 여러 인증 흐름을 지원합니다. 오늘은 가장 권장하는 방식인 Authorization Code Flow를 알아보겠습니다.
아래 사진으로 인증 흐름을 정리해보았는데요. authorization server와 resource server는 통합하여 그려보았습니다. 차근차근 알아볼까요?
저희의 서비스에서 사용자가 로그인 버튼을 동작하면 서비스는 인증 서버의 로그인 페이지로 리다이렉트 시킵니다. 저희가 아는 그 로그인 페이지가 맞습니다.
이때 client_id, redirect_uri, response_type을 포함하여 요청을 보내게 됩니다. 이는 소셜 로그인을 제공해주는 서비스에서 확인이 가능한 정보들로 요청을 식별하기 위하여 쓰입니다.
그 후 사용자가 정상적으로 동의와 로그인을 수행하면 1) 저희가 설정한 redirect uri로 code가 넘어가며, 2) code를 통하여 인가 서버에서 토큰을 받아온 후 3) 토큰을 통해 사용자 정보도 받아올 수 있습니다. 그 후에는 저희 서버에서 토큰을 각자 발급하여 넘겨주면 간단히 OAuth 구현이 끝나게 됩니다.
사실 실제 구현을 할 때 reidrect uri를 서비스 서버로 설정할 것인지, 서비스 클라이언트로 설정할 것인지 결정하는 것이 무척 어려웠는데요. 저는 서버로 해야한다고 생각했지만 클라이언트분은 클라이언트로 해야한다고 하셔서 결정하는데 시간이 오래 걸렸었습니다. 이건 나중에 구현 편에 따로 이야기해보도록 하겠습니다.
OAuth 2.1에서는 권장하지 않는 인증 흐름 몇 가지가 삭제되고, PKCE가 필수가 되며 Redirect URI를 정확히 일치시키는 것을 요구합니다. 아직 공식은 아니지만 몇몇 서비스에서는 2.1 방식 중 몇 가지를 채택하고 있기도 하니 알아두시면 좋습니다. ✨
마무리하며
OAuth가 무엇인지에 대해 알아보고 표준 동작 방식도 정리해보았습니다. 기능 개발전 표준 동작 방식을 알아본다면 많은 도움이 되실 거라 생각합니다.
다음에는 카카오 OAuth 구현 방법으로 돌아오겠습니다. 🙋
'Spring' 카테고리의 다른 글
| Seed를 사용하여 Pagenation + Random에서 중복 없이 데이터 가져오는 방법 | ORDERBY RANDOM PostgreSQL seed (1) | 2025.03.16 |
|---|