2. Content List
1. OAuth 개념 (OAuth란 무엇인가?)
2. OAuth1.0 vs Oauth2.0
3. OAuth 개발환경 및 도구
4. 관련 사이트 공유
3. OAuth 개념
무엇에 쓰는 물건이고?
■ Open Authorization 약자이며 API를 사용하여 자원에 접근하기 위한 표준
■ SNS와 같은 웹서비스 자원을 사용자의 인증정보 없이도 써드파티에서 사용
■ Oauth 프로토콜은 2007년 초반 처음 초안이 작성됨
■ IETF에서 RFC 5849 : The Oauth 1.0 Protocol로 등록됨
TIP
IETF란? [Internet Engineering Rask Force] 약자로
인터넷의 원활한 사용을 위한 인터넷 표준규격을 개발하고
있는 미국 IAB(Internet Architecture Board)의
조사위원회
RFC란? [Request for Comments] 인터넷 기술을
구현하는데 필요한 절차 등을 제공하는 공문서 간행물
짜증나!!
4. OAuth 개념
OpenID와 OAuth는 다른가? 본질 적으로 다르다
■ OpenID의 주요 목적은 인증(Authentication), Oauth의 목적은 허가
(Authorization)
■ OpenID의 사용은 OAuth와 같이 로그인 인증 행동과 같지만 근본 목적은
OAuth는 API 호출 권한 및 자료 사용에 대한 허가을 주 목적으로 한다.
■ OpenID와 OAuth와는 근본적으로 다르다는 것을 알아야 함.
5. OAuth 개념
조금 알 것 같은데 뭔가 더 없나? 개념이 확~ 잡을 만한 그 무언가…
■ OAuth와 로그인의 차이를 설명해 보겠다 다음과 같은 절차를 생각해 보자
① 나방문씨(외부손님)가 안내 데스크에서 업무적인 목적으로 김목적씨(회사사원)를 만나러 왔다고 말함.
② 안내데스크에서는 김목적씨에게 나방문이라는 어처구니 없는 이름을 사용하는 정신병자 갑인 사람이
방문 했다고 연락함.
③ 김목적씨는 안내데스크로 찾아와 정신병원 입원 동기라 얘기하고 나방문씨의 신원을 확인 해 준다.
④ 김목적씨는 업무 목적과 인적 사항을 안내 데스크에 기록함.
⑤ 안내 데스크에서 나방문 씨에게 방문증을 발급해 줌
⑥ 김목적씨와 나방문씨는 정해진 장소로 이동해 업무 시작
나방문김목적
안내데스크 P양
일하러 갑시다
ㅇ 사원증
-모든곳 출입가능
ㅇ 방문증
- 일부구간 출입 불가능
①②
③ ④
⑤
⑥
6. OAuth 개념
OAuth와 춤을…
OAuth를 이용하여 사용자를 인증하는 과정을 OAuth Dance라고 함. 두 명이 춤을 추듯 정확하게 정보를
주고받는 과정을 재미있게 명명한 것
용어 설 명
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의 자원에 접근하기 위한 키를 포함한 값
8. OAuth 개념
OAuth와 춤을… 회사 방문 과정과 OAuth 인증과정
회사 방문 과정 OAuth 인증 과정
나방문씨가 안내 데스크에 김목적씨 만나러 왔다고 함. Request Token의 요청과 발급
안내 데스크에 나방문씨가 왔다고 김목적씨에게 얘기함. 사용자 인증 페이지 호출
김목적씨가 안내데스크로 찾아와 입원 동기라 함. 사용자 로그인 완료
김목적씨가 업무목적과 인적사항 안내데스크에 기록 사용자의 권한 요청 및 수락
안내 데스크에서 나방문씨에게 방문증 발급 Access Token 발급
김목적씨와 나방문씨는 정해진 장소로 이동 업무시작 Access Token을 이용해 서비스 정보 요청
Token?!
TIP
Token : 네트워크 아키텍처중에서 로컬 에어리어 네트워크
중 링(ring) 네트워크이다. 데이터 플로 머신에 있어서
연산되는 대상의 “데이터”
OAuth의 Token은 인증 및 허가에 필요한 일종의
암호화된 Key라고 생각하면 됨.
9. Oauth 종류에 따른 장/단점 및 사용업체 구분
OAuth1.0 vs OAuth2.0
OAuth1.0a OAuth2.0
인증 및 signature 생성이 너무 복잡함
(Consumer의 노력이 필요함)
인증 및 signature 생성이 단순함.
인증을 얻기 위해 Web 환경만 지원
비브라우져 (Win Application)의 Client에서 인증을 하기 위한
매끄러운(?) 방법을 제공한다.
스케일이 큰 Service Provider의 성능 이슈 발생
(Validation 과정에서 발생하는 성능 이슈 추측)
아직까지 성능 이슈에 대한 보고 없음
Client에서 암호화를 위한 코드를 삽입할 필요없음
(HMAC_SHA1 등)
2.0과 호환성을 제공하지 않는다 1.0과 호환성을 제공하지 않는다
Oauth2.0에서는 인증을 통해 access_token을 발급받은 이후에는 https와 access_token parameter의
인증만으로 protected된 자원에 접근 할 수 있게 하겠다는 의미로 해석됨
OAuth1.0 Service Provider OAuth2.0 Service Provider
1. NHN(Open API)
2. Daum(요즘, Open API)
3. MySapce
4. NetFlix
5. Twitter -> Oauth2.0 전환
6. Vimeo
1. Facebook
2. Foursquare
3. Google
4. Microsoft(Hotmail, Messenger, Xbox)
5. Linkedin
6. Daum(티스토리)
10. OAuth1.0 vs OAuth2.0
아니 OAuth1.0의 Signature 생성이 얼마나 복잡하면…
Parameter Parameter 설명
Oauth_callback 권한 확인 후 이동할 URL
Oauth_consumer_key API 사용자 키
Oauth_nonce 임의 문자열 (동일 시간대 요청에 유일한 문자)
Oauth_signature URL정보를 조합하여 비밀키로 암호화한 문자열
Oauth_signature_method Oauth_signature의 암호화 방식
Oauth_timestamp 1970이후를 초단위로 환산한 값
Oauth_version Oauth의 버전 (1.0a까지는 1.0으로 명시)
Request Token 요청을 위한 필요 매개변수
Parameter Parameter 설명
Oauth_token Request token
Oauth_token_secret Consumer secret key와 조합하는 추가 비밀키
Request Token요청 완료 시 결과 값
11. 아니 OAuth1.0의 Signature 생성이 얼마나 복잡하면…
OAuth1.0 vs OAuth2.0
Signature Base String 생성규칙 4단계
1단계 : HTTP Request Method
Request Token 요청시 GET과 POST 두가지 방법으로 RFC3986에서 정의한 퍼센트 인코딩 방법을 사용하여 인
코드 해야함.
2단계 : Request URL
인증요청시 사용하는 Request URL을 퍼센트 인코딩한다.
인코딩 후 내용 https%3A%2F%2f[request URL].oauth
3단계 : Oauth Parameters
요청을 위해 전달하는 Oauth 파라미터들 중 Oauth_signature를 제외한 파라미터들을 Name과
Value로 정렬하여 퍼센트 인코딩 해야함.
Exam)urlencode(oauth_callback)=urlencode(http://www.example.com)&urlencode(oauth_consumer_key)=urlen
code(dkfjasldklfja)....
4단계 : Signature Base String의 조합
A,B,C에서 만든 각각의 결과물을 Signature Base String의 규칙에 맞게 조합
완성된 예시 (Naver Signature)
GET&https%3A%2F%2Fnid.naver.com%2Fnaver.oauth&oauth_callback%3Dhttp%253A%252F%252Fnid.naver.com%252Fte
st%252Ftestoauth.nhn%26oauth_consumer_key%3DKdvYJ16Q_2yL%26oauth_nonce%3D7BE23CFD-B3D5-4DB3-A8D0-
4B236366D03C%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1306930668%26oauth_version%3D1.0
12. Signature가 완성된 code
OAuth1.0 vs OAuth2.0
Oauth_signature를 제외한 나머지 URL
http://nt.ntreev.com/ntreev.oauth?mode=req_req_token&
Oauth_callback=http://example.com/oauth_result.do&
Oauth_consumer_key=WEhGuJZWUasHg&
Oauth_nonce=zSs4RFI66
Oauth_signature_method=HMAC_SHA1&
Oauth_timestamp=1330442419&
Oauth_version=1.0
BASE64_ENCODE(HMA-SHA1(
GET+encode(https://nt.ntreev.com/ntreev.oauth) +
mode=encode(req_req_token)&oauth_callback=encode(http://example.com/
oauth_result.do)&oauth_nonce=encode(zSs4RFI66)&oauth_signature_method=
encode(HMAC-SHA1)&oauth_timestamp=1330442419&oauth_version=1.0
, SECRET_KEY(consumer secret key + “&”+ oauth_token_secret))
14. OAuth1.0 vs OAuth2.0
당…당황하셨어요~?
그럼 2.0에서는 뭐가 더 좋아졌나?
Oauth1.0에 참여했던 Eran Hammer는 Oauth2.0의 https방식에
의존하는 방법으로 채택 후에 Oauth2.0 개발자의 이름에 자신의
이름은 빼달라고 함. Https의 암호화 방식은 보안에 무지 취약한 방법이다
또한 토큰 암호화를 빼고 Https 방식에 의존하는 것은 실수다.
잠시만요~~~
Eran Hammer 이름 빼고
가실께요
15. OAuth1.0 vs OAuth2.0
당…당황하셨어요~?
그에 대한 반론
1. HTTPS에 의존하여 토큰 암호화 안함
: HTTPS는 충분히 안전하다
2. REFRESH하는 과정에서의 TOKEN 관리 문제
: 여러가지 대안 존재
3. 너무 많은 권한 부여방식
: 안전한 GRANT TYPE 사용 / EXTENSION사용 제한
소~~는 누가 키울꺼야?
이거~
나 때는 이런거 없었지~~
16. OAuth1.0 vs OAuth2.0
당…당황하셨어요~?
그럼 2.0에서는 뭐가 더 좋아졌나?
1. 확장성 : API 서버와 인증서버의 분리
2. 간단해 짐 : signature -> HTTPS 방식으로 get 또는 post방식으로 전송
3. 다양한 시나리오 : 다양한 토큰 지원, 다양한 GRANT TYPE 지원
- Mac token
- JSON-web token
- SAML2
4. Access Token 유효기간
- 모든 access token은 유효기간을 지님
- 기간이 만료되면 refresh token으로 연장 (Service Provider의 운영 이슈 발생)
Signature를 https 방식으로 만
보내는 것이 보안에 정답일까?
걱정하지마~ 어차피 https도 RC4
스트림 암호를 사용한다구~
당신이 나를 밤에 이용하는 것 처럼
말이지~
17. OAuth1.0 vs OAuth2.0
당…당황하셨어요~?
그래서 우린 뭘 쓸가나? Oauth1.0a? Oauth2.0?
1. 우린 국제적 대세를 따른다!!!
2. 여러 업체들이 앞으로 많이 이용 할 것 같은 것
3. Consumer 개발사가 쉽고 빠르게 접근 하도록
4. 모험정신을 이끌어 낼 수 있는 것 등등…
- 자료들이 만무하고 이미 다 구현 해 논 것들은 검증은 됐지만
맨날 남들이 해논거 뒷 따라 갈 수는 없다
우리도 달걀을 세우자~
창의적이게~
19. OAuth2.0 개발환경 및 도구
당…당황하셨어요~?
그럼 어디서 부터 개발을 시작해야 할까나?
일단 내 맘대로…
맘편하게 Linux로 나중에 OS 사달라고 애원 안해도 되거
무난하게 Linux와 궁합이 잘 맞으므로 해서리
Python이든 C#이든 만들 수 있지만 그래도 요새 Oauth 구현시
대세라는 JAVA 쓰기로 하고 Restful도 Java가 대세고
JAVA로 웹서비스 할라믄 Tomcat 있어야 겠지!!
이건 필수로다
20. OAuth2.0 개발환경 및 도구
당…당황하셨어요~?
Maven과 Spring Framework
빌드 및 프로젝트 관리툴 메이븐을 사용하고
이것도 대세라던데…
MVC 패턴 도구는
JAVA MVC 웹개발 프레이워크를 사용하도록 하자
왜냐면 Oauth2에 대한 메서드들이 다 들어있다.
Spring Framework와 Spring Security
이건…
제가 할께요~~
느낌 아니까~
22. OAuth2.0 개발환경 및 도구
당…당황하셨어요~?
지금하고 있습니다. 현재 Spring Security OAuth2
Sample Source를 받아서 분석중입니다.
기다리시고 다음편에 계속… 조만간 공개하겠습니다.
23. 관련사이트 공유
http://oauth.net/2/ : OAuth2.0 사이트
http://fr.slideshare.net/deview/hello-world-oauth : 실전 OAuth A to Z 오창훈 (개념과 기술적 이해를 설명)
http://www.slideshare.net/tebica/oauth2-api : OAuth 2.0 API인증을 위한 만능 도구상자 (OAuth1.0a와 OAuth2.0의 차이설명)
http://dev.kthcorp.com/2012/12/12/oauth-2-0-open-api-auth/ : 바로 위 내용을 글로 자세히 설명
https://github.com/SpringSource/spring-security-oauth : Spring Security를 이용하여 OAuth2.0 만든 C/S 환경 샘플
감사합니다.
