본문 바로가기
카테고리 없음

OAuth 2.0 관련 참고자료

좋은날 2016. 7. 7. 15:57

- OAuth2 프레임워크 표준

tools.ietf.org/html/rfc6749


- OAuth2 요약정리

http://earlybird.kr/1584

http://blog.naver.com/zoo5252/120209424686


- Google OAuth2 연동 사례

http://www.joinc.co.kr/w/man/12/oAuth2/Google


<용어 정리>

- User-Agent : 웹브라우저 등

- Resource Owner : 이용자

- Resource Server : API 서버(다양한 자원을 제공)

- Authorization Server : 인증서버 (API 서버와 같을 수도 있음)

- Client : 써드파티 어플리케이션(앱 또는 서버)


<OAuth 2.0 특징>

1. 간결성

OAuth 1.0a https가 필수가 아니었기 때문에 signature를 생성해서 호출애햐 했음
OAuth 1.0a API의 테스트가 힘듬
OAuth 2.0의 Bearer 토큰 인증 방식은 더 이상 signature가 필요 없음
API의 테스트가 간단해짐

2. 다양한 인증 방법 지원

OAuth1.0은 HMAC을 이용한 암호화 인증 방식만 제공
OAuth2.0은 시나리오별로 다양한 인증 방식을 제공
웹 브라우저, 모바일 등

3. 대형 서비스로 확장성 지원
- API 서버와 인증 서버의 역할을 분리 - 인증 서버 분리, 인증 서버 다중화등을 고려


<토큰 스펙>
oauth-v2 와 oauth-v2-bearer 라는 2개의 표준
이 외에도 SAML, JSON 웹 토큰, MAC 토큰 등의 방식 존재

* OAuth 2.0 변경사항
  1. HTTP 헤더 앞 부분에 bearer 토큰을 보내기 전에 “OAuth” 에서 “Bearer”로 수정
  2. “oauth_token” 이름이 “access_token” 으로 변경
<OAuh 1.0a 인증 방식>
OAuth 1.0a가 동작하기 위해서는 사용자, 컨슈머, 서비스 프로바이더가 필요하고 3-legged OAuth Client 는 기본적으로 Confidential Client 와 Public Client 로 나뉜다.
  • Confidential 클라이언트는 웹 서버가 API를 호출하는 경우 등과 같이 client 증명서(client_secret)를 안전하게 보관할 수 있는 Client를 의미한다.
  • Public Client는 브라우저기반 어플리케이션이나 모바일 어플리케이션 같이 client 증명서를 안전하게 보관할 수 없는 Client를 의미하는데 이런 경우 redirect_uri 를 통해서 client를 인증한다.
<OAuth 2.0 인증 방식>

OAuth 2.0이 지원하는 인증방식은 client 종류와 시나리오에 따라 아래 4가지가 있다. 하지만 실제로 Authorization Code Grant와 Implicit Grant를 제외하고는 일반적인 3-legged OAuth 가 아니기 때문에 open API에서는 많이 사용되지 않는다.

  1. Authorization Code Grant
    웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식이다. 서버사이드 코드가 필요한 인증 방식이며 인증 과정에서 client_secret 이 필요하다.
    로그인시에 페이지 URL에 response_type=code 라고 넘긴다.
    - 인증을 받으면 authorization code가 반환되고 이 코드를 client 에서 이용해서 access_token을 취득
    - user_agent(웹브라우저)는 access_token을 확인할 수 없어 token 노출 최소화 가능
    - JSP/Servlet, PHP등과 같은 Server-side 프로그래밍으로 인증을 구현할 경우 사용하기 적합한
    - (예) Ebay

  2. Implicit Grant
    token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식이다. Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용하면 된다. Client 증명서를 사용할 필요가 없으며 실제로 OAuth 2.0에서 가장 많이 사용되는 방식이다.
    로그인시에 페이지 URL에 response_type=token 라고 넘긴다.
    - Javascript 등을 이용해 클라이언트 브라우저등에서만 모든 처리가 이루어지는 요청에 활용

  3. Password Credentials Grant
    이 방식은 2-legged 방식의 인증이다. Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식이다. Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다.
    로그인시에 API에 POST로 grant_type=password 라고 넘긴다.

  4. Client Credentials Grant
    어플리케이션 이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.
    로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다.
    - Paypal, amazon

  5. Extension
    OAuth 2.0은 추가적인 인증방식을 적용할 수 있는 길을 열어놓았다. 이런 과도한 확장성을 메인 에디터인 Eran Hammer는 매우 싫어했다고 한다.
