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.0 | OAuth 2.0 |
|---|---|---|
| 역할 | 이용자, 소비자, 서비스 제공자 | 자원 소유자, 클라이언트, 자원 서버, 권한 서버 |
| API 호출 인증 및 보안 | 서명 | - HTTPS 기본 제공 - Access Token의 만료일 설정 가능 - 여러 인증 방식을 제공함으로써 다양한 시나리오에 대응이 가능하다. |
| 클라이언트 지원 유형 | 웹 애플리케이션 | 다양한 플랫폼 지원 |
| Access Token | Access Token 발급 시 계속 사용 가능 | 보안 강화를 위해 만료일 설정 가능 |
OAuth 2.0의 역할
- Resource Owner(자원 소유자)
- 자원 서버에 계정을 가지고 있는 사용자로 본인의 계정을 통해 자원 서버에 접근하는 것을 인가한다.
- Client
- Resource Server의 자원을 이용하고자 하는 애플리케이션 (ex. 소셜 로그인을 등록하고자하는 앱,웹)
- Resource Server(자원 서버)
- 특정 사용자의 리소스를 가지고 있는 서버. (ex. 구글,트위터,페이스북)
- Authorization Server(인증 서버)
- 인증/인가를 수행하는 서버
- Client에게 보호된 자원에 엑세스 할 수 있는 권한(Access Token)을 부여해준다.
OAuth 2.0의 동작방식
- OAuth의 대략적인 흐름을 알아보자.
- 클라이언트는 보호된 리소스로 접근하기 위해 자원 소유자에게 권한을 요청한다.
- 자원 소유자가 리소스 접근에 동의한다면 (인가)
- 클라이언트는 인증 서버로 Access Token 발급을 요청한다. 이때 인증을 위한 클라이언트 정보와 제공받을 권한을 함께 전달한다.
- Client ID : 클라이언트를 식별하는 고유한 ID
- Client Secret : 클라이언트를 인증하는 비밀번호 같은 값
- Scope : 제공받을 권한의 범위를 지정
- Client Secret : Access Token 발급 완료 후 리다이렉트할 URI
- 인증 정보와 제공할 권한 정보가 유효하다면, 인증 서버는 클라이언트에게 Access Token을 전달한다.
- 클라이언트는 자원 서버에게 필요한 리소스를 요청하고 Access Token도 함께 전달한다.
- 자원 서버는 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의 사용이 가능하다.
- 클라이언트가 권한 코드를 얻기 위해 파라미터로 클라이언트 ID, 리다이렉트 URI, 응답 타입을 Code로 지정하여 권한 서버에 전달한다.
- 권한 서버는 사용자(Resource Owner)에게 로그인 페이지를 제공하고 해당 페이지를 통해 사용자의 인증이 완료되면 권한 코드를 redirect_url로 클라이언트에게 전달한다.
- 권한 코드를 전달 받은 후 클라이언트는 권한 코드를 사용하여 권한 서버에 Access Token을 추가로 요청한다. 이때 파라미터로 클라이언트 아이디, 클라이언트 비밀번호, 리다이렉트 URI,인증 타입이 필요하다.
- Access Token을 전달 받은 후 리소스 서버에 엑세스 토큰을 사용하여 필요한 리소스를 요청한다.
2. Implict
- 암시적 승인 타입이며 권한 코드 없이 바로 Access Token이 발급되는 방식이다.
- 자격 증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식이다. (ex.스크립트 언어를 사용한 브라우저)
- Access Token의 만료기간을 짧게 설정하여 외부 유출의 위험을 줄여야한다.
- 클라이언트가 접근 권한을 얻기 위해 파라미터로 클라이언트 ID, 리다이렉트 URI, 응답 타입을 token으로 지정하여 권한 서버에 전달한다.
- 권한 서버는 사용자(Resource Owner)에게 로그인 페이지를 제공하고 해당 페이지를 통해 사용자의 인증이 완료되면 Access Token을 redirect_url로 클라이언트에게 전달한다.
- Authorization Code와 달리 Implict 방식은 권한 코드를 부여받지 않고 바로 Access Token이 발급된다.
- 리소스 소유자의 인증 정보를 클라이언트에서 직접 가지고 있는다.
- Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.
- Access Token이 유효하다면 요청한 리소스를 전달한다.
3. Resource Owner Password Credentials
- 자원서버에 계정이 있는 사용자의 아이디, 패스워드를 통해 Access Token을 발급받는 방식.
- 클라이언트가 타사의 외부 프로그램이라면 절대 이 방식을 사용해서는 안된다.
즉, 권한 서버,리소스 서버,클라이언트가 모두 같은 시스템에 속해 있을 때 사용해야하는 방식이다. - Refresh Token 사용이 가능하다.
- 사용자(리소스 소유자)가 클라이언트에게 서비스 사용 요청 시, 리소스 서버의 아이디와 비밀번호를 같이 전송한다.
- 클라이언트는 사용자의 리소스 서버 아이디와 비밀번호를 사용하여 Access Token을 요청한다. 파라미터로 클라이언트 ID, 클라이언트 시크릿 키, 승인 타입, 사용자의 ID, 사용자의 Password를 권한 서버에 전달한다.
- 클라이언트는 Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.
4. Client Credentials
- 클라이언트 자격 증명 승인타입으로 클라이언트의 자격 증명만으로 Access Token을 획득하는 방식이다.
- 즉, 클라이언트 애플리케이션 자체가 자원에 대한 접근 권한을 가지고 있을 때 사용하는 방식으로 사용자 인증이 불필요하다.
- 서버간 통신을 위한 인증에 주로 사용한다.
- Refresh Token 사용이 불가능하다.
- 클라이언트가 본인의 클라이언트 ID와 시크릿키를 통해 Access Token을 요청한다.
- 권한 서버는 유효한 ID와 시크릿 키 값이면 Access Token을 발급한다.
- 클라이언트는 Access Token을 통해 리소스 서버에 필요한 리소스를 요청한다.
🤔 권한 부여 유형은 어떻게 선택할까?
- First party?
- 소프트웨어 또는 IT 서비스를 직접 개발하고 운영하는 주체
- 데이터를 제공하는 측을 말하며 만약 구글 계정으로 Gmail에 로그인 할 경우 구글이 First Party이다.
- Third party?
- 원래의 제공자가 아닌 외부에서 제공되는 서비스나 애플리케이션을 말한다.
- 데이터를 수집하거나 처리하는 측을 말한다.
- 예를 들어 타 사이트에서 Facebook을 통해 로그인 할 경우 Facebook은 Third party이다.