개발중인 앱을 좀 더 안전하게 서비스하기 위해서 만든 백엔드 서버 프로토타입인 oauth2-restapi-server을 공유하고자 한다. oauth2-restapi-server 은 모두 node.js 위에서 동작하며 OAuth2.0 스펙대로 동작하는 Authorization server와 Authorization server가 발행한 access token으로 리소스 접근을 관리하는 매우 기본적인 RESTful API server로 이루어져 있다.

https://github.com/vinebrancho/oauth2-restapi-server

 당연한 얘기지만, 앱이 사용자의 개인정보와 리소스를 안전하게 보호되는 것을 보장해주지 않는다면 그 앱은 사용자로부터 외면받게 될 것이다. 그래서 앱 개발 시 사용자 인증(Authentication)과 리소스에 대한 권한부여(Authorization)는 반드시 필요하고 제공되어야 한다. 앱 개발시 인증과 권한 부여하는 방법에 관해 OAuth, OpenID, SAML 등 몇가지 스펙이 있는데, 이중에서 가장 많이 사용되고 twitter, facebook, google등 메이저급 업체들이 사용하는 스펙이 OAuth 이다. OAuth는 현재 2.0 까지 나왔으며, 최종 버전(final version)은 RFC 6749 (http://tools.ietf.org/html/rfc6749) 이다. OAuth 2.0은 인증 및 권한부여에 관한 기본적인 흐름(flow)뿐만 아니라 implementor가 자기의 목적에 맞게 확장할 수 있도록 해준다. 이 때문에 OAuth 2.0은 프로토콜인 동시에 프레임워크라고 부르기도 한다. OAuth 2.0 으로 서버와 클라이언트 간 인증을 마치면 서버는 권한부여의 결과로써 access token을 발행해주게 되는데, 클라이언트는 이 access token을 이용해서 서버로 리소스 접근을 요청할 수 있다. 서버는 access token 기반으로 리소스 접근을 허용할지 말지를 결정하고, 결과 데이터를 클라이언트에게 보내줄 수 있다. 서버는 access token 기반으로 클라이언트를 인식하고 서비스하기 때문에, 세션(session)이나 쿠키(cookie)를 이용해 클라이언트의 상태정보를 유지할 필요가 없다. 이것은 REST(Representational State Transfer) 디자인 컨셉의 주요한 요구사항인 ‘stateless’ 특성을 만족시켜준다. 그렇다. OAuth2.0의 access token을 이용해서 서버는 RESTful API를 클라이언트에게 제공할 수 있다. 실제로 OAuth2.0 을 제공하는twitter, facebook, google, yahoo, linkedin등 메이저급 앱의 서버들은 access token 기반의 RESTful API를 제공하고 있다. OAuth2.0에 대한 내용은 스펙문서 자체를 참고하길 바라며, 지금부터는 구체적으로 아래 내용들에 대해 살펴보고자 한다.

• 앱스토어에 올릴 1st party client 에 OAuth2.0의 어떤 권한부여 타입을 적용할 것인가?
• 인증 및 권한부여를 하는 authorization server는 어떻게 구현 하지?
• 발행된 access token 기반으로 동작하는 RESTful API server는 어떻게 구현 하지?
• oauth2-restapi-server 소스코드

잠깐, 문득 용어 정리가 필요할 듯 하다. 관점에 따라 앱은 다음과 같이 구성된다.

• 사용자 관점에서 프론트엔드(front-end)와 백엔드(back-end)
• 시스템 관점에서 클라이언트(client)와 서버(server)

앱 개발시 프론트엔드와 클라이언트, 그리고 백엔드와 서버는 동일한 의미로 사용된다. 클라이언트는 1st party client와 3rd party client 로 나눠진다. 1st party client 는 업체가 서비스를 위해 제공하는 공식 클라이언트이며 직접 사용자의 id와 password를 입력받을 수 있다. 그리고 3rd party client는 서비스에 접근하는 외부 클라이언트이며, 보안상의 이유로 해당 서비스 접근을 위해서 사용자로부터 직접적으로 id와 password 입력을 받지 못한다 (id, password 정보가 다른 앱에 저장될 위험이 있으니깐 말이다). OAuth2.0에서 서버는 authorization server와 resource server로 나눠진다. authorization server는 클라이언트들을 인증하고 access token을 발행해주는 서버이다. resource server는 클라이언트의 API 요청을 access token 기반으로 처리하는 서버이며 흔히 얘기하는 API server 이다. 자세한 것은 OAuth 2.0 스펙을 참고하기 바란다. OAuth를 이야기할 때는 클라이언트와 서버라는 용어를 사용하며, 본 글에서도 이 용어들을 사용할 것이다. 

앱스토어에 올릴 1st party client 에 OAuth2.0의 어떤 인증 타입을 적용할 것인가?

---

위에서도 언급했듯이  1st party client 는 특정 서비스를 위한 공식 클라이언트이다. 이 때문에 1st party client 는 등록된 사용자로부터 직접 id 와 password를 입력받아서 Authorization server 를 통해 사용자 인증을 하는데 그것들을 쓸 수 있다. 이러한 특성을 고려했을 때, 클라이언트 및 사용자 인증에 가장 적합한 인증 타입은 ‘Resource Owner Password Credentials’ 임을 찾을 수 있었다.

OAuth2.0 스펙에선 아래 4가지 타입의 인증 방식을 소개하고 있다.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

간략하게 핵심 내용을 설명하자면, Authorization Code와 Implicit 타입은 OAuth2 스펙을 보면 credential client 즉, 서비스에 접근하는 외부 앱을 위한 타입이다. Authorization Code는 자신만의 백엔드 서버를 갖고 동작하는 앱일 경우에, Implicit는 백엔드 서버 없이 순수 클라이언트 사이드에서만 동작하는 앱일 경우에 사용한다. 이들 외부 앱은 보안상의 이유로 사용자의 id와 password를 직접 입력 받지 못하기 때문에, access token을 얻기 위해서는 먼저 해당 서비스로 이동하여 사용자 확인(로그인) 및 허락을 받아야 한다. 이를 위해 외부 앱은 새로운 window 또는 webview 를 생성해서 해당 서비스의 Authorization server url에 client id와 callback url을 붙여서 리다이렉션 시킨다. Authroization server는 client id와 callback url을 검사하여 요청한 client가 developer site를 통해 등록된 정상적인 client인지 확인하는데 사용한다. 그리고 리다이렉션된 페이지에서 사용자가 id, password 로 로그인(Authentication)을 하고 해당 외부 앱이 자신의 데이터를 엑세스하도록 허용하면 (보통 ‘Allow’ 해당하는 버튼을 클릭함), Authorization server는 해당 외부 앱의 callback url에 인증타입에 따라 code 또는 access token을 붙여서 리다이렉션 시킨다. ‘Authorization Code’ 타입일 경우 callback url에 code가 붙으며, 외부 앱은 이 code 값과 해당 서비스에서 발급해준 자신의 client id와 secret 을 Authorization server로 다시 보내어 access token을 발급 받는다. 그리고 ‘Implicit’ 타입일 경우 바로 callback url에 access token정보가 fragment로 붙어서 넘어가는데 ‘Authorization Code’ 타입보다 간소화된 타입이라 보면 된다. client 는 사용자의 단말 또는 PC 에 설치되기 때문에 하드 코딩된 client id 값이 노출될 수도 있다. 그래서 client id 값만으로 access token을 받아오는 ‘Implicit’ 타입은 보안상 약간 위험할 수 있다. 그러나 ‘Authorization Code’ 의 경우, Authroization server와 통신하는 주체가 client가 아니라 백엔드 서버이고 client id와 secret이 백엔드서버에 저장되어 사용되기 때문에 노출될 여지가 없기 때문에 좀 더 보안상 좋다고 할 수 있다. 아무튼 이 두 타입의 인증방식은 용도상 외부 앱이 내 서비스에 접근하기 위한 것으로써 1st party client 인증용으로는 적절하지 않다. 그리고 마지막의 ‘Client Credentials’ 타입은 어떤 사용자든 상관없이 클라이언트 그 자체만을 인증하기 위한 방식으로써 사용자별로 인증하여 access token을 발행해야 하는 1st party client 인증용으로는 역시 적절하지 않다.

마지막으로 남은 ‘Resource Owner Password Credentials’. 이 타입은 아래의 OAuth2.0 스펙의 설명을 보면 1st party client 으로 적절해 보인다. 아 처음 스펙을 읽을 땐 왜 이렇게 이 문장이 ‘1st party client 를 위한 것이다!’ 라고 느껴지지 않았는지 모르겠다. 그냥 속시원하게 ‘1st party client 을 위해 적절하다’ 라고 명시해놓았으면 좋았을 것을 ㅠㅠ;

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application (4.3)

1st party client 는 자신의 Authozation server 에 인증 요청을 하는 것이므로, 어떤 페이지로의 리다이렉션 없이 직접 사용자의 id, password를 입력받고 자기의 client id와 secret을 Authorization server로 인증 및 access token을 요청한다. 이 경우, 1st party client 는 사용자 단말에 설치되어 있어서 하드 코딩된 client id 와 secret 이 노출되는 것이 위험할 수도 있으나, 이 타입의 경우 사용자의 id, password 를 함께 보내야만 인증 가능하므로 사용자 id, password 만 단말 어딘가에 저장하지 않는다면 안전하다고 할 수 있겠다. 그래서 OAuth2.0 스펙에도 access token을 얻은후에 client는 반드시 사용자의 credentials 즉, id와 password를 제거해라고 언급되어 있다.

The client MUST discard the credentials once an access token has been obtained. (4.3.1)

결론은 1st party client 에는 ‘Resource Owner Password Credentials’ 타입을 적용하자! 이다.

 

인증 및 권한부여를 하는 authorization server는 어떻게 구현 하지?

---

우선 1st party client 만 배포하는 나로써는 Authorization server 구현시 ‘Resource Owner Password Credentials’ 타입만 고려하면 되지만, 혹시나 나중에 외부 앱이 나의 서비스에 접근해야 하는 요구사항이 생길 수도 있으니 미리 다른 인증 타입도 고려해서 만들면 낫지 않을까 생각했다. 그리고 어차피 node.js 로 백엔드를 구성하고 있기 때문에 Authorization server 역시 node.js 로 구현했다.

1.  유용한 node.js 사용하기

• oauth2orize
• https
• passport-http
• passport-oauth2-public-client

oauth2orize 는 OAuth2.0 스펙의 핵심 flow를 node.js 형태로 구현해놓은 모듈이다. 요청된 인증 타입(grant_type)에 따라 개발자가 등록해놓은 callback function을 호출해주고, 해당 function이 리턴한 결과를 적절히 http response로 만들어서 client에게 응답해주는 모듈이다. 나는 이 모듈을 이용해서 oauth2-restapi-server 의 뼈대를 만들 수 있었다. oauth2-restapi-server가 express 모듈을 사용하고 있기 때문에 아래에서 설명할 Authorization API 가 호출될 때,  oauth2orize의 grant, exchange, errorHandler가 실행되도록 oauth2orize 기능들을 모든 Authorization API에 express의 middleware로 지정하였다.

https 는 TLS (Transport Layer Security) 기반으로 서버가 동작할 수 있도록 해주는 모듈로써 client와 Authorization server 간 주고 받는 패킷에 적용하기 위해서 사용했다. 나는 Authorization server에 self signed certificate를 만들어서 client와 주고 받는 패킷을 encryption / decryption 하도록 만들었는데 실제 product 시점엔 공인된 CA로부터 발급받은 certificate 를 사용해야 하지 않을까 싶다. 그리고 http 로 요청이 들어와도 https 로 리다이렉션이 되도록, 리다이렉션 기능을 모든 API 에 express의 middleware로 지정하였다.

passport-http 는 Authorization server가 client id 와 secret으로 client 검증을 해야 하는 경우에 사용한다. ‘Authorization Code’ 타입의 client가 code로 access token 을 요청하는 경우, ‘Resource Owner Password Credentials’ 타입의 client가 access token을 요청하는 경우, (잘 쓰이지는 않지만) ‘Client Credentials’ 타입의 client가 access token을 요청한 경우가 해당된다. 이 모듈은 http header의 ‘Authorization: Basic’ 뒤에 base64로 인코딩된 스트링을 파싱하여 client id와 secret을 개발자가 등록한 callback function으로 넘겨준다. client id와 secret이 유효한지 여부를 검사하는건 개발자의 몫이다.

passport-oauth2-public-client 는 Authorization server가 client id 만으로 client 검증을 하는 경우에 사용한다. ‘Authorization Code’ 타입의 client가 access token 요청 전 code 자체를 얻기 위해서 요청하는 경우, ‘Implicit’ 타입의 클라이언트가 access token을 요청하는 경우가 해당된다. 이 모듈은 http body의 ‘client_id’ 값을 개발자가 등록한 callback function으로 넘겨준다. client id가 유효한지 여부를 검사하는 건 개발자의 몫이다.

2. Authorization을 위한 API 설정

1st party 든 3rd party 든 모든 client들은 인증 및 access token을 요청하기 위해서 url 형태의 API를 통해서 접근한다. 아래의 API로 4가지 인증 타입의 요청을 모두 받아들일 수 있다.

1. /oauth2/authorize
2. /oauth2/authorize/decision
3. /oauth2/token

1, 2 번 API는 ‘Authorization Code’ 와 ‘Implicit’ 타입의 인증방식에서만 사용된다. 즉, 3rd party client 가 사용하게 되며 2번 API의 응답 결과가 해당 client가 등록될 때 지정한 callback url 뒤에 붙어서 넘어가게 된다. 응답 결과는 위에서 설명한대로 인증 타입에 따라 code또는 access token 둘 중 하나이다. 3번 API는 ‘Authorization Code’, ‘Resource Owner Password Credentials’, ‘Client Credentials’ 타입의 인증방식에서 사용된다. API 요청시 client는 OAuth2.0 스펙에서 요구하는 header와 body를 만들어서 요청해야 하며, authorization server는 이 값들을 파싱하여 client 검증 또는 사용자 검증을 하는데 사용해야 한다. API 사용법에 대한 자세한 설명은 oauth2-restapi-server github 페이지를 참고하길 바란다.

authorization의 의미대로 권한부여를 제대로 하려면 client 별로 사용자별로 접근할 수 있는 리소스를 제한하는 기능이 있어야 한다. 이를 위해 OAuth2.0 스펙에서는 ‘scope’ 이라는 필드가 있는데 제대로 authorization server를 만드려면 리소스에 대한 scope를 정의하고 http body의 ‘scope’ 필드를 활용할 필요가 있다. 여기서는 주제를 벗어나므로 자세한 내용은 생략한다. oauth2-restapi-server 는 아직 ‘scope’ 필드를 활용하고 있지 않다. 그래서 발행되는 모든 access token 은 API server 내 특정 사용자의 모든 자원에 대해 read/write 가능하다.

3. 필수 database 설정

OAuth2.0 스펙대로 동작하려면 기본적으로 아래와 같은 데이터를 Authorization server가 갖고 있어야 한다.

• 등록된 client들의 id 와 secret 정보 (보통 developer site 에서 각 client 개발자가 등록함, 난 테스트를 위해 디폴트로 하나씩 등록함)
• 등록된 사용자들의 id 와 password 정보
• access token을 얻기 위해 발행된 code 정보 (‘Authorization Code’ 타입을 위해서만 사용)
• 발행된 access token 정보

나는 mongoose 모듈을 이용해 authorization server가 mongo db 에 이러한 정보들은 저장하고 검색하고 삭제하도록 구성하였다.

4. 테스트를 위한 4가지 인증 타입별 client 정보를 등록

authorization server는 모든 요청에 대해 client 검증을 하기 때문에 타입별로 client 정보를 등록할 필요가 있다. 등록을 위한 developer site 가 있다면 편리하겠지만 여력이 없어서 단순히 authorization server가 런칭될 때, 디폴트로 client 들이 등록되도록 하였다. 이 때 등록되는 정보들은 다음과 같다.

• client name *
• client id *
• client secret *
• token refresh 여부 *
• callback url

‘ * ‘ 붙은 정보는 mandatory 이며, callback url은 ‘Authorization Code’와 ‘Implicit’ 타입에서만 사용된다.

5. 인증 및 access token 발행 테스트

각 타입별로 client 를 만들어서 확인해보면 가장 좋겠지만, Authorization server에게 요청/응답 받는 건 ‘postman’ 같은 http client로도 충분하다. 나는 크롬의 extension인 ‘postman’을 사용해서 위의 4가지 타입의 client들을 API로 검증할 수 있었다. 1st party client를 위한  ‘Resource Owner Password Credentials’ 타입에 대해서는 특별히 angular.js 기반의 client를 만들었다.

6. access token 저장 및 소셜 앱을 위해 확장한 기능

angular.js 기반의 1st party client는 local account로 로그인한 직후, ‘Resource Owner  Password Credentials’ 타입으로 access token을 요청하고 받아온다. 그리고 해당 access token은 local storage에 보관하여 client 종료후 다시 실행시 local storage에서 읽혀 다시 사용된다 (만약 명시적으로 authorization server에 API로 logout을 요청하면 authorization server는 해당 client와 사용자를 위해서 생성했던 access token을 제거하고, client 역시 local storage에 저장된 access token을 제거한다). 개인적으로 고민했던 부분은 access token을 받아온 후 client가 이것을 어떻게 보관하느냐 하는 부분이었다. 현재로써 결론은 client 가 access token을 저장할 필요가 있으니, Android/iOS 플랫폼에서 app isolation을 보장해준다는 가정하에 client가 살아있는 동안 영구적으로 보관하기 위해  local storage를 선택했다.

이 angular.js client는 local account 로 signup 및 login을 지원하며, 외부 social account 로 연결(connect)이 가능하다.  소셜 앱을 개발한다면 사용자들의 편의를 위해서 local account 를 생성하는 것 없이 1st party client 가 twitter, facebook 같은 외부 social account 인증만으로도 signup을 해줄 필요가 생긴다. 이 경우에 사용자의 social account로 1st party client를 로그인 한 후 RESTful API로 내부 리소스를 접근하려면 access token이 필요하다. local account 가 아닌데 ‘Resource Owner Password Credentials’ 타입을 어떻게 이용하지? 고민을 하다 생각해낸 아이디어는 1st party client가 social account로 login 하게 되면 결과값으로 twitter 등 해당 social 서버가 발행해준 access token을 client로 보내주고, client는 http body의 ‘username’과 ‘password’ 필드에 각각 해당 서비스 이름과 해당 서비스의 서버에서 발행해준 access token을 넣어주도록 하는 것이다. 그럼 authorization server는 ‘username’이 local account의 사용자 id가 아닌 서비스 이름일 경우 password에 있는 access token 값으로 내부 database를 검색하여 등록된 social account인지 체크 후, RESTful API 사용을 위해서 access token을 발행해주는 것이다. 테스트 결과 잘 동작하였으며 외부 social account을 지원하는 앱을 만드는 경우라면 참고해도 될 것 같다.

 

 발행된 access token 기반으로 동작하는 RESTful API server는 어떻게 구현 하지?

---

client가 Authorization server를 통해 access token을 얻었다면, 그 access token을 갖고 특정 리소스에 접근하기 위해서 API를 호출할 것이다. 이 때 API server는 오직 access token 하나만으로 해당 요청을 받아야 할지 말지를 결정하고 적절히 그 요청을 처리해야 한다. OAuth2.0에서는 client로부터의 API 요청시 authorization server와 API server 중 누가 access token의 유효성을 검사해야 하는지 정해놓지 않았다. 그래서 implementor가 성능, 보안을 고려해서 자신의 상황에 맞게 선택해야 한다. 나의 경우 API server가 직접 access token 을 검사하도록 만들었다. API server 역시 node.js 로 구현하였고 내용은 다음과 같다.

1. 유용한 node.js 모듈 사용하기

• https
• passport-http-bearer

API server 에 역시 안전하게 client와 패킷 교환을 해야하기 때문에 https 를 적용했다.

passport-http-bearer 는 http header에 있는 ‘Authorization Bearer:’ 뒤에 있는 스트링인 access token을 개발자가 등록한 callback function으로 넘겨준다. access token 이 유효한지 여부를 검사하는 건 개발자의 몫이다. API server는 자신에게 들어온 API 요청을 처리하기 전에 전달받은 access token이 유효한지 검증하는데 이 모듈을 사용한다.

2. 리소스 접근을 위한 API 설정

개발하는 앱에 따라 리소스를 정의하고 그 리소스에 접근할 RESTful API를 정의할 필요가 있다. RESTful API는 보통 다음과 같은 특징들을 제공한다.

• Uniform Interface (hyper media를 이용, http의 헤더, 바디, url을 통해 인터페이스를 정의)
• Stateless (session을 사용하지 않는다. 그래서 서버의 물리적 확장성 높임)
• Cacheable (동일한 요청은 캐쉬데이터로 전달)
• Client-Server (client 코드가 서버 독립적으로 작성가능, 서버 또한 client 독립적으로 제작 가능)
• Layered System (client 상태를 유지하지 않기 때문에 중간 서버들을 추가하여 layer서버구조 가능)
• Code on Demand (optional한 특징이며, cilent에서 실행할 코드를 미리 생성하여 전달)

RESTful API를 정의하려고 한다면 우선 아래의 자료들을 읽어보는 것이 좋을 듯하다.

• https://s3.amazonaws.com/tfpearsonecollege/bestpractices/RESTful+Best+Practices.pdf
• http://www.restapitutorial.com/lessons/whatisrest.html
• http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
• http://spoqa.github.io/2013/06/11/more-restful-interface.html

 

oauth2-restapi-server 소스코드

---

아래 github 주소로 실행가능한 소스코드를 올려두었다. OAuth2.0 authorization server나 access token기반 API server를 이해하고 설계하는데 entry point로 도움이 되었으면 한다. 현재 oauth2-restapi-server 는 authorization server와 API server가 하나의 process 로 실행된다. 서버 아키텍처에 따라 이 두 server는 분리될 수도 있기 때문에 최대한 코드 레벨에서 서로 디펜던시를 갖지 않도록 만들었다.

github: https://github.com/vinebrancho/oauth2-restapi-server

• authorization server :
  • https://github.com/vinebrancho/oauth2-restapi-server/tree/master/oauth2_server
• basic RESTful API server :
  • https://github.com/vinebrancho/oauth2-restapi-server/tree/master/api_server
• sample 1st party client :
  • https://github.com/vinebrancho/oauth2-restapi-server/tree/master/public
• database :
  • https://github.com/vinebrancho/oauth2-restapi-server/tree/master/model

 

마치며..

---

안전하게 앱과 사용자를 인증하는 방법으로 OAuth2.0를 살펴보았고, 실제로 본인이 node.js 로 구현한 authorization server와 API server를 토대로 몇가지 주요한 내용을 살펴보았다. OAuth2.0은 많은 논의 거쳐 final version이 나왔고 현재 여러 서비스 업체들이 사용하고 있기 때문에 나름(?) 믿고 적용할만한 프로토콜이다. 앱 인증과 RESTful API를 고려중인 개발자들에게 작은 도움이 되었으면 하는 바램으로 글을 마무리한다.

 

현재 많이 사용되는 social network 몇개를 내 앱에서 oauth로 인증하기 위하여 먼저 node.js로 프로토타입을 위한 앱을 만들어봤다. 3rd 앱에서 oauth로 다른 social network의 사용자를 인증하는 것을 보통  social login 또는 social authentication 이라고 부른다. 통계를 보면, social login을 위해 가장 많이 사용되는 계정들은  facebook, google+, yahoo, twitter 순이다.

The landscape of social login: Facebook makes a comeback

신규 앱에서는 사용자 인증관련해 social login을 많이 사용하는 추세인데 이것은 사용자에게 편리함을 준다. 왜냐하면 별도의 가입절차 없이, 이미 등록된 다른 social network의 계정으로 신규 앱에 로그인을 할 수 있게 해주기 떄문이다.  뿐만 아니라 oauth 인증 결과로 받은 access token을 이용해 신규 앱은 허용된 범위에서 해당 social network 제공자에게 어떤 자원에 대해 read/write를 요청할 수도 있다. 예를 들면 사용자가 word press 에 twitter 계정을 연결(connect)시켜서 write권한이 있는 access token을 얻게한 다음, 나중에 word press에 포스팅했을 때 자동으로 자신의 twitter 계정에 tweet이 남겨지도록 할 수 있다.

social login은 주로 OAuth 또는 OpenID 방식으로 구현이 된다.  현재 주요 social network 제공자들은 OAuth 방식을  채택하고 있기 때문에, 3rd 앱들은 OAuth로 social login 기능을 구현하고 있다. OAuth스펙은 OAuth1.0, OAuth1.0A를 거쳐 현재 OAuth2 까지 나온 상태이다.  OAuth2가 기존 OAuth의 단점을 커버하고 있기 때문에 OAuth2를 많이 사용하는 추세이다.

나는 node.js 로 social-logins 앱을 만들어보았는데 이 때 사용한 주요 node.js 모듈은 다음과 같다. 나의 social-logins 앱은 위에서 얘기한 3rd 앱이 된다.

• express 4.0 모듈과 passport 모듈
• social network 별 passport strategy 모듈
• mongodb 와 mongoose 모듈

social-logins 앱이 제공하는 기능은 다음과 같다.

• email, password 기반의 로컬 계정 생성 (sign up) , 로컬 계정 로그인 (log in, or sign in)
• social network 계정으로 로그인
• 프로필 페이지에서 로컬 계정 정보 표시
• social network 계정 연결(connect), 해제 (disconnect) 제공
• 로그인 또는 연결된 social network 계정 기본정보를 프로필에 표시

로컬 계정과 더불어 기본으로 지원되는 social network 계정은 다음과 같다.

• Twitter (OAuth1.0A)
• Facebook (OAuth2)
• Google+ (OAuth2)
• Yahoo! (OAuth2)
• LinkedIn (OAuth2)
• GitHub (OAuth2)

social-logins 앱 소스 코드는 나의 github 저장소에 올려두었다.

https://github.com/vinebrancho/oauth2-restapi-server/tree/node_server_render_ver

node.js로 social login 구현시 OAuth를 핸들링을 하는 passport strategy 모듈이 이미 만들어져 있다면, 해당 social network 계정을 붙이는 작업은 쉽게 가능하다. 하지만 passport strategy 모듈이 없다면 OAuth 처리를 위해 해당 social network의 개발자사이트에 명시된 스펙을 꼼꼼히 체크하면서 개발해야 한다. 위에 나열한 것들은 각각의 passport strategy 모듈이 존재하기 때문에 social login을 구현하는데 많은 시간이 들지 않았다.

UI를 가지는  front-end 영역은 브라우저의 페이지, 또는 iOS, Android 네이티브 앱, 또는 webview를 가진 네이티브 앱인 hybrid 앱  형태가 될 수도 있다. 나의 social-logins 앱은 기능 검증이 목적이어서 fron-end는 단순히 브라우저의 페이지로 제작했다(추후 angular.js와 bootstrap 기반으로 리팩토링 예정). 아래는 social-logins 앱의 스크린샷이다. (난 UI 에는 정말 소질이 없나보다 -_-;;)

social-logins 앱 로그인

social-logins 앱의 로컬 계정 생성

로컬 계정으로 로그인 후 프로필 페이지

로그인 화면에서 트위터 계정으로 로그인하여 생성된 새로운 프로필

하나의 유저에 여러 social network 계정을 연결(connect)한 후.  (브라우저 사이즈상 스크롤하여 나눠서 스샷했음, 아래 사진들은 같은 페이지에 있음)

마치며..

사용자의 편의를 위해서, 새로운 앱을 만들 때 social-login 기능은 이제 필수인거 같다. 그리고 많은 사용자를 갖고 있는 social network 들은 이미 OAuth 기반의 사용자 인증을 위한 RESTful API를 제공하고 있고 검증해본 결과 잘 동작한다. 물론 node.js로 앱을 만들면 이미 RESTful API 처리를 해주는 것들이 모듈로 개발되어 있는 상태라 기능 OAuth 검증이 매우 쉽다. 앱 개발자들은 로컬 계정 뿐만 아니라 social network 계정도 지원하여 사용자가 좀 더 편리하게 앱을 이용할 수 있도록 하면 좋을 것 같다.

 

< References >

– http://oauth.net/2/

– https://github.com/jaredhanson/passport

– https://github.com/jaredhanson/passport/wiki/Strategies

– http://scotch.io/tutorials/javascript/easy-node-authentication-linking-all-accounts-together

node.js (이하 node)는 공식적으로 event loop 이 수행되는 main thread 에서만 v8엔진 기반의 javascript 실행환경을 제공한다. node 는 자신의 프로세스 내/외부에서 발생하는 모든 request를 main thread를 통해 처리한다. 이 때문에 main thread 를 잠깐 멈추게 하는 cpu-intensive javascript 코드를 수행해야 하는 usecase는 node에서 사용하기엔 무리가 있다. 이것이 node의 제약이기도 하다. 그러나 node로 꼭 그러한 작업를 수행해야 한다면 어떻게 해야 할까. 언제든 제약 또는 단점으로 여겨지는 문제를 푸는 일은 재미있는 일이다. node에서 cpu intensive 작업을 수행하면서도 node가 멈추지 않고 동작하게끔 할 수 있는 몇가지 방법을 정리해보려 한다. 

* 이글에서 말하는 cpu intensive 작업은 cpu를 연속적으로 사용하는 javascript 코드로써 코드 수행이 끝날때까지 자신을 호출한 caller에게 결과를 리턴하지 않는 작업을 의미한다. 

1. child_process 모듈

node 프로세스를 fork하여 새로운 node 프로세스를 생성하는 것이다. 즉, 자식 node 프로세스를 만드는 것이다. 아래의 코드처럼 child_process를 fork하면서 child process가 수행해야 할 javascript 파일을 지정할 수 있다.
[gist 981c240f2fa24b7d9dfc]

 child process는 지정된 javascript 코드를 수행하면서 수행한 결과를 메시지를 통해 parent process에게 전달해줄 수 있다. 물론 parent process가 이 메시지를 받기 위해서 listen하고 있어야 한다. child process를 fork해서 cpu-intensive 작업을 수행하도록 하면 원래 node 프로세스는 계속해서 event loop을 수행하며 다른 요청들을 처리할 수 있다. 그러나 child_process 를 사용시 고려해야 할 것이 있다. 그것은 child 프로세스가 또 하나의 node 프로세스라는 것이다. 이것은 child 프로세스가 부모처럼 node를 위한 각종 초기화 작업을 수행한 후 지정된 javascript 코드를 수행시킨다는 의미이다. node 초기화 작업은 크게 다음과 같다.

 – v8 초기화 및 Isolate, Context 생성
 – uv event loop 생성 및 non-blocking 작업을 위한 thread pool 생성 (현재 4개)
 – ‘process’와 ‘module’ js object 생성, 각종 builtin 모듈 로딩

음, cpu-intensive 작업을 위해 이런 비용을 들이면서 프로세스를 생성하는 것은 그렇게 나이스해 보이지 않는다.  child_process 모듈은 쉘 명령어를 수행해서 표준출력으로 결과를 parent process에게 보내는 용도가 더 적합하지 않을까 싶다. 그러나 node 프로세스 생성 비용이 큰 문제가 되지 않는 시나리오라면 사용해도 괜찮을 것 같다. 

2. cluster 모듈

cluster 모듈은 내부적으로는 child_process 모듈의 fork 메소드를 사용해서 구현하기 때문에 위에서 언급한 node 프로세스 비용이 고스란히 발생한다. 무엇보다 cluster 모듈은 cpu core를 모두 활용함으로써 동시 발생하는 외부 요청들을 더욱 많이 처리하여 scalability를 높이기 위해 만들어졌다. 그러므로 cpu intensive 작업을 처리하는데 있어서는 cluster 모듈 사용은 적절하지 않은 것 같다. 
[gist df60c43becedbfe94b51]

3. threads-a-gogo 모듈

cpu intensive 작업을 위해서 별도의 프로세스를 생성하는 것보다는 이미 실행중인 node 프로세스안에 새로운 thread를 생성하여 javascript 실행환경을 만들어주는 것이 비용과 반응성 측면에서 더 나아보인다. v8의 javascript 실행환경을 위해서는 반드시 v8::Isolate과 v8::Context가 필요하다. 새롭게 생성된 thread는 이미 만들어진 v8::Isolate 를 쓸 수도 있고, 아니면 새롭게 만들어서 쓸 수도 있다. main thread가 다른 thread와 javascript 오브젝트들을 공유하려면 javascript 실행환경이 같아야 한다. 이말은 같은 v8::Isolate를 사용해야 한다는 것인데, 이렇게 되면 동시에 두 thread가 javascript 코드를 수행할 수 없다. 왜냐하면 v8이 하나의 v8::Isolate은 자신을 lock을 하고 있는 하나의 thread에 의해서만 사용되도록 제한하고 있기 때문이다. main thread의 javascript 수행이 멈추지 않도록 하려면 새로운 thread에 새로운 v8::Isolate과 v8::Context를 생성해줘야 한다. main thread는 콜백이나 메시지 전달을 통해 결과를 받을 수 있어야 할 것이다. 찾아보니 방금 말한 것을 구현한 node 모듈이 있었다. 
threads-a-gogo 모듈이다. (이름이 아주 독특한데 왜 gogo라고 했을까 a는 뭐지-_-;ㅋ). threads-a-gogo의 목적자체가 cpu-intensive 작업을 main thread가 아닌 별도의 thread에서 처리하도록 하는 것이다. 별도로 생성된 thread는 작업이 완료되면 main thread에게 콜백 또는 메시지로 결과를 알려줄 수 있다. 아래는 별도의 thread를 생성하고 계산작업을 시킨후 그 결과를 main thread 내 콜백으로 호출하는 예이다. 
[gist 2d12240c4fd64d8c2eab]

threads-a-gogo가 생성하는 thread는 pthread이며 main thread의 v8::Isolate를 사용하지 않고 별도의 v8::Isolate과 v8::Context을 생성하여 사용한다. 즉, main thread가 생성한 어떤 v8 object도 접근할 수 없을뿐만 아니라 다른 thread과도 어떤 v8 Object도 공유할 수 없다는 의미이다. 생성된 thread는 독립적으로 javascript 코드 또는 파일을 수행하고 main thread에게 결과만 전달한다. 아래 코드는 thread-a-gogo의 c++ addon에서pthread_create를 호출할때 start_routine 인자로써 전달하는 함수이다.  
[gist b14b66d0cd11ba6ce64c]

4. webworker-threads 모듈

HTML5의 Web Worker 스펙을 구현한 node 모듈이다. 서버 사이드에서 web worker를 쓸 수 있게 했다는 것만으로도 좋은 시도라 생각한다. 바로 위에서 소개한 threads-a-gogo 모듈을 이용해서 thread 처리를 하고 있다. 아래 소스는 threads-a-gogo의 예제를 web worker버전으로 바꿔본 것이다.
[gist 12008430e591d3209699] 

목적 자체가 threads-a-gogo와 같고 thread 내부 동작도 동일하나 개발자들에게 노출된 javascript API만 다르다. 둘 중 맘에 드는 걸 선택해서 쓰면 되겠으나, Web Worker 스펙은 W3C에 의해 만들어졌고 클라이언트 사이드에서 많이 사용되고 있어 레퍼런스도 많으니 이왕이면 webworker-threads 모듈을 사용하는게 좋을 듯하다.

5. JXCore (forked from node.js)

JXCore는 node.js 소스코드를 fork하여 multithreading 기능을 추가한 프로젝트이다. 프로젝트가 시작된 이유는 node가 제 아무리 I/O중심의 요청들을 받아서 빠르게 처리한다 하더라도 동시에 수많은 요청이 한꺼번에 들어오면 반응성이 떨어지는 현상이 있는데 이를 해결하기 위해서라고 한다. node.js는 cluster 모듈을 이용해서 node 프로세스를 여러개 생성해서 반응성을 높이려고 하는데 JXCore는 하나의 node 프로세스 안에 추가적인 thread들을 생성하여 각각 v8::Isolate, v8::Context를 만들고 각각 uv기반의 event loop을 갖도록 하여 반응성을 높인다. 일반적으로 thread가 process에 비해 cpu나 메모리 측면에서 생성비용이 적게 때문에 JXCore가 cluster에 비해 효과를 보는 부분이 있을 거라고 예상할 수 있다. 실제로 벤치마크 결과(레퍼런스 참고)를 보면 node.js의 cluster보다 좋은 성능을 내고 있음을 알수 있다. JXCore가 node.js에 multithreading 기능을 넣은 건 기존 cluster의 반응성 문제를 해결하기 위해서였으나, 이 multihreading 기능을 이용해서 cpu-intensive 작업도 할 수 있도록 지원한다. 아래의 코드에서 보듯이 생성된 JXCore의 thread pool에 task를 add하면 JXCore가 내부적으로 thread를 선택하여 해당 task를 수행시킨다. main thread는 등록한 callback 또는 메시지를 통해 결과를 받을 수 있다. 
[gist 63d008f5b38d9020a5fa]

thread를 이용해서 동시 요청에 대한 반응성을 끌어올린 부분과 cpu intensive 작업을 병렬로 처리하게 한 부분은 주목할만하지만, 굳이 node.js를 fork해서 독립적으로 개발할 필요가 있었을까 싶다. 물론 node.js의 core를 수정해야 했기에 그렇다고는 하지만 node.js가 앞으로 계속 버전업이 될텐데 그에 따라 계속 호환성 유지를 해줄지 모르겠다. 현재까지는 node.js의 버전 (0.11)과 100% 호환되기 때문에 기존 node module과 app이 동작하는데 문제가 없다. JXCore는 현재 오픈 소스도 아니고 중간에 독자적인 길을 걷게 될 수도 있기 때문에 JXCore 기반으로 node 코드를 짜는건 node 개발자들에겐 약간 risk가 있게 느껴지지 않을까 싶다. 

마무리하며..

node에서 제약으로 여겨지는 cpu intensive 작업을 병렬적으로 수행하여 해결하는 몇가지 방법을 간단히 살펴보았다. cpu intensive 작업을 수행하는 상황과 시나리오가 다양하고 다를 것이기 때문에 어떤 방법이 좋다라고 결론 짓기는 어렵다. 상황에 맞게 선택해서 쓰도록 하자. 

 

< refereces >

– http://nodejs.org/api/child_process.html

– http://nodejs.org/api/cluster.html

– https://github.com/xk/node-threads-a-gogo

– https://github.com/audreyt/node-webworker-threads

– http://jxcore.com/docs/jxcore-feature-multithreading.html

– http://flippinawesome.org/2014/03/03/jxcore-a-node-js-distribution-with-multi-threading/

– http://jxcore.com/nodejx-vs-vert-x-vs-node-js-cluster/

애플 개발자 프로그램에 등록한 기념으로 iOS 어플 개발에 대해 몇가지 생각을 나누고자 한다.

1. Objective-C

Objective-c로 개발됐던 NeXT를 기반으로 탄생한 OS X 및 iOS는 objective c 기반의 툴과 프레임워크 (또는 라이브러리)를 갖고 있다. 그렇다보니 이들 운영체제에서 동작하는 어플을 개발할 때 기본적으로 objective-c 라는 언어를 사용한다. 물론 크로스 플랫폼 툴 예를 들면, Xamarin을 이용해 C#을 쓰거나 Apache Cordova를 이용해 HTML5로도 iOS 어플을 개발할 수는 있다. 그렇지만 최근 몇년간 objective c의 사용률이 계속 증가하는 걸 보면 아직까지는 objective c로 어플 개발하는 것이 대세인 것 같다.

objective c는 언어 이름에서도 알수 있듯이  객체지향적 요소가 혼합된 c 언어라고 볼 수 있지 않을까 싶다. 필자가 objective c를 개인적으로 익혀보니 c언어와 c++,  java, python 같은 객체지향 언어를 사용할 줄 아는 개발자라면 objective c를 익히는데 그리 큰 시간이 들지 않을 것이다. 클래스 표기 방법이나, 객체 생성 삭제, 메소드 호출 방법 등 문법적 차이만 있을뿐 기본적으로 다른 객체지향 언어와 용도는 같다.

물론 objective c 만의 독특한 기능들도 있는데 유효하지 않은 객체에 접근할 때 0을 리턴해주는 nil 객체라던지 (c,c++에선 segfault로 프로그램이 종료-_-;) 기존 클래스를 변경하거나 상속하지 않고도 해당 클래스에 메소드를 추가해서 쓸 수 있는 카테고리(Category) 기능이 필자에겐 인상적이었다. 카테고리는 개발 초기보다 릴리즈 이후 기능 추가를 해야 할 경우에 유용하지 않을까 생각된다.

objective c 를 위한 자료는 구글링을 해보면 정말 많이 찾을 수 있지만, 필자가 본 것중 괜찮은 자료 몇개를 공유한다.

http://www.otierney.net/objective-c.html.ko

http://cocoadevcentral.com/d/learn_objectivec

2. xcode 그리고 cocoa touch storyboard

많은 개발자들이 칭찬하는 애플의 xcode ide. 내가 써보기 전에는 공감할 수 없었다. 필자는 소프트웨어를 개발하면서 SDK나 IDE 같이 UI 가진 툴을 거의 쓰지 않았다. 필자는 리눅스 기반에서 코딩을 해온지라 커맨드라인 툴들인 vi, ctag, gnu 툴체인, gdb 정도만 있으면 개발, 디버깅엔 문제가 없었다. 무엇보다 마우스를 옮기며 클릭하는 것에 비해 움직임이 적었기 때문에 내가 생각하는 바를 좀 더 빨리 수행할 수 있었기에 커맨드라인 환경을 더 선호했었다. 필자가 이런 배경을 가지고 있었던터라 xcode 이용해 코딩하는거에 약간의 거부감이 있었으나 며칠을 사용해보고 나서 생각이 달라졌다. xcode. 정말 잘 만든 ide 이다!

내가 제대로된 어플을 개발해본적은 없지만, xcode 상에서 직관적으로 UI를 만들고 로직을 붙일 수 있었다. storyboard 를 이용하면 버튼, 라벨, 네비게이션 바 등 iOS7 위젯들을 쉽게 추가할 수 있다. storyboard는 단순히 스케치북이라 생각하면 될 것 같다. 생각하는 어떤 UI가 있다면 storyboard 상에서 드래그 앤 드랍으로 덕지덕지(?) 붙인 후 시뮬레이터로 구동시켜서 어떤 느낌을 주는지 확인해볼 수 있다. 물론 사용자와 인터랙션을 해야 하는 시나리오, 가령 버튼을 클릭하면 배경화면이 바뀌는 등의 일을 하려면 storyboard와 소스코드를 연동해야만 가능하다.

xcode에서 project 하나를 만드면 xcode 가 자동으로 기본 소스 파일을 생성하면서 템플릿 코드들을 추가해준다. 템플릿 코드에는 어플의 라이프 사이클 관련 이벤트 핸들러들이 들어 있으며 템플릿 타입(게임 등)에 따라 추가적인 템플릿 파일을 생성해준다. 특정 이벤트 발생시 수행해야 할 작업이 있다면 iOS 어플 개발자는 이들 핸들러를 구현해주어야 한다. 템플릿이 생성해주는 것은 정말 기본적인 몇가지 밖에 되지 않기 때문에 개발자가 자신의 어플을 만들면서 각종 위젯과 이에 따른 이벤트 처리들을 직접 추가 및 구현해주어야 한다.

storyboard에 추가한 위젯 (버튼, 텍스트 입력 등)와 소스코드를 연결할때 핵심 부분을 간략히 정리하자면 다음과 같다. 우선 소스코드에 storyboard상에 붙여놓은 해당 위젯 타입으로 멤버 변수를 선언해주어야 한다. 이 때 storyboard 상의 위젯을 가리킨다는 의미로 변수형 앞에 IBOutlet 지시어를 꼭 넣어주어야 한다. 그리고 storyboard 내 Outlets 리스트에서 해당 IBOutlet 변수를 선택하여 연결하고 싶은 위젯에 Ctrl + 드래그앤드랍를 해주면 storyboard 상 위젯이 소스코드 상의 멤버 변수라는 것을 xcode(정확히는 Interface Builder)에게 알려주게 된다. 이후 부터는 소스코드 상에서 해당 위젯의 속성을 변경하거나 해당 위젯이 제공하는 특정 이벤트 핸들러들을 구현하여 처리해줄 수 있다.

반대로 특정 위젯 위에서의 사용자의 터치나 제스처가 발생했을 때 무언가 처리를 해주어야 한다면, 소스코드에서 IBAction 지시자를 넣어 메소드를 생성하고 이를 storyboard 내 Recieved Actions 리스트에서 해당 IBAction 메소드를 선택하여 연결하고 싶은 위젯에 Ctrl + 드래그앤드랍를 해주면 된다. 이 때 받을 이벤트나 제스처를 선택해야 할 수 있도록 팝업이 뜨고 그 중 하나를 선택하면 된다. 이를 통해 개발자는 사용자의 터치나 제스처 입력에 대해 처리할 수 있다.

그리고 뜬금없지만.. xcode 내 editor 는 자동 완성 기능이 아주 좋은 것 같다. vi에서는 ctag와 연동해 별도 설정을 해야만 했던 기능인데 xcode에서는 디폴트로 동작한다.

3. 개발 참고 문서

objective c와 xcode 를 이용해서 iOS 어플을 어떻게 만드는지 경험해보고 싶다면, 아래 애플의 개발자 문서를 추천한다. 필자는 인터넷에 떠도는 여러 튜토리얼을 읽어보았는데 애플 문서 만큼 iOS를 개발하는데 필요한 여러 내용들을 잘 정리한 건 없었던 것 같다.

https://developer.apple.com/library/ios/referencelibrary/GettingStarted/RoadMapiOS/index.html#//apple_ref/doc/uid/TP40011343

그 외 아래 튜토리얼도 지루하지 않고 꽤나 괜찮았다.

http://www.raywenderlich.com/tutorials

본격적으로 iOS 어플 개발을 하게 된다면 API 등 참고해야 할 내용들이 아주 많아질텐데 애플 개발자 사이트에 문서화가 너무나도 잘 되어 있어서 다행이다.

https://developer.apple.com/library/ios/navigation/

마지막으로 개발자 포럼 사이트이다. stackoverflow 에서도 왠만한 답은 얻을 수 있겠지만 여기 커뮤니티도 꽤나 크니 활용할만하다.

https://devforums.apple.com

4. 3rd party 개발자 그리고 철학

나는 타이젠 플랫폼 구체적으로 web framework 을 개발하던 사람으로서 외부에 공개되는 기능을 정의하고 개발할 때 3rd party 개발자 입장에서 생각하면서 만드려고 노력했었다. 3rd party 개발자라면 이런 기능이 필요할까. API의 원형은 어떤게 더 효율적일까. 문서는 충분히 만들어졌나. 개발자들이 이것을 이용해 내가 의도한대로 사용해줄까. 이 기능 때문에 개발자가 몰려들까. 이런 류의 질문을 스스로 던지곤 했었다. 타이젠 에코시스템이 아직 자리 잡지 않은 상황이고 개발자 풀이 적은 상황에서 정답을 얘기해줄 수 있는 사람이 사실 주변에 없었다. 나 역시 3rd party 개발자로서의 경험이 없기 때문에 스스로 던지는 질문에 늘 예측만 할 뿐이었다.

며칠간 iOS 개발을 위해 환경을 설정하고 기본 기술을 익히고 사용해보면서, 아 이걸로 제대로 된 어플 하나 만들 수 있겠다 하는 생각이 들었다. iOS의 심플한 UX를 추구하면서 사람들에게 도움이 되는 무언가를 나눌 수 있다는 사실에 의욕이 생긴다. 3rd party 개발자 입장이 되보니 플랫폼에서 중요한게 무엇인지 하나씩 알아가게 되는 것 같다. 에코시스템, 개발환경, 개발 문서 그리고 커뮤니티 모두 중요하지만, 개발자들의 참여를 자발적으로 이끌어낼 수 있는 철학이 무엇보다 중요하지 않을까 싶다.

자, 그럼 이제부터 시작해보자.