안녕하세요 Humanscape 의 Jake 입니다.
오늘은 OAuth 2.0에 대해 알아보고자 합니다.
OAuth 2.0은 다양한 서비스 환경에서 사용자 인증과 권한 부여를 위한 industry-standard protocol 로 사용자가 카카오톡이나 구글과 같은 인터넷 서비스의 기능을 다른 애플리케이션에서도 사용할 수 있게 해줍니다.
OAuth는 2006년 트위터 개발자 브래인쿡과 소셜북마이크사이트 Ma.gnolia가 회원이 OpenID를 사용해 서비스에 접속할 수 있는 인증방법을 고민하던중 API 접근 위임에 대한 공개 표준이 없다는것을 알게되었고 그 뒤 2007년 4월 OAuth 인터넷 커뮤니티가 탄생 2008년 73회 IETF회합에서 정식으로 논의가 되었으며 2010년에 OAuth 1.0 프르토콜 표준안이 RFC 5849로 발표 되었습니다. ( 2007년 10월 3일 OAuth core 1.0 가 발표 되었으나 이는 비공식 )
OAuth 를 수행하는 Roles과 Protocol에 대해 살펴 보겠습니다.
Roles
- Resource Owner : Protected Resource에 대한 접근권한을 부여함
- Resource Server : Protected Resource를 호스팅 하는 서버. Access Token을 사용하여 Protected Resource Requests에 응답
- Authorization Server : Client에 AccessToken을 발급하고 Resource Owner인증 및 권한 부여
- Client : Resource Owner에게 Protected Resource Requests를 함
Protocol
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol FlowA : Client가 Resource Onwer에게 권한을 요청합니다.
B: Client는 Resource Owner가 권한을 허가하면 권한자격증명을 받게됩니다. ( 권한자격증명은 대표적인 4가지유형 또는 확장된유형이 있으며 사용은 서버가 지원하는 형식과 권한을 요청하는 클라이언트에 따라 달라집니다 )
C: Client는 Authorzaion Server 에 권한자격증명을 제공하여 Access Token 을 요청합니다.
D: Authorzaion Server가 Client 를 인증하고 유효성을 검사하고 유효한경우 Access Token을 발급합니다.
E: Client는 Resource Server에 AccessToken을 제공하여 Protected Resource를 요청합니다.
F: Resource Server가 AccessToken이 유효한지 확인하고 유효하다면 Protected Resource를 제공합니다.
대표적인 권한자격증명 4가지
- Authorization Code : Client가 Resource Owner에게 직접권한증명을 요청하지않고 Authorization Server에서 인증을 받고 Authorization Code를 발급을 받습니다. 이후 Client는 Authorization Server에 Authorization Code를 제출하고 AccessToken을 발급받습니다. 이방법은 AccessToken을 바로 발급하지않고 일련의 검증절차를 거치기때문에 보안상의 이점이 있습니다.
2. Implicit : Authorization Code가 발급되지 않고 바로 AccessToken을 발급받습니다. Implicit방식은 Browser에서 구현되는 클라이언트에 적합합니다.
3. Resource Owner Password Credentials : Resource Owner의 username과 password를 입력하여 AccessToken을 발급 받습니다. 이 방식은 Resource Owner와 Client간의 신뢰도가 높은 경우 사용됩니다. ( 다른 권한 부여 유형을 사용할 수 없는 경우에 사용합니다 )
4. Client Credentials : Client 정보 (clientId, clientSecret 등)를 입력하여 AccessToken을 부여 받습니다. 이방식은 Resource Owner가 User가 아닌 Client일때 사용됩니다.
지금까지 OAuth2에 대해 알아보았습니다. 많은서비스들이 OAuth2를 활용하여 Remote Service Resource를 요청하고 있습니다. 위의 내용을 참고하셔서 서비스구축시에 도입을 해보시는것도 좋을것 같습니다.
감사합니다.
Get to know us better!
Join our official channels below.
Telegram(EN) : t.me/Humanscape
KakaoTalk(KR) : open.kakao.com/o/gqbUQEM
Website : humanscape.io
Medium : medium.com/humanscape-ico
Facebook : www.facebook.com/humanscape
Twitter : twitter.com/Humanscape_io
Reddit : https://www.reddit.com/r/Humanscape_official
Bitcointalk announcement : https://bit.ly/2rVsP4T
Email : support@humanscape.io
