웹 사이트를 이용하다 보면 Google, Facebook, Naver, Kakao 등등 외부 플랫폼을 사용하여 간단하게 회원가입 및 로그인을 할 수 있는 경우가 있다. 클릭 한 번으로 간편하게 로그인할 수 있을 뿐만 아니라, 소셜 플랫폼에서 지원하는 다양한 기능들을 사용할 수 있는 장점이 있습니다.
이때 사용되는 프로토콜이 OAuth 2.0 입니다.
OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜입니다.
1. OAuth 2.0 참여자
- Resource Server : 제어하고자 하는 자원을 갖고 있는 서버 ex) Facebook, Google
+ Authorization Server : 인증과 관련된 처리를 전담하는 서버 - Resource Owner : 자원의 소유자 ex) 홍길동
- Client : Resource Server에 접속해서 정보를 가져가는 클라이언트
2. Client 등록
Client가 Resource Server를 이용하기 위해서는 자신의 서비스를 등록함으로써 사전 승인을 받아야 합니다. 각 플랫폼의 개발자 사이트에 들어가서 등록을 합니다.
등록 절차를 통해 총 3가지 정보를 부여받습니다.
- Client ID : 클라이언트 웹 애플리케이션을 구별할 수 있는 식별자이며, 노출이 무방합니다.
- Client Secret : Client ID에 대한 비밀키로서, 절대 노출해서는 안 됩니다.
- Authorized redirect URL : Authorization Code를 전달받을 리다이렉트 주소입니다
scope는 Client가 Resource Server로부터 인가받은 권한의 범위입니다. ex) 이메일, 사용자 이름 등등
3. OAuth 2.0 작동 방식
- Resource Server에 client id값, 사용할 기능(Resource Server가 정해놓은 형식), 인증코드를 전달받을 redirect URI를 쿼리 파라미터로 넘긴다. ex) 버튼에 링크를 건다.
- Resource Owner가 버튼을 눌러서 Resource Server로 접속을 한다.
- Resource Server는 Resource Owner의 현재 로그인 여부를 파악한다. (로그인되어있지 않으면 로그인 화면을 띄운다.)
- Resource Owner는 로그인을 수행한다.
- 로그인이 완료되면 Resource Server는 비교 검증을 수행한다.
- 검증을 마치면 scope에 해당하는 권한을 Client에게 부여할 것인지 체크하는 필수, 선택 메시지를 전송하게 된다.
- 허용 버튼을 누른 정보만 Resource Server로 전송된다.
- Resource Server는 회원의 허용 정보를 수집한다.
4. Resource Server의 승인
- Resource Server는 Authorization Code를 회원에게 전송한다. 전송할 때 Header 값에 Location를 주는데, 이는 리다이렉션 명령에 해당한다.
- Resource Owner의 웹브라우저는 회원이 인식하지도 못할 만큼 은밀하게 주어진 주소로 이동한다.
Client는 이 주소를 바탕으로 Authorization Code를 알게 된다. - 이제 Client는 Resource Owner을 통하지 않고 Resource Server에 직접 접속한다. 지금까지 알아낸 정보와 Client_secret을 함께 보낸다. (카카오는 Client_secret가 필수가 아님.)
- Resource Server는 클라이언트가 넘긴 code와 client_id, client_secret, redirect_uri 4가지가 모두 일치하는지 확인하고 다음 단계로 넘어간다.
5. Access Token 발급
- Authorization code을 통해 인증을 마쳤으므로 Resource Server는 code값을 지워야 한다.
- 그 후 Resource Server는 AccessToken을 발급하고 Client에게 응답해 준다.
- Client는 AccessToken을 내부적으로 서버에 저장한다.
- Client는 AccessToken을 이용해 Resource Server에 있는 정보에 액세스 할 수 있습니다.
6.Refresh Token 발급
Access token은 수명이 있다.
수명이 끝난 token으로 API에 접속해도 API는 요청을 받지 않는다.
토큰을 다시 발급받을 때마다 사용자에게 인증과정을 처음부터 밟도록 하는 것은 적합하지 않다.
Access token의 수명이 다했을 때 새로운 access token을 발급받는 방법이 refresh token이다.
마치며 :
실제로 저도 소셜 로그인을 직접 구현해 보며 많이 알았고, 직접 각각의 플랫폼에 지침서를 보며 공부하면 좋을 거 같습니다!
참고 문헌 : https://opentutorials.org/course/3405
'WEB' 카테고리의 다른 글
Redis Lock 동시성 해결하기 (0) | 2024.05.01 |
---|---|
인터셉터와 리졸버 (0) | 2024.04.12 |
JWT 활용기 (0) | 2024.04.12 |
Oauth를 사용해 카카오 로그인 구현 (0) | 2024.04.12 |
리사이징 적용기 with Marvin (0) | 2024.03.14 |
Spring Cloud Config 도입기 (0) | 2024.03.08 |
JPA란 무엇일까? (0) | 2023.06.01 |
웹 서버와 웹 애플리케이션 서버 (0) | 2023.04.01 |