OAuth&LDAP.md

android OAuth

android의 OAuth 프로토콜 연동에 대하여

작성자 : 박소현

Present Time : 2018-07-25-WED

Last Updated : 2018-07-31-TUE

---

0. 들어가기 전

본 주제를 선택하게 된 계기는 발표자가 지원하고자 했던 회사의 우대사항에 포함되어 있었기 때문이다.

지원하고자 했던 회사 뿐만 아니라 다른 회사에서도 중요하게 여길 수 있는 주제라고 생각되어 발표하게 되었다.

발표자는 아니었지만 다른 회사 면접에서 충분히 질문으로 나올 수 있는 개념이니깐 알고 있으면 도움이 많이 될 것 같다.

1. OAuth

1-1. OAuth?

: 인증을 위한 오픈 스탠더드 프로토콜

1-2. OAuth의 탄생

OAuth의 탄생 이전에도 다른 애플리케이션에 사용자의 아이디와 암호가 노출되지 않도록 하면서 API 접근 위임(API Access Delegation)이 가능한 여러 인증 방법이 있었다. Google과 Yahoo!, AOL, Amazon 등에서는 각각의 인증 방식을 제작하여 사용했다. (각각의 인증 방식에 대해서는 개인적으로 찾아보도록 하자!)

OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

OAuth 1.0이 나온 때는 2007년이며, 이후 보안 문제를 해결한 수정 버전인 OAuth 1.0 revision A 가 2008년에 나왔다.

2007년에 나온 OAuth 1.0은 비공식 논의체에 의해 최초로 만들어진 것이고, 2010년 IETF OAuth 워킹그룹에 의해 이 프로토콜이 IETF 표준 프로토콜로 발표된 것이다.

현재 나와 있는 OAuth 2.0은 드래프트 단계에 있는 것으로, IETF OAuth 워킹그룹이 주축이 되어 만든 것이다. OAuth 2.0은 OAuth 1.0과 호환되지 않지만, 인증 절차가 간략하다는 장점이 있다. 그래서 아직 최종안이 나오지 않았음에도 여러 인터넷 서비스에서 OAuth 2.0을 사용하고 있다. 다음 표는 대표적인 인터넷 서비스 기업에서 사용하는 OAuth의 버전을 정리한 것이다.

[표1 - 인터넷 서비스 기업이 사용하는 OAuth 버전]

