[SpringBoot] OAuth 2.0 기반의 소셜 로그인 구현하기(1) - OAuth란?

출처 : https://okky.kr/

소셜 로그인이란 사용자가 자신의 소셜 미디어 계정(ex) 구글, 카카오, 페이스북 등)을 사용하여 웹 서비스에 로그인하는 방법입니다. 이를 통해 사용자는 새로운 계정을 만들 필요 없이, 소셜 미디어 플랫폼에서 제공되는 인증 정보를 사용하여 웹 서비스에 쉽게 로그인할 수 있습니다.

 

이번 포스팅에서는 Spring 프레임워크에서 지원하는 OAuth에 대해 알아보도록 하겠습니다.

✔️ OAuth란 ?

OAuth는 Open Authorization의 약자로, 사용자가 데이터에 대한 권한을 안전하게 제어하고 인증할 수 있도록 도와주는 오픈 표준 인증 프로토콜입니다. 사용자는 자원의 소유자에게 비밀번호를 제공하지 않고도 애플리케이션 혹은 서비스가 사용자의 자원에 접근할 수 있도록 허용합니다.

 

과거에는 각 애플리케이션 또는 서비스가 자체적으로 아이디와 비밀번호를 통해 사용자 인증을 진행하거나 구글, 야후, 아마존과 같은 회사들은 각각 고유한 인증 시스템을 구축하여 사용자 인증을 진행하였습니다. 각 회사의 인증 시스템을 사용하기 위해서는 사용자가 해당 서비스에 로그인할 때마다 서로 다른 인증 방법을 사용해야 했던 것이었죠.

 

이런 문제를 해결하기 위해 OAuth는 각 서비스의 인증 방식을 표준화하여, 사용자가 일관된 방식으로 인증을 할 수 있도록 합니다. OAuth를 사용함으로써 각 서비스는 사용자 인증을 위한 별도의 인증 시스템을 구현할 필요 없이, OAuth를 준수하고 있을 경우 표준화된 방식으로 사용자 인증을 처리할 수 있게 됩니다.

 

그렇다면, 처음으로 등장한 OAuth 1.0과 2012년에 출시된 OAuth 2.0에 어떤 차이점이 있는지 알아보도록 하겠습니다.

 

---

✔️ OAuth 1.0

OAuth 1.0은 이전 버전의 프로토콜로, 복잡한 과정과 암호화 서명을 사용하는 방식을 기반으로 합니다. 이 버전에는 세 가지 주요 역할이 있습니다.

• 사용자(User) : 리소스에 대한 권한을 소유한 사용자, 자신의 리소스에 접근 권한을 부여하려는 개인
• 소비자(Consumer) : 사용자의 리소스에 접근하려는 서드파티 애플리케이션
• 서비스 제공자(Service Provider) : 사용자의 리소스를 호스팅하는 서버

즉, 위 3가지의 역할이 서로 상호작용하는 형태입니다.

출처 : https://blog.stackademic.com/oauth-1-0-and-oauth-2-0-in-net-core-1f04a35abbae

 

OAuth 1.0의 인증 방식은 다음과 같습니다.

 

1. 소비자(애플리케이션)는 서비스 제공자로부터 Request Token을 요청합니다. 이 요청은 서명된 요청이며, 소비자의 정보를 포함하여 서비스 제공자에게 전송됩니다.
2. 서비스 제공자는 Request Token을 발급합니다.
3. Request Token을 받은 소비자는 사용자를 인증 URL로 리다이렉트시키고, 사용자는 해당 URL을 통해 자신을 인증하여, 소비자가 자신의 리소스에 접근할 수 있는 권한을 부여합니다.
4. 사용자가 승인하고 나면, 소비자는 서비스 제공자에게 Access Token을 요청합니다. 이 요청은 서명된 요청이며, Access Token은 소비자가 사용자의 리소스에 접근할 때 필요한 인증 정보입니다.
5. 서비스 제공자는 요청을 검증하고 Access Token을 발급합니다.
6. 이제 소비자는 받은 Access Token을 통해 사용자의 리소스에 접근하고 작업을 수행할 수 있게 됩니다.

OAuth 1.0의 프로세스는 서명된 요청과 함께 토큰 기반의 권한 부여 방식을 사용하여 소비자가 사용자의 리소스에 안전하게 접근할 수 있도록 하여 높은 수준의 보안을 제공합니다. 그러나 이 과정에서 소비자는 서비스 제공자에게 요청을 할 때마다 전자 서명을 만들어야 하며, nonce(한 번만 사용되는 임의의 값)를 다루는 복잡성으로 인해 구현이 어렵다는 특징을 가지고 있습니다.

 

---

✔️ OAuth 2.0

OAuth 2.0은 OAuth 1.0과 다른 방식의 용어를 사용합니다.

