[OAuth] OAuth를 파헤쳐보자

Hocaron·2022년 2월 8일

oAuth

🔐소셜 로그인을 구현하면서, 빠질 수 없는 OAuth! 이번에 제대로 공부해보고, 정리해보자.

OAuth란?

OAuth가 사용되기 전에는?

외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조였다.

OAuth1이란?

Open Authorization, Open Authentication 의미한다.
말 그대로 애플리케이션(페이스북,구글,트위터)(Service Provider)의 API를 유저대신에 접근할 수 있는 권한을 Third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜이다.
OAuth의 인증은 API를 제공하는 서버에서 진행하고, 유저가 인증되었다는 Access Token을 발급하였다.
그 발급된 Access token으로 Third party(Consumer)애플리케이션에서는 Service Provider의 API를 안전하고 쉽게 사용할 수 있게 되었다.

OAuth2 란?

OAuth의2는 OAuth의1의 유저의 인증플로우, 전반적인 목적만 공유하고 OAuth의1.0을 새로 작성한것이다.

OAuth의1.0 과 OAuth의2.0차이점

OAuth의1.0과 OAuth의2.0의 차이는 앱 애플리케이션, 웹 애플리케이션, 데스크탑 애플리케이션등의 인증방식을 강화하고 Consumer에 개발 간소화를 중심으로 개발 되었다.
인증 절차 간소화
- 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어 졌다.
- 기존의 OAuth1.0은 디지털 서명 기반이었지만 OAuth2.0의 암호화는 https에 맡김으로써 복잡한 디지털 서명에관한 로직을 요구하지 않기때문에 구현 자체가 개발자입장에서 쉬워졌다.
용어 변경
- Resource Owner : 사용자 (1.0 User해당)
- Resource Server : REST API 서버 (1.0 Protected Resource)
- Authorization Server : 인증서버 (API 서버와 같을 수도 있음)(1.0 Service Provider)
- Client : 써드파티 어플리케이션 (1.0 Service Provider 해당)
Resource Server와 Authorization Server서버의 분리
- 커다란 서비스는 인증 서버를 분리하거나 다중화 할 수 있어야 함.
- Authorization Server의 역할을 명확히 함.
액세스 토큰은 기간이 짧다
- 일반적으로 OAuth 1.0 액세스 토큰은 1 년 이상 보관
- OAuth 2.0에는 리프레시 토큰 개념 도입하여, 엑세스 토큰의 기간은 짧지만, 리프레시 토큰을 사용하여 재발급 받을 수 있게 만들었다.
다양한 인증 방식(Grant_type)
- Authorization Code Grant
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
- Device Code Grant
- Refresh Token Grant

그림으로 보는 OAuth의 1.0의 WorkFlow

WorkFlow를 이해하기 위해 먼저 알아야 할 개념

용어	설명
User	Service Provider에 계정을 가지고 있으면서, Consumer앱을 이용하려는 사용자
Service Provider	OAuth를 사용하는 Open API를 제공하는 서비스 (facebook,google등)
Protected Resource	Service Provider로부터 제공되어지는 API 자원들
Consumer	OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스
Consumer Key	Consumer가 Service Provider에게 자신을 식별하는 데 사용하는키
Consumer Secret	Consumer Key의 소유권을 확립하기 위해 Consumer가 사용하는 Secret
Request Token	Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환한다.
Access Token	인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값
Token Secret	주어진 토큰의 소유권을 인증하기 위해 소비자가 사용하는 Secret

가장 먼저 Consumer는 Service Provider로부터 Client key와 Secret을 발급 받아야한다. 이것은 Service Provider에 API를 사용할것을 등록하는것과 동시에 Service Provide가 Consumer를 식별할 수 있게 해준다.
Request Token을 요청할 때 Consumer 정보, Signature 정보를 포함하여 Request token을 요청, 발급 받는다.
Request Token값을 받은후 Consumer는 User를 Service Provider에 인증 사이트로 다이렉트시키고,
유저는 그곳에서 Service Provider에 유저임을 인증하게 된다.
Consumer는 해당 유저가 인증이되면 OAuth_token와 OAuth_verifier를 넘겨준다.
그이후에 Consumer는 OAuth_token와 OAuth_verifier받았다면 다시 서명을 만들어 Access Token을 요청하게 된다.
그리고 Service Provider는 받은 토큰과 서명들이 인증이 되었으면 Access Token을 넘기게된다.
그리고 그 Access Token 및 서명정보를 통해 Service Provider에 Protected Resource에 접근할 수 있게 된다.

그림으로 보는 OAuth의 2.0의 WorkFlow

WorkFlow를 이해하기 위해 먼저 알아야 할 개념

용어	설명
Resource Owner	사용자
Resource Server	보호된 리소스를 관리하며, 사용할 API를 관리하는 주체. 토큰의 유효성을 확인하기 위해 인가 서버와 통신을 주고받기도 한다, REST API 서버
Authorization Server	요구하는 정보나 리소스에 접근할 수 있도록 허용하는 서버
Client	소유자 대신 토큰으로 리소스 서버의 API를 사용하는 주체, 써드파티 어플리케이션

1. 먼저 클라이언트가 Redirect URL을 포함하여 Authorization server 인증 요청을 한다.
2. AuthorizationServer는 유저에게 로그인창을 제공하여 유저를 인증하게 된다.
3. AuthorizationServer는 Authorization code를 클라이언트에게 제공해준다. 사전에 등록한 인증사이트로 다이렉트 시킨다.
4. Client는 코드를 Authorization server에 Access Token을 요청한다.
5. Authorization 서버는 클라이언트에게 Access token을 발급해준다.
6. 그 Access token을 이용하여 Resource server에 자원을 접근할 수 있게 된다. 그이후에 토큰이 만료된다면 refresh token을 이용하여 토큰을 재발급 받을 수 있다.

주의해야 하는 부분

리소스 클라이언트가 필요 이상의 권한을 요청하지 않는지 확인해야 한다.
- scope를 정해야 한다.
- 개발과정에서는 편의성을 위해 권한을 포괄적으로 부여하지만, 서비스 출시 시에는 사용자가 직접 필요한 권한만 체크해서 토큰 생성하도록 해야한다.
발급받은 토큰이 외부로 유출되지 않도록 주의해야 한다.
- 유효기간을 짧게 설정하고, 자주 갱신해야 한다.
공식 SDK 사용하기
- SDK는 보안패치 / 인가코드 없이 토큰을 사용하거나 토큰을 자동 갱신하는 편의성을 제공한다.
HTTPS 사용하기

🤔 서버 사이드에서 한번더 생각해볼점

토큰의 권한 검사하기
- 토큰이 유효하지 authorization server에 요청을 보내 확인해야 한다.
데이터 검증하기
- 클라이언트에서 받은 모든 데이터는 신뢰할 수 없다.
- 문자열은 escape를 거쳐야 하고, 브라우저의 경우 content-type은 application/json으로 설정해야 한다.
에러를 리턴해야 할 때, 가급적이면 정보노출을 최소화하자.