인터넷 서비스 기업	OAuth 버전
Facebook	2.0
Foursquare	2.0
Google	2.0
Microsoft (Hotmail, Messenger, Xbox)	2.0
LinkedIn	2.0
Daum(티스토리	2.0
NHN (오픈API)	1.0a
Daum(요즘, 오픈API)	1.0a
MySpace	1.0a
Netflix	1.0a
트위터	1.0a
Vimeo	1.0a
Yahoo!	1.0a

1-3. OAuth Dance, OAuth 1.0 인증 과정

1-3-1. OAuth Dance?

: OAuth를 이용하여 사용자 인증을 하는 과정

두 명이 춤을 추듯 정확하게 정보를 주고받는 과정을 재미있게 명명한 것이다.

1-3-2. OAuth 1.0 대표 용어

[표2 - OAuth 1.0 대표 용어]

용어	설명
User	Service Provider에 계정을 가지고 있으면서, Consumer를 이용하려는 사용자
Service Provider	OAuth를 사용하는 Open API를 제공하는 서비스
Consumer	OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스
Request Token	Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환한다.
Access Token	인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값

1-3-3. OAuth 1.0 인증 과정

[표3 - 회사 방문 과정과 OAuth 인증 과정]

	회사 방문 과정	OAuth 인증 과정
1.	나방문씨가 안내 데스크에서 업무적인 목적으로 김목적씨를 만나러 왔다고 말한다.	Request Token의 요청과 발급
2.	안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.	사용자 인증 페이지 호출
3.	김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.	사용자 로그인 완료
4.	김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.	사용자의 권한 요청 및 수락
5.	안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.	Access Token 발급
6.	김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.	Access Token을 이용해 서비스 정보 요청

위의 표에 따르면, Access Token은 방문증이라고 이해할 수 있다. 이 방문증으로 사전에 허락된 공간에 출입할 수 있다. 마찬가지로 Access Token을 가지고 있는 Consumer는 사전에 호출이 허락된 Service Provider의 오픈 API를 호출할 수 있는 것이다.

1-4. OAuth 2.0

OAuth 1.0은 웹 애플리케이션이 아닌 애플리케이션에서는 사용하기 곤란하다는 단점이 있다. 또한 절차가 복잡하여 OAuth 구현 라이브러리를 제작하기 어렵고, 이런저런 복잡한 절차 때문에 Service Provider에게도 연산 부담이 발생한다.

OAuth 2.0은 이러한 단점을 개선한 것이다. OAuth 1.0과 호환성이 없고, 아직 최종안이 발표된 것은 아니지만 여러 인터넷 서비스 기업에서 OAuth 2.0을 사용하고 있다.

1-4-1. OAuth 2.0의 특징

• 웹 애플리케이션이 아닌 애플리케이션 지원 강화
• 암호화가 필요 없음 HTTPS를 사용하고 HMAC을 사용하지 않는다.
• Siganature 단순화 정렬과 URL 인코딩이 필요 없다.
• Access Token 갱신 OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다. OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

이외에도 OAuth 2.0에서 사용하는 용어 체계는 OAuth 1.0과 완전히 다르다. 같은 목적의 다른 프로토콜이라고 이해는 것이 좋다. 하지만 아직 최종안이 나오지 않았기 때문에, 현재로서는 OAuth 2.0의 특징만 파악하는 것으로도 충분할 듯 하다.

1-5. Android에서 Facebook Login해보자!!!

NAVER같은 경우는 공식적인 개발 가이드가 따로 있고, Facebook이나 Google은 공식은 아니지만(공식 문서도 있는 것 같다) 많은 사람들이 가이드를 친절하게 설명해놓았다. 그래서 단계마다의 세세한 설명보다 주의해야 할 점 위주로 적어보았다.

• minSdkVersion는 API 15 이상으로 설정한다.
• 해시 키의 경우, 커멘드 창을 통해 확인할 수 있지만 코드로 확인할 수도 있다.

https://developers.facebook.com/docs/facebook-login/android?sdk=maven

http://superwony.tistory.com/13

2. LDAP

2-1. LDAP?

: Lightweight Directory Access Protocol

인터넷이나 기업 내의 인트라넷 등 네트워크 상에 있는 파일이나 장치들과 같은 자원 등의 위치를 찾을 수 있게 해주는 소프트웨어 프로토콜이다.

네트워크에서, 디렉토리란 어떤 자원이 네트워크 상의 어디에 있는가를 알려준다. 인터넷을 포함한 TCP/IP 네트워크에서, DNS 는 특정 네트워크 주소와 도메인 이름 사이의 관계를 나타내는 디렉토리 시스템이다. 그러나, 때로는 도메인 이름 조차 모를 수 있는데, LDAP는 개체가 어디에 있는지 알지 못하더라도 그것을 검색할 수 있게 한다 (비록 추가정보가 있으면, 검색시 도움은 되겠지만).

LDAP 디렉토리는 아래에 나타낸 것처럼, 계층으로 구성되는 단순한 트리 구조이다.

• 루트 디렉토리 (시작위치 또는 트리 구조의 근원), 각각 아래로 뻗어나간다
• 국가들, 각각 아래로 뻗어나간다
• 기관들, 각각 아래로 뻗어나간다
• 기관별 단위 (부서 등), 각각은 아래로 뻗어나간다
• 개체들 (사람, 파일, 및 프린터 등과 같은 공유자원들)

2-2. 어떻게 사용될까?

SSO(Single Sign On) : 한 번의 인증 과정으로 여러 컴퓨터 상의 자원을 이용 가능하게 하는 인증 기능

SSO의 기본 DB가 주로 LDAP서버를 사용한다.

1. 사용자관리에 주로 이용되고 있다.

   왜냐하면, LDAP는 지정되어있는 디렉토리의 내용을 읽어오는데 아주 빠른 성능을 보유하고 있기 때문이다.

2. 인증서를 저장하는데 많이 이용하고 있다.  금융권에서는 거의 사용한다고 보면 된다

2-3. 기타 등등

LDAP는 디렉토리 서비스 엑세스를 위한 클라이언트-서버 프로토콜이다.

디렉토리 서비스

디렉토리는 데이타베이스와 유사하지만 디렉토리 내의 정보는 일반적으로 쓰기보다는 읽기 작업에 빈번히 이용된다. 따라서, 디렉토리는 통상적으로 정규 데이터베이스들이 다량의 복잡한(high-volume complex) 갱신을 위해 사용하는 복잡한 처리(transaction) 또는 롤백 계획(프로그램에 따라 바로 전의 체크포인트로 돌아가기, roll-back)을 수행하지 않는다.

즉, 디렉토리는 일반적으로, 적어도 허용된다면, 전부 갱신되거나 아무 것도 변경되지 않는다.

자주 변경되는 정보를 관리하는 것은 LDAP보다는 RDBMS를 사용하는 것이 옳다.

3. 마무리

3-1. 출처

https://d2.naver.com/helloworld/24942

3-2. 마무리

면접을 보기 전에 한 번씩 읽고 가면 개념적으로 도움이 될 것 같다.