[OAuth2] 소셜 로그인; 인증을 위한 개방형 표준 프로토콜

Naver, Kakao 로그인 등 사용자 인증 기능을 제공하는
인증 및 권한 부여 프로토콜

 

 

 

프로토콜에는 여러가지 종류가 존재하지만 Kakao, Naver API를 이용한 로그인을 공부했기 때문에

이와 관련된 OAuth2 프로토콜에 대해서 공부해보고자 한다.

 

 

---

 

OAuth2(Open Authorization 2.0)란?

 

1. 사용자들이 비밀번호를 제공하지 않고, 다른 웹사이트 상의 자신의 정보에 대해 웹사이트에 접근 권한을 부여할 수 있는 수단

 

2. 접근 위임을 위한 개방형 표준

 

3. 책임을 Third-Party Applicaiton(google, kakao, naver 등)에 위임

: 정보 관리에 대한 책임 뿐만 아니라 부여받은 접근 권한을 통해 Third-Party에서 가지고 있는 사용자의 리소스 조회 등의 기능을 수행

 

 

*Third-Party란?

: Third-Party는 다양한 분야에서의 의미를 가지고 있는데, 프로그래밍에서의 서드파티는 프로그래밍을 도와주는 플러그인이나 라이브러리, 프레임워크 등을 만드는 회사를 의미함 (ex. naver, kakao, google 등)

: 제3자가 중간 다리 역할로서 도움을 주는 것

: 즉, 플러그인, 라이브러리, 프레임워크가 밀키트라면 우리는 이것을 조리만 하면 되는 것을 말함

 

---

 

OAuth2는 아래의 세 가지 주체간의 상호작용의 정의하는데, 어떤 주체들이 있는지 살펴본 다음 동작을 보고자 한다.

 

OAuth2를 구성하는 역할

 

 

1. Resource Owner

: 리소스 소유자

: 리소스(자원)에 대한 액세스를 허용 또는 거부할 수 있는 주체자

 

2. Client

: 자원에 액세스 하려는 애플리케이션 또는 서비스로 보통 우리가 개발하려는 서비스를 의미

: 리소스 소유자를 대신해 액세스 토큰을 얻기 위해 인사 서버에 요청

* Server 입장에서는 개발하려는 서비스가 클라이언트이기 때문에 다음과 같은 이름이 붙은 것으로 Resource Owner와 헷갈리면 안됨

 

3. Authorization & Resource Server

: Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버

: Resource Server는 third-party를 의미 (리소스를 가지고 있는 서버)

 

 

그렇다면 상호작용을 할 때에는 어떤 것을 하고, 어떤 것을 주고 받는 것일까?

이를 설명하기 위해 선행되어야 하는 용어들에 대해 알아보고자 한다.

 

OAuth2 주요 용어

 

1. Authentication

: 인증, 접근 자격이 있는지 검증하는 단계

 

2. Authorization

: 인가, 자원에 접근할 권한을 부여하는 것으로, 완료 시 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여

 

3. Access Token

: 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token

 

4. Refresh Token

: Access Token 만료 시 이를 갱신하기 위한 용도로 사용하는 Token으로 일반적으로 Access Token 보다 만료 기간이 긺

 

 

---

 

이제 기본적인 용어들에 대해 알았으니, OAuth2가 어떻게 동작하는지 살펴보고자 한다.

(Kakao, Naver API를 이용한 로그인 블로그를 보고 왔거나 알고 있다면 동작 방식이 크게 어렵지 않을 것이다.)

 

 

 

* Resource Owner는 사용자, Client는 웹사이트 라고 명시할 에정이다.

 

 

1~2. 로그인 요청

: 사용자가 로그인을 시도하면(로그인 요청을 보내면), 웹사이트에서는 Authorization Server로 자신의 Client_Id와 Redirect_URL 등을 매개변수로서 포함시켜 요청을 보내게 된다.

 

 

3~4. 로그인 페이지 제공

: 회원이 아니라면 동의여부를 받는 페이지가, 회원이었다면 로그인을 하는 페이지가 제공되며, ID/PW를 입력해 인증을 진행한다.

 

