Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

Kuma's Curious Paradise

[이룸] 240201 카카오 로그인 도입 이유 본문

이룸 프로젝트

[이룸] 240201 카카오 로그인 도입 이유

쿠마냥 2024. 3. 6. 15:58

 

🌟 이번 프로젝트에서는 ‘카카오 로그인’을 구현해 볼 예정입니다. 그 이유는 다음과 같습니다.

 

  1. 사용자 경험 향상: 기존의 소셜 미디어 계정을 통해 로그인할 수 있기 때문에, 사용자에게 편리한 로그인 기능 제공이 가능합니다. 또한 소셜 미디어에서 제공하는 사용자 정보에 접근할 수 있기 때문에, 애플리케이션은 사용자의 프로필 정보를 활용하여 맞춤형 서비스를 제공할 수 있습니다.
  2. 보안 강화: 사용자의 비밀번호가 애플리케이션에 저장되지 않는 대신, 토큰 기반 보안 프로토콜을 사용하여 안전한 인증을 제공합니다.
  3. 사용자 신뢰 증진: 카카오, 구글과 같은 소셜 미디어의 신뢰도를 기반으로 애플리케이션에 대한 신뢰도가 증가할 수 있습니다.

 

OAuth 2.0 과 SNS 로그인 기능의 관계

  • OAuth는 외부 서비스(우리 서비스)의 인증 및 권한 부여를 관리하는 범용 프로토콜 중 하나입니다. SNS 로그인은 OAuth 2.0 프로토콜을 사용한 로그인 방식이지요.
  • 사용자는 SNS 계정으로 로그인하고, 애플리케이션은 해당 SNS 제공자로부터 OAuth 2.0 토큰을 얻습니다. 다시 말해, OAuth 또한 토큰 기반의 로그인을 구현한다는 뜻입니다. 애플리케이션은 이 토큰을 사용하여 사용자 정보에 액세스하고, 필요한 경우 SNS의 다양한 기능을 활용합니다.
  • 현재 사용되고 있는 OAuth 2.0의 인증 방식(그랜트 타입)은 4가지입니다. 상황에 맞게 그랜트 타입을 선택하고 사용합니다.
    • Authorization Code Grant:
      • 시나리오: 클라이언트가 서버 측 리소스에 접근하려는 경우. 대표적으로 웹 애플리케이션에서 사용됩니다.
      • 동작 방식:
        1. 클라이언트가 사용자를 서버로 리디렉션하여 인증 코드를 요청합니다.
        2. 사용자가 인증하면 서버는 클라이언트에게 인증 코드를 제공합니다.
        3. 클라이언트는 인증 코드를 사용하여 서버에 엑세스 토큰 및 리프레시 토큰을 요청합니다.
        4. 서버는 엑세스 토큰 및 리프레시 토큰을 클라이언트에게 발급합니다.
    • Implicit Grant
      • 시나리오: 클라이언트 측에서 리소스에 직접 액세스할 수 있는 경우. 대표적으로 SPA(Single Page Application)에서 사용됩니다.
      • 동작 방식:
        1. 클라이언트가 사용자를 서버로 리디렉션하여 액세스 토큰을 요청합니다.
        2. 사용자가 인증하면 서버는 클라이언트에게 액세스 토큰을 직접 제공합니다.
    • Resource Owner Password Credentials Grant
      • 시나리오: 클라이언트가 사용자의 아이디와 비밀번호를 직접 수신하고, 그 정보를 사용하여 엑세스 토큰을 얻어야 하는 경우. 주로 신뢰 가능한 애플리케이션이 서버에 직접 접근할 때 사용됩니다.
      • 동작 방식:
        1. 클라이언트가 사용자의 아이디와 비밀번호를 서버에 직접 제공합니다.
        2. 서버는 클라이언트에게 엑세스 토큰을 제공합니다.
    • Client Credentials Grant
      • 시나리오: 클라이언트가 자체적으로 인증하고 엑세스 토큰을 얻어야 하는 경우. 주로 클라이언트가 서버에 직접 접근하여 자체적으로 리소스에 액세스할 때 사용됩니다.
      • 동작 방식: 클라이언트가 서버에게 클라이언트 아이디와 클라이언트 시크릿을 제공하여 인증합니다.서버는 클라이언트에게 엑세스 토큰을 제공합니다.
    Authorization Code Grant와 Implicit Grant는 주로 웹 애플리케이션에서, Resource Owner Password Credentials Grant는 신뢰 가능한 애플리케이션에서, 그리고 Client Credentials Grant는 클라이언트가 서버에 직접 액세스해야 할 때 사용됩니다.

 


