본문 바로가기

SPRING

OAUTH란

이번 파이널 프로젝트에서 로그인 API를 써볼 기회가 생겼다. 

호기롭게 시작했는데 무슨 말인지 도통 이해 안가는거 투성이다....ㅠㅠ 

 

이런저런 예제들 보면서 해보는데 OAuth 이게 자꾸 나와서 그게뭔데!! 하고 찾아보게 되었다.

워낙 정리가 잘되어있어서 이해가 쏙쏙되었다!  하지만...이해만 하고 넘어가면 까먹을것같아서 적어본다..ㅠ

아래는 참고한 사이트트들

https://d2.naver.com/helloworld/24942

https://mylupin.tistory.com/38

 

OAuth 2.0 이란

안녕하세요 코드짜는헬창입니다. 카카오 로그인 연동중 OAuth 개념이 궁금하여 찾던중 이해가 잘되는 글이 있어 포스팅 했습니다~! 도움 되시길 바랍니다. 참조 : https://baked-corn.tistory.com/29 OAuth2.0

mylupin.tistory.com

https://interconnection.tistory.com/76

 

OAuth의 개념과 원리

DB의 종류를 바꾸어서 마이그레이션을 하는 과정에서 하나 발견한 JSON token을 발견했습니다. FaceBook에서 사용하는 Token인데, 여기서 OAuth를 사용을 하는데 정확히 원리와 개념에 대해서 몰랐습니

interconnection.tistory.com

https://swalloow.github.io/about-oauth2/

 

OAuth2에 대해 알아보자

먼저 OAuth 인증을 이해하기 위해 필요한 몇 가지 개념들에 대해 알아보자. OAuth 인증을 진행할 때 해당 서비스 제공자는 '제 3자가 어떤 정보나 서비스에 사용자의 권한으로 접근하려 하는데 허용

swalloow.github.io

OAuth란?

- API 접근 및 사용 인증을 위한 프로토콜이다.

 

OAuth의 Auth는 두가지를 포함하고 있다. 

  • Authentication(인증)
  • Authoriztion(허가)

즉, OAuth 인증을 진행할때마다 해당 서비스 제공자는 '제 3자가 어떤 정보나 서비스에 사용자 권한 접근을 허용하겠느냐?"라는 안내 메세지를 보내주는 것이다.

아래는 Naver d2 에서 발췌한 설명이다. 저 글을 읽고 뭐가 다른지 확실히 이해할 수 있어서 아예 통으로 넣었다.

OAuth와 로그인
OAuth와 로그인은 반드시 분리해서 이해해야 한다.
일상 생활을 예로 들어 OAuth와 로그인의 차이를 설명해 보겠다.
사원증을 이용해 출입할 수 있는 회사를 생각해 보자. 그런데 외부 손님이 그 회사에 방문할 일이 있다. 회사 사원이 건물에 출입하는 것이 로그인이라면 OAuth는 방문증을 수령한 후 회사에 출입하는 것에 비유할 수 있다.
다음과 같은 절차를 생각해 보자.
1. 나방문씨(외부 손님)가 안내 데스크에서 업무적인 목적으로 김목적씨(회사 사원)를 만나러 왔다고 말한다.
2. 안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.
3. 김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.
4. 김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.
5. 안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.
6. 김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.

위 과정은 방문증 발급과 사용에 빗대어 OAuth 발급 과정과 권한을 이해할 수 있도록 한 것이다. 방문증이란 사전에 정해진 곳만 다닐 수 있도록 하는 것이니, '방문증'을 가진 사람이 출입할 수 있는 곳과 '사원증'을 가진 사람이 출입할 수 있는 곳은 다르다. 역시 직접 서비스에 로그인한 사용자와 OAuth를 이용해 권한을 인증받은 사용자는 할 수 있는 일이 다르다.

 

OAuth1.0

- 웹애플리케이션을 중심적으로 만들어졌음.

 

OAuth1.0의 특징

- API 인증 시 , 사용자의 비번을 노출하지 않고 인증할 수 있음.

- 인증과 API 권한 부여를 동시에 할 수 있다.

 

OAuth1.0의 동작 방식

- OAuth 1.0 은 기본적으로 user/consumer/service provider 가 필요하다.

 

아래 사진은 내가 만들고 있는 프로젝트 로그인 화면이다.

그림이 있으면 좀 더 보기좋아서 아래 나오는 얘기는 이 사이트를 기준으로 적겠다.

- user는 사용자로 petbreedding에 카카오나 네이버로 로그인 하려는 사람

- consumer는 카카오나 네이버

- service provider 는 이제 전달받은 API를 이용할 petbreedding이다.

 

OAuth1.0의 단점

  • 웹애플리케이션 말고 애플리케이션에서는 사용하기 곤란하다
  • 복잡한 절차로 인한 OAuth 구현 라이브러리 제작이 어렵다.
  • Access Token 발급시 계속 사용가능해 보안 문제

 

OAuth2.0이란? 

- 기존 1.0의 단점들을 보완해 만든 프로토콜로 용어체계가 1.0과는 달라서 같은 목적의 다른 프로토콜

- 애플리케이션에서의 사용성 문제나 서명과 같은 개발이 복잡하고 기능과 규모의 확장성 지원을 위해 만들어진 표준이다. 

 

OAuth1.0과의 다른 점

  • 용어가 변경 되었다.
    • Resource Owner : 사용자 == OAuth1.0의 user
    • Resource Server : REST API 서버 == OAuth1.0의 consumer
    • Authoiztion Server : 인증 서버
    • Client : 써드파티 어플리케이션 (서비스)  == OAuth1.0의 service provider
  • 간단하고 직관적이다. 
    • OAuth 1.0에서는 HTTPS가 필수였다...
    • Signature 없이 생성 및 호출이 가능해졌다.
    • URL 인코딩을 할 필요가 없다.  --> redirect 덕분인가..?
  • 더 많은 인증 방법을 지원한다.
    • 여러 인증 방식을 통해 웹/모바일 등 다양한 시나리오에 대응이 가능하다.
    • Access Token의 Life-time을 지정해 만료일 설정이 가능해져서 보안을 강화할 수 있다.
  • 대형 서비스로의 확장성 지원

OAuth2.0의 프로세스

  1. Client(petbreedding)이 먼저 ResourceServer(카카오/네이버)의 API를 사용한다고 ResourceServer에 등록
    1. 등록과정에서 ResourceServer는 Client에게 Client_ID와 Client Secret을 부여해준다.
  2. Resource Owner(user)가 Client(petbreedding)에서 카카오나 네이버로 로그인을 요청
  3. Client(petbreedding)는 Resource Owner(user)에게 ResourceServer(카카오/네이버)의 로그인 창을 띄움
  4. 로그인 후 Resource Owner(user)는 자신의 정보 접근 권한 동의 화면을 보고 동의에 체크
    1. 동의 안하면 Client(petbreedding)에서 로그인 못함
  5. ResourceServer(카카오/네이버)가 Client(petbreedding)에게 암호화된 Code를 먼저 던져준다.
  6. Client(petbreedding)가 그럼 다시 암호화된 Code + 자신의 Client_ID와 Client Secret를 ResourceServer(카카오/네이버)에게 돌려보낸다.
  7. 돌려받은 정보가 일치하다면 ResourceServer(카카오/네이버)는 Client(petbreedding)에게 접근 권한 부여의 암호인 Access Token을 던져준다.
  8. 로그인 성공!

 


일단 뭔가 크게는 이해했는데 코드로 구현할 생각하니 쫌.. 막막하긴 하다. 그래도 어떻게 진행되는지는 이해했다.