테스트
Authorization: Bearer


<Refresh token>

클라이언트가 같은 access token을 오래 사용하면 결국은 해킹에 노출될 위험이 높아진다. 그래서 OAuth 2.0에서는 refresh token 이라는 개념을 도입했다. 즉, 인증 토큰(access token)의 만료기간을 가능한 짧게 하고 만료가 되면 refresh token으로 access token을 새로 갱신하는 방법이다. 이 방법은 개발자들 사이에서는 논란이 있는데, 토큰의 상태를 관리해야 해서 개발이 복잡해 질 뿐만 아니라 토큰이 만료되면 다시 로그인 하도록 하는 것이 보안 면에서도 안전하다는 의견이 있기 때문이다.



API 권한 제어 (scope)

OAuth 2.0은 써드파티 어플리케이션의 권한을 설정하기 위한 기능이다. scope의 이름이 스펙에 정의되어있지는 않으며 여러 개의 권한을 요청할 때에는 콤마등을 사용해서 로그인 시에 scope를 넘겨주게 된다.


<OAuth 2.0 문제점>

  1. OAuth 1.0a에서는 token 과 함께 token 비밀번호를 같이 받는데 2.0에서는 이 토큰 비밀번호가 없어져서 실제로 클라이언트를 구분하기가 힘들어 졌다.
  2. OAuth 1.0a의 signature 기능을 없애서 SSL 기능에 의존함으로서 더 위험해졌다. 또한 이렇게 된 것은 기업 솔루션에 적용 되기위한 것이었다.
  3. OAuth 2.0에서 토큰 유효기간을 설정 할 수 있고 또 만료가 되면 갱신 되어야 한다. 이 변화는 OAuth 1.0 개발자들이 토큰 상태까지 관리해야 한다는 점에서 매우 커다란 변화이다. 이 기능은 자체적으로 인코딩 되어서 저장되는 토큰을 위한 것인데 이런 토큰은 권한을 취소(revoke) 하는데에 문제가 있기 때문에 또 다시 유효기간을 짧게 가져가게 된다.
  4. 권한 부여 방식
    OAuth 2.0에서는 너무 많은 방식을 지원 하고있다. 이는 여러 보안상의 문제점의 가능성을 의미한다.
    또한 OAuth 2.0을 IETF에서 시작한 것을 후회하는 말도 하면서, 그렇다고 딱히 다른 대안이 있는 것도 아니라는 의견도 밝힌다. 현재 워킹 그룹이 합의를 하지 못하고 있는 사항들에 리스트도 적었는데, 그만큼 OAuth 2.0스펙이 너무 포괄적이며 스펙은 더 많은 제한을 가지고 있고 많은 것이 결정되어있어야 한다는 이야기라고 그는 계속 주장 한다
4. API 사용자를 생성하는 좋은 방법은?
이 이슈는 API의 고전적인 이슈 중 하나이다. API인증을 하기위한 사용자를 생성하는 API는 어떻게 인증해야 하는가에 대한 이야기 이다. API를 사용해서 사용자를 생성한다면, CAPCHA 등의 방법을 사용할 수 없기 때문이다. 보통 다양한 조건체크, email 확인 등의 방법을 사용하기도 하지만, 가능하면 사용자 추가는 그냥 웹 브라우저상에서 직접 하도록 하는 것이 정답이다.

참고자료

http://v_lovepooh_v.blog.me/220620469795


저작자표시 비영리 변경금지

티스토리툴바