Authorization Code Grant

웹 애플리케이션에서 일반적으로 사용되는 그랜트 타입은 Authorization Code Grant입니다. 그 이유는 다음과 같습니다.

  1. 보안 강화:
    • Authorization Code Grant는 클라이언트에게 직접 액세스 토큰을 제공하지 않고, 대신에 인증 코드를 제공합니다. 이로써 클라이언트가 사용자의 정보를 직접 액세스하지 않고, 안전하게 토큰을 교환할 수 있습니다.
  2. 액세스 토큰 및 리프레시 토큰 제공:
    • Authorization Code Grant는 액세스 토큰과 리프레시 토큰을 모두 제공하므로, 클라이언트는 일정 기간 동안 리소스에 액세스할 수 있고, 만료 시 리프레시 토큰을 사용하여 새로운 토큰을 얻을 수 있습니다.
  3. 리디렉션 기반의 플로우:
    • Authorization Code Grant는 리디렉션을 통한 인증 플로우를 사용합니다. 사용자는 인증 과정을 서비스 제공자(인증 서버)의 페이지에서 진행하고, 최종적으로 클라이언트 애플리케이션으로 리디렉션됩니다.
  4. 코드 교환을 통한 보안 획득:
    • Authorization Code Grant는 코드 교환을 통해 토큰을 안전하게 획득할 수 있습니다. 액세스 토큰이 URL 파라미터로 직접 전송되지 않고, 대신에 안전한 코드 교환을 통해 토큰을 획득합니다.

이러한 이유로 Authorization Code Grant는 웹 애플리케이션에서 사용자의 보안 및 개인 정보를 더욱 효과적으로 보호하고, 안전한 인증 플로우를 제공하는 데 많이 사용됩니다.

 

Authorization Code Grant 동작 순서 그림으로 살펴보기

출처 : https://tansfil.tistory.com/60?category=475681

 

 

Authorization Code Grant

  1. Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 합니다.
  2. Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(ex Facebook, Google 로그인 url)을 보냅니다.
  3. Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 Authorization Grant를 url에 실어 Client에게 보냅니다.
  4. Client는 해당 권한증서(Authorization Grant)를 Authorization Server에 보냅니다.
  5. Authorization Server는 권한증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해줍니다.
  6. Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘깁니다.
  7. Resource Owner(사용자)가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청합니다.
  8. Resource Server는 Access Token이 유효한지 확인 후, Client에게 자원을 보냅니다.
  9. 만일 Access Token이 만료됐거나 위조되었다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급 받습니다.
  10. 그 후 다시 Resource Server에 자원을 요청합니다.
  11. 만일 Refresh token도 만료되었을 경우, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야합니다. (이는 다시 사용자가 다시 로그인 하라는 말입니다.)

OAuth2.0을 이용한 SNS 로그인

출처 : https://velog.io/@kys8854/JWT%ED%86%A0%ED%81%B0-%EC%9D%B8%EC%A6%9D%EC%B2%98%EB%A6%AC-%ED%9D%90%EB%A6%84

 

출처: https://tansfil.tistory.com/60?category=475681

  1. 사용자(Resource Owner)가 서버에게 로그인을 요청합니다.
  2. 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보냅니다.
  3. 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한증서(code)를 담아 서버에게 보냅니다.
  4. 서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청합니다.
  5. 서버는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보(고유 id 포함) 등을 돌려줍니다.
    여기서 프로필 이미지나 이메일 주소, 이름 등을 얻을 수도 있는데 이는 초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 다릅니다. 페이스북 이름에 대해서만 접근할 수 있는 권한을 설정하면 이름 값만 Authorization Server에서 돌려줄 것입니다,
  6. 받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행합니다.
  7. 로그인이 완료되었다면 세션/쿠키 , 토큰기반 인증 방식을 통해 사용자의 인증을 처리합니다.

이렇게 OAuth2.0과 SNS 로그인에 대해 알아보았습니다. 배운 내용을 참고하여 카카오 로그인 기능 구현을 시작해 보려 합니다.