App은 과거에는 폰 기반의 인증체계를 따랐지만, 지금은 패드류와 같은 전화번호 기반이 아닌 기기들이 퍼지면서 디바이스 인증체계가 필요하게 된다.


1. 폰 번호 인증 


min, mdn 이라는 전화번호 체계를 통해서 통신사에서 인증하는 시스템이다. 이 시스템은 인증, 결제가 특정 통신사에 의존적이라는 단점과 결제가 무척 쉽게 된다는 장점이 있다. 스마트폰은 되지만, 테블릿이나 패드류는 인증이 어렵다. 확장자체가 안되는 단점이 존재한다.  통신사 Store 어플이 이 부분때문에 VOC가 생기고 있다. 



2. 멀티 디바이스 인증


디바이스 플랫폼 의 device id(ios라면 UDID, unique device identifier) 기반으로 인증 체계를 구축한다. 그러나 플랫폼에서 가이드를 하지 않는 관계로 계속 바뀌게 되면 인증 체계도 그에 맞게 수정이 되어야 한다.


참고로, wifi의 mac address를 이용하지만, 개인정보 이슈도 있고, wifi도 꺼져있으면 올바른 주소값을 가져올 수 없다. 또한 너무 hardware디펜던트한 정보면 기기변경이나 양도시 문제가 될수 있다. 



(1) IOS - apple

고전적으로 UDID(40-digit sequence of letters and numbers)를 사용했다. 그러나 2013년 5월 1일 부터(https://developer.apple.com/news/index.php?id=3212013a)  UDID를 사용하는 모든 App은 더이상 Apple이 승인해주지 않기로 했다. 

https://developer.apple.com/library/ios/#documentation/uikit/reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html

IOS 5.0이상부터는 UIDevice의 uniqueIdentifier 를 쓰지 못하고 UUID 또는 advertisingIdentifier 또는 identifierForVender를 써야 한다. 


오래전부터 Apple은 UDID대신 UUID를 쓰라고 계속 권고했었고,  UDID를 해결할려고 하는 분위기(http://dev.kthcorp.com/2011/09/07/ios5-uuid-udid/)가 존재했다. 

https://github.com/ylechelle/OpenUDID, http://secureudid.com/ 와 같이 UDID를 generation하는 움직임이 있었지만 Apple의 힘으로 모두 통일했다. 


iOS 7에서는 wifi 정보가 이상하게 추출되거나 개인정보로 취급되는 일들이 벌어졌다. 

http://techcrunch.com/2013/06/14/ios-7-eliminates-mac-address-as-tracking-option-signaling-final-push-towards-apples-own-ad-identifier-technology/


Vender 입장에서는 UDID대신 UUID를 쓰거나 새로나온 API를 써야 하는 환경인데, legacy를 위해서는 새로운 unique id를 발급하는 체계를 서버가 하거나, UUID를 Static하게 저장/읽기로 쓰는 형태로 가게 되었다. 


UUID는 iOS 6.0부터 쓸 수 있으며, 4 random bytes이다. 시간 베이스이기때문에 재설치하면 UUID는 새로운 값이 되는 특성을 가지고 있다. 따라서 저장을 해야 해서 유지성을 높여야 한다. 이미 legacy 호환을 위해서 다양한 시도들이 있고 계속 사용중에 있다. 


https://github.com/blackpixel/BPXLUUIDHandler

http://stackoverflow.com/questions/10697786/is-it-a-good-idea-to-store-device-identifier-in-keychain-for-ios-app



(2) Android 

폰의 경우는 TelephonyManager 를 사용하면 된다. 그러나 패드 및 테블릿에서는 정보를 구할 수 없다. 

TelephonyManager.getDeviceId()


Settings.Secure.ANDROID_ID를 이용하는 경우가 많이 거론된다. 

그러나 ANDROID_ID 를 사용하는 방법은 일부 단말 혹은 안드로이드 2.2 하위 버전에서는 같이 아이디를 반납하면서 unique성이 떨어지기도 한다. 그래서 어떤 Vendor들은 이 이슈를 해결하기 위해서 ANDROID_ID + mac 을 섞은 hashing value를 쓰기도 한다.  ANDROID_ID 는 초기화하면 새로운 값이 나온다는 장점이 있다. 


제조사의 시리얼 넘버를 사용 (http://developer.android.com/reference/android/os/Build.html#SERIAL)하는 경우도 있는데. android 2.3부터 사용가능하다. 양도시 인증 문제가 발생할 수 있다. 


결국 안드로이드도 IOS처럼 서버에서 인증체계를 가져가거나 기기에서 UUID (128-bit, http://developer.android.com/reference/java/util/UUID.html)를 생성/저장/읽기를 함으로서 기기의 인증을 하는 방법을 차용하게 된다. stack-overflow를 뒤지다 보면 아래의 블로그를 참조하라고 나오는 경우가 많아서 내용을 공유한다. 

http://android-developers.blogspot.in/2011/03/identifying-app-installations.html




(3) 나머지 

타 스마트폰의 경우도 iOS나 android처럼 진행하면 된다. 





3. 생각

기기의 unique id를 얻기 위해서 서버에서 uniqueness를 생성할지, 단말 App에서 생성할지는 고민해볼만하다. 각각의 장단점이 있고, 이 둘을 합치는 것도 좋을 수 있을 것 같다. 


폰 인증과 디바이스 인증과 계정 인증의 결합은 매핑만 하면 참 괜찮을 것 같은 생각이 든다. 현재까지는 폰인증만 있거나, 디바이스 인증, 계정 인증의 결합만 존재하고 있는 현실이다. 그러나 이 모든 것이 합쳐진다면 진짜 재미있는 현실이 기다리고 있을 것 같다. 



Posted by 김용환 '김용환'

댓글을 달아 주세요