Oauth

Published: by Creative Commons Licence

OAuth

OAuth는 Open Authorization, Open Authentication을 뜻하는 것으로 애플리케이션(페이스북, 구글 등 Service Provider)의 유저의 비밀번호를 Third Party앱에 제공없이 인증, 인가를 할 수 있는 오픈 스탠다드 프로토콜이다. OAuth 인증을 통해 애플리케이션 API를 유저 대신에 접근할 수 있는 권한을 얻을 수 있다. OAuth가 사용되기 전에는 외부 사이트와 인증 기반 데이터를 연동할 때 인증 방식의 표준이 없었기 때문에 기존의 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조였다. 이 문제를 보안하기 위해 OAuth의 인증은 API를 제공하는 서버에서 진행하고, 유저가 인증되었다는 Access Token을 발급하여, Third party 애플리케이션에서는 Service Provider의 API를 안전하고 쉽게 사용할 수 있게 되었다.

OAuth의 흐름

API 인증과 권한 부여를 동시에 제공하는 인증 프로토콜을 찾다가, 적당한 것이 없다고 결론내리고 만든것이 OAuth 1.0이다. OAuth1.0은 2007년 10월에 확정되었으나 나중에 세션 고정 공격 보안 결함이 발견되어 OAuth 1.0a가 개선되어 나왔다.

1. OAuth1.0a의 장점

OAuth1.0a가 기존의 다른 인증과 구분되는 특징은 크게 두가지가 있다.

  1. API를 인증함에 있어 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증할 수 있다.
  2. 인증과 API 권한 부여를 동시에 할 수 있다.
    • OAuth1.0에서는 써드파티에게 비밀번호를 노출하지 않고 인증하는 방법으로 Open ID가 있었지만, 권한 부여의 기능을 가지고 있지 않았다.

2. OAuth1.0a 프로세스

OAuth1.0a process

  1. Consumer은 Service Provider로부터 Client key와 Secret을 발급받아야 한다. 이것은 Service Provider에 API를 사용할 것을 등록하는 것과 동시에 Service Provider가 Consumer임을 식별하게 해준다.
  2. Request Token의 요청과 발급 (A,B)
  3. 사용자 인증 페이지 호출(C)
  4. 사용자 로그인 완료
  5. 사용자의 권한 요청 및 수락 및 OAuth_token과 OAuth_verifier을 Consumer가 받는다.(D)
  6. Access Token 발급 요청(E)
  7. Access Token을 이용해 서비스 정보 요청(F)

3. 인증토큰의 장점

  • 사용자의 아이디/패스워드를 몰라도 토큰을 통해 허가받은 API에 접근 가능
  • 필요한 API에만 제한적으로 접근할 수 있도록 권한 제어 가능
  • 저장되어 있는 인증토큰이 유출되더라도 트위터의 관리자 화면에서 인증 토큰의 권한 취소 가능
  • 사용자가 트위터의 패스워드를 변경해도 인증토큰은 계속 유효

Authentication vs Authorization

  • Authentication : 인증
  • Authorization : 허가 일반 로그인은 회원가입할 때 사용했던 아이디와 비밀번호를 통한 인증이라면 OAuth2.0은 타사 서비스의 이메일 정보에 우리가 만든 서비스의 접근을 허락하여 사용자를 인증한다.

OAuth 2.0

  • OAuth1.0a에서 불편하다고 느꼈던 모바일에서 사용성 문제나 signature 생성과 같은 개발이 복잡하고 CPU를 많이 소비하는 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어 짐.
  • 개선된 점
    1. 간단해 졌다.
      • OAuth1.0a에서는 https가 필수가 아니었기 때문에 API를 호출할 때 Signature를 생성해서 호출해야 했다. OAuth2.0의 Bearer 토큰 인증 방식을 사용하면 signature가 필요없어 API 테스트를 하거나 예제를 만들 때, 간단하게 curl등 직관적인 방법을 사용해 문서화하고 개발 가능하다.
      • 기존 OAuth1.0은 디지털 서명 기반이지만 OAuth2.0의 암호화는 https에 맡김으로서 복잡한 디지털 서명에 관한 로직을 요구하지 않는다.
    2. 더 많은 인증 방법을 지원
      • OAuth1.0a 에서는 1가지 인증 방식을 제공한다. (HMAC을 이용한 암호화 인증 방식)
      • OAuth2.0은 시나리오별 여러가지 인증방식을 제공하여 웹 브라우저, 모바일 등 다양한 시나리오에 대응할 수 있게 해준다.
    3. 대형 서비스로의 확장성 지원
      • 커다란 서비스를 만들기 위해선 인증 서버를 분리할 수 있어야 하고, 인증 서버를 다중화 할 수 있어야 한다.
      • OAuth2.0에서는 API 서비스를 하는 서버와 인증 역활을 하는 authorization server의 역활을 명학히 구분하여 인증서버의 분리화 다중화에 대한 고려가 되어 있다.

