Home [Security] OAuth 2.0?
Post
Cancel

[Security] OAuth 2.0?

3월 3주차 스터디 발표 자료📖
앞의 서버,토큰 인증 포스팅에 이어 OAuth에 대해 알아보고자 합니다!!
🔥서버/토큰 인증방식: https://chonahyeon.github.io/posts/SessionToken/

OAuth?


소셜 로그인

  • OAuth란 구글,페이스북 등 다양한 플랫폼의 사용자 데이터에 접근하기 위해 제 3자인 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임받을 수 있는 프로토콜이다.
  • 예시로는 소셜 로그인이나 구글 캘린더와 연동하여 사용자의 일정을 대신 기록해주는 서비스 등이 있다.

OAuth vs OAuth2.0

  • 🤔 OAuth의 개념은 알겠는데 두 버전의 차이는 뭘까?
    • OAuth 2.0은 OAuth의 보안 문제등을 개선한 버전이다.
    • OAuth 2.0은 암호화와 토큰 관리같은 추가적인 보안 처리를 필요로한다.
특징OAuth 1.0OAuth 2.0
역할이용자, 소비자, 서비스 제공자자원 소유자, 클라이언트, 자원 서버, 권한 서버
API 호출 인증 및 보안서명- HTTPS 기본 제공
- Access Token의 만료일 설정 가능
- 여러 인증 방식을 제공함으로써 다양한
시나리오에 대응이 가능하다.
클라이언트 지원 유형웹 애플리케이션다양한 플랫폼 지원
Access TokenAccess Token 발급 시 계속 사용 가능보안 강화를 위해 만료일 설정 가능

OAuth 2.0의 역할

  1. Resource Owner(자원 소유자)
    • 자원 서버에 계정을 가지고 있는 사용자로 본인의 계정을 통해 자원 서버에 접근하는 것을 인가한다.
  2. Client
    • Resource Server의 자원을 이용하고자 하는 애플리케이션 (ex. 소셜 로그인을 등록하고자하는 앱,웹)
  3. Resource Server(자원 서버)
    • 특정 사용자의 리소스를 가지고 있는 서버. (ex. 구글,트위터,페이스북)
  4. Authorization Server(인증 서버)
    • 인증/인가를 수행하는 서버
    • Client에게 보호된 자원에 엑세스 할 수 있는 권한(Access Token)을 부여해준다.

OAuth 2.0의 동작방식

OAuth 작동방식

  • OAuth의 대략적인 흐름을 알아보자.
    1. 클라이언트는 보호된 리소스로 접근하기 위해 자원 소유자에게 권한을 요청한다.
    2. 자원 소유자가 리소스 접근에 동의한다면 (인가)
    3. 클라이언트는 인증 서버로 Access Token 발급을 요청한다. 이때 인증을 위한 클라이언트 정보와 제공받을 권한을 함께 전달한다.
      • Client ID : 클라이언트를 식별하는 고유한 ID
      • Client Secret : 클라이언트를 인증하는 비밀번호 같은 값
      • Scope : 제공받을 권한의 범위를 지정
      • Client Secret : Access Token 발급 완료 후 리다이렉트할 URI
    4. 인증 정보와 제공할 권한 정보가 유효하다면, 인증 서버는 클라이언트에게 Access Token을 전달한다.
    5. 클라이언트는 자원 서버에게 필요한 리소스를 요청하고 Access Token도 함께 전달한다.
    6. 자원 서버는 Access Token을 검증한 후, 요청한 리소스를 전달한다.

OAuth 2.0의 권한 부여 유형

이미지 출처 [권한 부여 선택 유형 ]: https://m.blog.naver.com/PostView.naver?blogId=mds_datasecurity&logNo=222182943542&proxyReferer=
이미지 출처 [권한 부여 선택 flow ]: https://justee.tistory.com/1

  • 권한부여?
    클라이언트가 사용자(자원 소유자)를 대신하여 사용자의 승인 하에 인가서버로 부터 권한을 부여받는 것

1. Authorization Code

  • 권한 코드 부여타입이며 서버 사이트 애플리케이션(웹 애플리케이션)에 적합하며 보안에 가장 안전한 유형이다.
  • 리소스 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는다.
  • Refresh Token의 사용이 가능하다.

