OAuth2 Spec. - 1. Introduction
https://tools.ietf.org/html/rfc6749#page-4
1. Introduction 소개
In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations: 기존의 client-server 인증모델은, client가 resource owner의 credential을 가지고 protected resource에 접근하는 형태다. thrid-party application이 redtricted-resource에 접근하려면 resource owner의 credential을 가지고 있어야 한다. 위의 사항들은 아래의 문제와 제약을 갖는다 :
o Third-party applications are required to store the resource owner’s credentials for future use, typically a password in clear-text. Third-party application은 앞으로 사용할 resource owner의 credential을 다 가지고 있어야한다. 보통 password를 텍스트로 보관한다.
o Servers are required to support password authentication, despite the security weaknesses inherent in passwords. Server는 취약한 패스워드 인증방식을 꼭 지원해야한다.
o Third-party applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources. Third-party application은 resource owner의 protected resource에 대한 광범위한 접근권한을 갖게된다. resource owner는 일부 resource에 대해 별도의 시간제한이나 접근제한을 걸 수 없다.
o Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party’s password. (OAuth2를 쓰지 않는경우)Resource owner에서 third party 앱의 접근을 관리할 때는 일부 리소스에 접근을 제한할 수 없고 비밀번호를 바꿔서 전체 리소스의 접근을 모두 제한해야한다.
o Compromise of any third-party application results in compromise of the end-user’s password and all of the data protected by that password. ?? Third-party application의 결과는? end-user 비밀번호에 달려있다. 모든 데이터는 end-user 비밀번호에 의해 보호된다.
OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. OAuth는 이 문제들을 authorization layer를 이용해서 그리고 resource owner의 client의 role을 이용해서 해결했다. OAuth에서 client의 접근은 resource owner에 의해 동작한다. resource server에서 서비스된다. 그리고 이것들은 resource owner고 다른 인증값을 사용한다.
Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token – a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. protected resource에 접근할 때, resource owner의 credential을 사용하는 대신에 client는 access token을 받는다. (access token : 문자열로 되어있고, 접근범위와 사용가능시간제한, 그리고 접근 속성이 정의되어있다.) Access token은 authorization server가 third-party client에게 발급한다. third-party client는 이 access token 으로 resource owner에 접근할 수 있다.
For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo- sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation- specific credentials (access token). 예) 사용자(resource owner)가 사진앱(client)을 다운받아서 인스타그램(resource server)의 비밀사진첩에 접근하는데 이 앱에 내 비밀번호를 넣지 않아도 된다. 그냥 인스타그램의 인증서버(authorization server)에 바로 접근해서 이 앱을 허가(trusted)시켜버리면 프린팅서비스앱(client)에 접근권한(delegation-specific credentials (access token))을 준다
This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope. 이 스펙은 Http하에 사용하도록 설계되었고 http외의 프로토콜과 사용하는것은 알 바 아님.
The OAuth 1.0 protocol ([RFC5849]), published as an informational document, was the result of a small ad hoc community effort. This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community. The OAuth 2.0 protocol is not backward compatible with OAuth 1.0. The two versions may co-exist on the network, and implementations may choose to support both. However, it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments. The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should approach this document without any assumptions as to its structure and details. OAuth1하고 뭐 어쩌고