OAuth2.0 에서의 용어

  • Resource Owner : 보호된 자원에 접근하는 권한을 제공한다(사용자).
  • Resource Server : acess token을 이용하여 요청을 수신할 때, 권한을 검증한 후 적절한 결과를 응답한다.
  • Authorization Server : 인증 서버, 클라이언트가 성공적으로 access token을 발급받은 이후에 자원 소유자를 인증하고 권한 부여를 한다.
  • Client : 써드파티 어플리케이션, resource owner의 보호된 자원에 접근을 요청하는 어플리케이션

Resource Server와 Authorization Server의 분리

  • 커다란 서비스는 인증 서버를 분리하거나 다중화 할 수 있어야 함.
  • Authorization Server의 역활을 명확히 함

OAuth2.0 flow

OAuth process

  1. client가 어떤 사이트를 이용해보려고 Facebook 가입 버튼을 눌러, 로그인 창이 나온 후 , 로그인을 한다. (A,B)
  2. 로그인을 하고 나면 서버에서 승인을 받아 B단계가 지난다.
  3. 로그인 후, 해당 사이트의 접근을 허용할 것인가? 확인 창이 나타나게 된다. 허용을 하게 되면 해당 사이트에서 로그인 목적으로 사용할 수 있는 Access token을 받게 된다. (C,D)

  4. ACess Token을 이용하여 서비스를 사용(E,F).

    OAuth process

  5. Client가 Resource Server Api를 이용한다고 Resource Server에 등록을 한다. Resource Server는 이 Client를 식별할수 있는 Client ID와 Client Secret를 발급한다.

OAuth process OAuth process

  1. Resource Owner가 Client에서 google 계쩡으로 로그인을 요청하여 Client는 Resource Owner에게 Resource Server의 로그인 창을 띄어주고 로그인을 한다. (A,B)

OAuth process

  1. Resource OWner는 Client가 Resource Server에 있는 자신의 정보에 접근에 대한 동의를 구하는 창을 보고 동의를 구한다.

OAuth process

  1. Resource OWner가 Client에게 Resource Server에 있는 자신의 정보에 접근을 허락했다면 Resource Server는 Client에게 일련의 암호화된 코드를 제공하고 이 코드와 함꼐 해당 정보의 사용을 등록했는지의 여부를 판단하는 ClientID와 Client Secret을 함꼐 보내 모든 것이 일치한다면 최종 접근 권한 부여의 암호인 Acess Token을 발급한다.

OAuth 인증 방법 (https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/ 더 보충하기)

  1. Authorization code
    • 웹 서버에서 api를 호출하는 등의 시나리오에서 confidential client가 사용하는 방식. 서버사이드 코드가 필요한 인증 방식이며 인증과정에서 client_secret가 필요하다.
  2. Implicit
    • OAuth1.0a와 가장 비슷한 인증 방식이다. public Client인 브라우저 기반의 어플리케이션이나 모바일 어플리케이션이서 이 방법을 사용하면 된다. Client 증명서를 사용할 필요가 없으며 실제 OAuth2.0에서 가장 많이 사용되는 방식이다.
  3. Resource Owner Passord Credentials
    • 2-legged 방식의 인증이다. client에 아이디/ 패스워드를 지정해 놓고 아이디/패스워드로 직접 access toekn을 받아오는 방식이다.
  4. Client Credentials
    • 어플리케이션이 Confidential Client일 때 id 와 secret을 가지고 인증하는 방식.

출처

  • https://minwan1.github.io/2018/02/24/2018-02-24-OAuth/

  • OAuth 1.0a VS OAuth2.0 비교 정리 글 : http://earlybird.kr/1584
  • OAuth2.0 : http://baked-corn.tistory.com/29

http://www.nextree.co.kr/oauth-2reul-iyonghan-sso-hwangyeong-gucug-2-2/