권한 부여 타입 1

  1. 클라이언트가 권한 코드를 얻기 위해 파라미터로 클라이언트 ID, 리다이렉트 URI, 응답 타입을 Code로 지정하여 권한 서버에 전달한다.
  2. 권한 서버는 사용자(Resource Owner)에게 로그인 페이지를 제공하고 해당 페이지를 통해 사용자의 인증이 완료되면 권한 코드를 redirect_url로 클라이언트에게 전달한다.
  3. 권한 코드를 전달 받은 후 클라이언트는 권한 코드를 사용하여 권한 서버에 Access Token을 추가로 요청한다. 이때 파라미터로 클라이언트 아이디, 클라이언트 비밀번호, 리다이렉트 URI,인증 타입이 필요하다.
  4. Access Token을 전달 받은 후 리소스 서버에 엑세스 토큰을 사용하여 필요한 리소스를 요청한다.

2. Implict

  • 암시적 승인 타입이며 권한 코드 없이 바로 Access Token이 발급되는 방식이다.
  • 자격 증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식이다. (ex.스크립트 언어를 사용한 브라우저)
  • Access Token의 만료기간을 짧게 설정하여 외부 유출의 위험을 줄여야한다.

권한 부여 타입 2

  1. 클라이언트가 접근 권한을 얻기 위해 파라미터로 클라이언트 ID, 리다이렉트 URI, 응답 타입을 token으로 지정하여 권한 서버에 전달한다.
  2. 권한 서버는 사용자(Resource Owner)에게 로그인 페이지를 제공하고 해당 페이지를 통해 사용자의 인증이 완료되면 Access Token을 redirect_url로 클라이언트에게 전달한다.
    • Authorization Code와 달리 Implict 방식은 권한 코드를 부여받지 않고 바로 Access Token이 발급된다.
    • 리소스 소유자의 인증 정보를 클라이언트에서 직접 가지고 있는다.
  3. Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.
  4. Access Token이 유효하다면 요청한 리소스를 전달한다.

3. Resource Owner Password Credentials

  • 자원서버에 계정이 있는 사용자의 아이디, 패스워드를 통해 Access Token을 발급받는 방식.
  • 클라이언트가 타사의 외부 프로그램이라면 절대 이 방식을 사용해서는 안된다.
    즉, 권한 서버,리소스 서버,클라이언트가 모두 같은 시스템에 속해 있을 때 사용해야하는 방식이다.
  • Refresh Token 사용이 가능하다.

권한 부여 타입 3

  1. 사용자(리소스 소유자)가 클라이언트에게 서비스 사용 요청 시, 리소스 서버의 아이디와 비밀번호를 같이 전송한다.
  2. 클라이언트는 사용자의 리소스 서버 아이디와 비밀번호를 사용하여 Access Token을 요청한다. 파라미터로 클라이언트 ID, 클라이언트 시크릿 키, 승인 타입, 사용자의 ID, 사용자의 Password를 권한 서버에 전달한다.
  3. 클라이언트는 Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.

4. Client Credentials

  • 클라이언트 자격 증명 승인타입으로 클라이언트의 자격 증명만으로 Access Token을 획득하는 방식이다.
  • 즉, 클라이언트 애플리케이션 자체가 자원에 대한 접근 권한을 가지고 있을 때 사용하는 방식으로 사용자 인증이 불필요하다.
  • 서버간 통신을 위한 인증에 주로 사용한다.
  • Refresh Token 사용이 불가능하다.

권한 부여 타입 4

  1. 클라이언트가 본인의 클라이언트 ID와 시크릿키를 통해 Access Token을 요청한다.
  2. 권한 서버는 유효한 ID와 시크릿 키 값이면 Access Token을 발급한다.
  3. 클라이언트는 Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.

🤔 권한 부여 유형은 어떻게 선택할까?

권한 부여 유형

  • First party?
    • 소프트웨어 또는 IT 서비스를 직접 개발하고 운영하는 주체
    • 데이터를 제공하는 측을 말하며 만약 구글 계정으로 Gmail에 로그인 할 경우 구글이 First Party이다.
  • Third party?
    • 원래의 제공자가 아닌 외부에서 제공되는 서비스나 애플리케이션을 말한다.
    • 데이터를 수집하거나 처리하는 측을 말한다.
    • 예를 들어 타 사이트에서 Facebook을 통해 로그인 할 경우 Facebook은 Third party이다.
This post is licensed under CC BY 4.0 by the author.