• Resource owner : 리소스에 대한 권한을 소유한 사용자 (OAuth 1.0에서의 User)
• Authorization Server : 사용자의 동의를 받아 권한을 부여하는 서버 (OAuth 1.0에서의  Service Provider)
• Resource Server : 자원을 호스팅하는 서버
• Client : Resource Server에서 제공하는 자원을 사용하는 애플리케이션 (OAuth 1.0에서의 Consumer)

📝 간소화된 워크플로우

OAuth 2.0은 OAuth 1.0의 사용자 인증 플로우 및 전반적인 목적은 동일하지만, OAuth 1.0에 비해 인증 절차가 간소화됨으로써 구현이 더 용이해졌습니다. OAuth 1.0은 구현 및 유지가 복잡한 전자 서명을 사용한 반면,  OAuth 2.0은 전자 서명을 사용하지 않고 HTTPS 프로토콜에게 보안을 담당하도록 합니다. HTTPS는 암호화된 통신을 제공하여 요청과 응답을 안전하게 전송하여 데이터의 기밀성과 무결성을 보장하기 때문이죠. 따라서 OAuth 2.0을 구현할 때 디지털 서명과 같이 복잡한 암호화 로직을 구현할 필요가 없어지면서 개발자 입장에서 구현이 간단해졌습니다.

 

📝 확장성

OAuth 2.0의 토큰 기반 접근 방식은 다양한 플랫폼과 디바이스와의 쉬운 통합과 확장성을 허용합니다. 이를 통해 서로 다른 환경에서도 일관된 인증 및 권한 관리를 할 수 있습니다.

 

📝 유연한 Grant Types

OAuth 2.0은 여러 Grant type을 제공하여 웹 애플리케이션, 모바일 앱 등 각 시나리오에 맞춰 필요한 권한 인가 방식을 선택할 수 있습니다.

• Authorization Code Grant : 일반적으로 웹 애플리케이션에서 사용되며, 소셜 로그인과 같은 인증 구현 시 가장 많이 쓰이는 방식입니다. 주로 Access Token과 Refesh Token을 사용합니다.
• Implicit Grant : 주로 웹 브라우저 기반의 애플리케이션이나 모바일 애플리케이션에서 사용되며, 권한 부여를 위해 리다이렉트된 URI에서 Aceess Token을 직접 얻는 방식입니다.
• Client Credentials Grant : 클라이언트의 자격 증명을 사용하여 서버에 직접 Access Token을 요청하는 방식입니다.
• Resource Owner Password Credentials Grant : 클라이언트가 사용자의 아이디와 패스워드를 직접 재공하여 Access Token을 받아오는 방식으로, 클라이언트가 사용자의 자격 증명을 직접 처리하는 것이기 때문에 클라이언트의 확실한 신용이 보장될 때 사용합니다.
• Device Code Grant : 인증되지 않은 디바이스(ex) 스마트 TV 또는 IOT 기기)에서 사용되는 방식으로, 해당 디바이스는 특정한 코드를 받고 이 코드를 사용자의 다른 기기(ex) 스마트폰 또는 컴퓨터)에서 인증하여 권한을 부여받습니다.
• Refresh Token Grant : Refresh Token은 액세스 토큰의 유효 기간이 만료된 경우에 사용되며, Access Token을 갱신하는데 사용됩니다. 즉, 일정 기간 동안 Access Token을 다시 발급받을 수 있도록 하는 Token입니다. Refresh Token Grant는 이 Refresh Token을 사용하여 새로운 Access Token을 얻는 방식을 의미합니다.

출처 : https://blog.stackademic.com/oauth-1-0-and-oauth-2-0-in-net-core-1f04a35abbae

 

OAuth 2.0의 대략적인 인증 방식은 다음과 같습니다.

 

1. 먼저 클라이언트가 사용자에게 권한을 요청합니다. 예를 들어, 로그인 페이지를 제공하여 아이디 및 패스워드를 요청합니다.
2. 사용자는 인증 정보(ex) 아이디와 패스워드)를 Authorization Server에게 제공합니다. 이때 Authorization Server는 특정 인증 코드를 발급하여 클라이언트로 리다이렉트되어 전달됩니다.
3. 클라이언트는 인증 코드를 통해 Authorization Server에게 Access Token을 요청합니다.
4. Authorization Server는 Access Token을 발급하여 클라이언트에게 전달합니다.
5. 클라이언트는 Access Token을 받아, 이를 통해 Resource Server로부터 리소스에 접근합니다.
6. Resource Server는 Access Token을 검증하여 리소스에 접근을 허용하며, 최종적으로 클라이언트가 사용자에게 서비스를 제공할 수 있게 됩니다.

지금까지 OAuth에 대해 알아보았습니다.🧐 다음 포스팅에서는 실제로 Spring 프레임워크에서 OAuth 기반의 소셜 로그인을 구현해보도록 하겠습니다.

---

References

• https://blog.stackademic.com/oauth-1-0-and-oauth-2-0-in-net-core-1f04a35abbae
• https://wan-blog.tistory.com/20