블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

OAuth 2.0 노트

아키텍쳐 /Security & IDM | 2014.08.11 17:05 | Posted by 조대협

OAuth 용어 정리

Resource Owner (사용자)

Authorization Server (인증서버

Resource Server (REST API)



 

OAuth 2.0 grant flow

Authorization code grant flow

주로 Web Application에서 사용됨

Implicit grant flow

자바스크립트 애플리케이션에서 많이 사용됨. 스크립트 단에서는 credential 등이 노출 될 수 있으니, 주로 Read only 용도로 많이 사용함. accessToken이 노출될것을 전제로 함.

모바일 애플리케이션도 많이 사용하는걸로 나오네??

Ÿ   Used in public clients

Ÿ   It's is a redirection-based flow (similar to the one in the authorization code grant)

Ÿ   The access token is received as a parameter of the redirection endpoint upon successful completion of the request, similar to the authorization code parameter in the authorization request response in the authorization code grant



Flow

     The first step is initiation of the flow. The client redirects the User agent to the Authorization server by using the authorization endpoint, the client identifier, and the redirection endpoint that will be used for the response.

     The Authorization server authenticates the Resource owner and requests his decision whether to authorize or deny the request.

     If the Resource owner authorizes the request (which is assumed), he is redirected back with response information, using the supplied redirection endpoint that was provided with the initial request. The response information is contained in the URL fragment that contains the access token and other parameters (we'll see the difference between a regular URL parameter and one found in a URL fragment in the detailed overview).

     Now that the User agent (the browser) is redirected back, the access token included in the response is passed to the Client application.

Client Server Application Case

Mobile App Case

(웹이 아니기 때문에, Redirect 처리를 어떻게 해야 할지 고민해야 함.

Samsung Account와 같이 전용 APK를 넣는 방식이나, 웹 페이지 Scrapping 방식등이 있음)

 

Resource owner password credential grant flow

직접 ID,PASSWORD를 보내는 방식으로, 1st level 파트너나 자사 시스템에 많이 사용.

기존의 HTTP BASIC이나 HTTP Digest 인증 방식을 migration하기가 용이함



     The resource owner (for example, the user) supplies the Client application with his username and password.

     The client application makes a request to the Authorization server, including the user's credentials and also his own identifier and secret.

     The Authorization server authenticates the client based on his identifier and secret, checks whether it is authorized for making this request, and checks the resource owner credentials and other parameters supplied. If all checks pass successfully, the Authorization server returns an access token in response.

Client credential grant flow

Userless 상태에서 많이 사용됨. (API 키와 유사한 방식)

 

 

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24

빠르게 훝어보는 node.js

#15  - Passport를 이용한 OAuth 2.0 API 인증 (Facebook 1/2)

조대협 (http://bcho.tistory.com)



REST 기반의 OPEN API 인증을 고민하다가 보니, 가장 많이 쓰이는게, OAuth 2.0이라서, OAuth 2.0을 보다보니, 도저히 이해가 안되겠다 싶어서, 간단하게 직접 구현해보기로 했다. OAuth 서버를 구현하기전에 먼저 테스트 클라이언트가 필요했기 때문에, node.js + passport 를 이용해서 facebook API를 호출하는 간단한 웹 사이트를 만들어보기로 했다.

Facebook API는 기본적으로 OAuth 2.0을 사용하고, Passport 모듈에서 잘 추상화된 라이브러리를 제공하기 때문에 쉽게 구축할 수 있으리라 생각했다. 실제로 구축해보니, 간단한 예제를 만드는데 약 1시간 30분 정도가 소요되었다.

자아 그러면 이제부터 Passport node.js를 이용해서 간단한 Facebook API를 호출하는 예제를 만들어보도록 하자.

OAuth 2.0

먼저 OAuth 2.0에 대한 개념을 알아보도록 하자. OAuth 2.0, 서비스에 대한 Authentication (인증) Authorization(권한 인가)에 대한 포괄적인 프레임웍이다. 특히 API 인증에 유용하게 사용될 수 있는데, 사용하는 애플리케이션의 타입(,모바일,자바스크립트)에 따라서 다양한 인증 메카니즘을 제공한다. 이를 grant type이라고 하는데, 대표적으로 4가지 형태의 grant type을 제공한다.

Ÿ   Authorization Code for webserver

Ÿ   Implicit for browser-based or mobile apps

Ÿ   Resource owner password credential for logging in with a username and password

Ÿ   Client credential for application access

다른 grant type에 대해서는 차차 소개하기로 하고, 오늘은 authorization code 방식의 grant type에 대해서 알아보도록 하자.

※ 다른 grant type에 대해서는 http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#web-server-apps 에 잘 정리가 되어 있다.

지금 구축하려고 하는 것은 facebook API를 내 서비스 웹서버에서 호출하는 시나리오이다.

Facebook API를 호출하기 위해서는 node.js 애플리케이션을 facebook 에 등록해야 한다. 이 등록은 facebook developer portal을 통해서 진행할 수 있는데, 아래 그림과 같이



1.  포탈에 node.js 사이트 관련 정보 (서비스 URL, CallBack URL, 서비스 명 등)을 입력하면,

2.  포탈에서 client_id client_secret을 발급해준다. client_id는 서버에서 발급되는 node.js 만든 서비스에 대한 id 라고 생각하면 되고, client_secret은 그 id에 대한 일종의 인증용 패스워드이다. (절대로 외부에 노출되면 안되는)

3.  이렇게 받은 client_id client_secret node.js 애플리케이션 내에 저장한다.

이렇게 해서 node.js 애플리케이션이 만들어졌으면 호출을 해보자. 호출은 다음과 같은 순서로 이루어 진다. 잠깐 용어를 짚고 넘어가면 OAuth 2.0에서는 Facebook 과 같이 Protected resource (API)를 제공하는 서버를 Resource Server 라고 하고, node.js와 같이 Protected resource (API)에 대한 접근을 요청하는 대상을 Client 라고 정의 한다. Client Resource Server에 접근할때, 사용자의 신분 (id,password)를 기반으로 하여, Resource Server에 접근하는데, 이러한 사용자를 User 라고 정의한다. 그러면 다음과 같은 흐름을 보자.



1.  먼저 사용자는 Web Browser에서, node.js 서버로 서비스를 요청한다.

2.  Node.js 서버는 사용자가 로그인이 되어 있지 않은 상태라면, Facebook log in URL에 대한 rediretion URL을 브라우져에게 보낸다. 이 때, node.js 서버임을 식별하기 위해서 client_id와 몇 가지 추가적인 정보를 보내는데, 그 내용은 다음과 같다.

Ÿ   client_id : 사용자를 통해서 인증을 요청하는 서비스가 앞에서 등록한 node.js 애플리케이션임을 알려준다.

Ÿ   redirect_url : 페이스북 인증서버에서 인증이 끝난후에, 인증 결과를 받을 node.js  애플리케이션으 HTTP URL을 정의한다.

Ÿ   scope : 페이스북에 접근을 요청한 리소스 목록을 정의한다. 예를 들어, 글쓰기, 읽기, 사진 올리기, 연락처 공유등과 같이 리소스에 대한 범주를 정의한다. Oauth 2.0의 특징중의 하나가 단순히 사용자 인증(Authentication)만을 하는 것이 아니라, 사용자가 소유한 리소스중, 접근을 허가 하는 권한 제어(Authorization) 기능을 함께 제공한다는 것이다.

https://oauth2 authorizationserver.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos

실제 facebook redirection URL

https://www.facebook.com/login.php?skip_api_login=1&api_key=253044994897796&signed_next=1&next=https://www.facebook.com/v2.0/dialog/oauth?redirect_uri=http://localhost:8080/auth/facebook/callback&scope=read_stream&response_type=code&client_id=253044994897796&ret=login&cancel_uri=http://localhost:8080/auth/facebook/callback?error=access_denied&error_code=200&error_description=Permissions error&error_reason=user_denied#_=_&display=page

3.  Browser Redirect URL을 받아서,페이스북의 인증 서버 URL Redirect를 한다.

4.  페이스북 인증 서버는 log in page를 사용자에게 보낸다.



5.  사용자는 사용자 ID PASSWORD를 입력한다.

인증이 되고 나면, scope에 의해서 리소스에 대한 접근 요청을 허가할 것인지를 물어보는데, 아래는 node.js 애플리케이션이 글쓰기 권한을 요청했을때 사용자에게 node.js 애플리케이션에 글쓰기 권한을 허용할지를 물어보는 화면이다.



6.  페이스북의 인증서버는 ID,PASSWORD를 인증과 권한 획득에 성공하면, 인증과 권한 획득에 성공했다는  Authorization Code와 함께, 다시 2에서 정의된 Service Consumer node.js server callback URL (redirect_url= redirect_uri=http://localhost:8080/auth/facebook/callback ) redirect request를 보낸다.

7.  Browser는 위에서 받은 Authorization code와 함께, 앞에서 받은 node.js 서버의 callback URL redirect를 한다.

http://localhost:8080/auth/facebook/callback?code=AQAKlwhopD1DD5(중략)

8.  Node.js 서버는 이 사용자가 인증 되었음  증명하는 받은 authorization code를 가지고, 페이스북의 authorization server에 문의한다.
POST https://api.oauth2server.com/token
    grant_type=authorization_code&
    code=AUTH_CODE_HERE&
    redirect_uri=REDIRECT_URI&
    client_id=CLIENT_ID&
    client_secret=CLIENT_SECRET

Ÿ   grant_type : grant type은 앞에서 설명한 4개중에서, 현재 사용하는 grant type authorization code 방식이기 때문에 이를 정의한다.

Ÿ   code : 앞에서 받은 authorization code

Ÿ   redirect_uri

Ÿ   client_id : node.js 서버를 인증하기 위한 client id. 앞서 developer portal에서 발급받아서, node.js 서버 애플리케이션안에 넣어놓았다.

Ÿ   client_secret : node.js 서버를 인증하기 위한 client_secret(password). 앞서 developer portal에서 발급받아서, node.js 서버 애플리케이션안에 넣어놓았다.

9.  페이스북의 authorization server는 이 authorization code를 가지고해당 요청이 인증되었음을 확인하고, node.js 서버에게로 API 접근을 허용하는 access_token을 발급한다.

10. Node.js 서버는 이 access_token을 가지고 페이스북 API에 접근을 요청하면, 페이스북 API서버는 access_token을 통해서 API 접근 가능 여부를 판단한 후, 인가된 요청인 경우 API 요청을 수락하여 서비스를 제공한다.

간단하게 authorization code 방식을 이용한 애플리케이션 인증 방식에 대해서 알아보았다. 몇가지 더 짚고 넘어가면, authorization code 방식의 장점은 node.js 서버가 사용자 id,password를 알수 없다. API를 제공하는 서비스 제공자 입장에서, 3’rd party (협력 파트너)에게 자사의 사용자 id,password를 노출 시킬 필요가 없기 때문에, 파트너를 대상으로 안전하게 서비스 사용자의 id,password 없이 사용자 인증을 진행할 수 있다.

아울러 access_token에 대해서 몇가지 짚고 넘어갈것이 있는데, access_token을 취득한 이후에는 별도의 사용자 인증 절차가 필요하지 않다. Node.js 서버에서 access_token만을 기억하고 있으면 해당 사용자에 대한 리소스를 호출하는 API를 이 access_token을 통해서 호출할 수 있다. (즉 호출할때 마다 매번 사용자 인증을 할 필요가 없다는 말이다.)


다음글에서는 실제로 Passport 모듈을 이용하여 Facebook Open API를 호출하는 방법을 설명하도록 하겠다.

괜찮은 책들 정리




Security Patterns in Practice

저자
Fernandez-Buglioni, Eduardo 지음
출판사
John Wiley & Sons (Asia) Pte. | 2013-06-25 출간
카테고리
과학/기술
책소개
Learn to combine security theory an...
가격비교

Security 전반에 걸쳐, 인증, 암호화, 인가등 다양한 시나리오에 대해서 패턴 중심으로 설명, 개념 잡기 아주 좋음



OAuth 2.0에 대해서 이해가 잘되게 설명된 책. 이거 보고 개념 잡았음



Beyond Software Archiecture

저자
Hohmann 지음
출판사
Addison Wesley | 2003-01-01 출간
카테고리
과학/기술
책소개
Successfully managing the relations...
가격비교

읽어야지 하면서 아직 못본책, 아키텍쳐 설계와 특히 라이센스 관리에 대한 디자인이 들어 있는 책




OAuth 2.0 based API 인증 메모

아키텍쳐 /Security & IDM | 2014.06.05 17:02 | Posted by 조대협


* Authroization Code

- Redirect base / 서버 백엔드가 있는 경우 사용 - 파트너사가 API를 사용하는 시나리오에 유리

* Implicit 

- Rediect base / 특히 Java script 처럼 서버 백엔드가 없는 경우 유용. Read Only 등에 사용

* Resource Owner Password Credential 

- Client Id, Secret을 앱에 넣은 후, Client Id/Password로 인증하여, access token을 발급 받는 방식으로, Authorization Server와 Resource Owner가 같은 서비스인 경우 유용함 (자사 API 제공에 유용)

* Client Crendetial


유용한 Link

  • 서버 구현체 : http://oauth.net/2/
  • http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified
  • node.js 모듈 - https://github.com/jaredhanson/oauth2orize
  • http://vinebrancho.wordpress.com/2014/05/19/oauth2-restapi-server-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EC%95%B1%EC%9D%84-oauth2-0%EC%9C%BC%EB%A1%9C-%EC%A2%80-%EB%8D%94-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C/


'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24