5~6. Authorization Code 발급 및 Redirect URI로 이동

: ID/PW를 이용해 인증에 성공할 경우에는 인가코드를 제공받게 되고, 인가코드를 포함해 Redirect_URI로 이동하게 된다.

이 인가 코드는 Access Token을 발급받기 위한 임시 코드로 수명이 짧다.

 

7~8. Access Token 발급

: 발급받은 인가 코드를 사용해 Authorization Server에 전달하고 Access Token을 발급받는데, 이 토큰은 Resources Server에서 사용자의 리소스에 접근하기 위해서 사용된다. 따라서 이는 유출되면 안되고, 제 3자가 가로채지 못하도록 https를 통해서만 사용된다.

: 주로 인가 코드와 함께 Client_Id, Redirect_URI, code, grant_type등을 같이 보내게 되는데 이는 어떤 Authorization Server를 이용하는지에 따라 조금씩 차이가 존재한다.

 

9. 로그인 성공

: Access Token까지 발급을 받는다면 사용자는 로그인에 성공하였음을 알게된다.

 

10~13. Access Token을 이용한 리소스 접근

: 사용자가 Resource Server의 리소스가 필요한 기능을 웹사이트에 요청하고, 웹사이트는 로그인 과정에서 발급받은 Access Token을 이용해 사용해 리소스를 받아 사용자에게 서비스를 제공하게 되는 것이다.

 

 

 

여기서 왜 Access Token을 바로 발급받는 것이 아닌

Authorization Code를 발급받고 그 코드를 이용해 Access Token을 발급받는가?에 대한 의문이 든다.

 

 

이는 이 전에 블로깅했던 Redirect 시 데이터를 전달하는 방법에 대해 문제가 존재하기 때문이다.

2023.11.12 - [공부 자료/자바스크립트[JS]] - [Springframework] Redirect 시 데이터 전달

[Springframework] Redirect 시 데이터 전달

 

 

Access Token은 매우 민감한 데이터로 노출되면 안되는 토큰이다.

그렇기 때문에 이를 방지하기 위해 Authorization Code를 발급받아 사용하는 것인데, 사용 과정은 아래와 같다.

 

 

1. Redirect URI를 프론트엔드 주소로 설정해 Authorization Code를 전달

2. Authorization Code를 프론트가 백엔드로 전달

3. 백엔드는 Authorization Server의 엔드포인트로 Access Token을 요청

 

 

즉, Authorization Code를 발급받는 과정이 생략된다면 Authorization Server가 Access Token을 웹사이트에 전달하기 위해서 Redirect URI를 통해 전달해야 하고 이는 토큰이 노출될 수 있게 되는 것이다.

 

 

---

 

다시 본론으로 돌아와서 OAuth2의 동작 방식에 대해서 알아보았는데,

권한을 부여하는 방식도 여러가지가 있다.

(위에서 알아본 방식은 Authorization Code를 사용한 권한 부여 승인 코드 방식이다.)

 

1. Authorization Code Grant

: 권한 부여 승인 코드 방식

: 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식

: 웹사이트가 사용자를 대신해 특정 자원에 접근을 요청할 때 사용되는 방식

 

2. Implicit Grant

: 암묵적 승인 방식

: 자격 증명을 안전하게 저장하기 힘든 웹사이트에게 최적화된 방식

: 인가 코드 없이 Access Token이 바로 발급

: Refresh Token 사용이 불가능

 

3. Resource Owner Password Credentials Grant

: 자원 소유자 자격증명 승인 방식

: username, password로 Access Token을 발급

 

4. Client Credentials Grant 

: 클라이언트 자격증명 승인 방식

: 웹사이트의 자격증명만으로 Access Token을 획득

: 자격 증명을 안전하게 보관할 수 있는 웹사이트에서만 사용되어야 하며, Refresh Token 사용이 불가능

 

 

---

 

용어들이 유사한 것이 많고, 특히 동작 방식을 이해하는데 어려울 수 있지만

많이 사용하는 것인 만큼 확실하게 이해하고 넘어가면 좋을 것 같다.