Monthly Archives: March 2015

OAuth2 Spec. – 1.3. Authorization Grant

1.3. Authorization Grant

An authorization grant is a credential / representing the resource owner’s authorization / (to access its protected resources) / used by the client / to obtain an access token. // This specification defines four grant types / — authorization code, implicit, resource owner password credentials, and client credentials — as well as an extensibility mechanism // for defining additional types.

authorization grant는 자격이다. / resource owner의 authorization인증을 대표하는 / (이것의 protected보호된 resources자원에 접근하기 위해) / client에 의해 사용된다 / access token을 얻기 위해. //
이 규격은 네 가지 인증 타입을 정의한다 / — 인증코드, 내재화, 자원소유자의 비밀번호 인증정보, client 인증정보 — / 게다가 추가적인 타입을 위한 확장 메커니즘

authorization grant는 client가 resource owner의 protected resource에 접근하기 위한 access token을 받기위한 인증을 말한다.
이 규격서는 네가지 인증 방식grant types을 정의한다
authorization code
implicit
resource owner password credentials
client credentials
위 네개 뿐 아니라 추가로 확장도 가능하다

1.3.1. Authorization Code

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

authorization server : client와 resource owner사이의 중재자 역할을 한다
authorization code는 authorization server에서 얻을 수 있다.
client는 authorization을 resource owner에 직접 요청하는 대신에 resource owner를 authorization server에 연결해줄 수 잇다. ([RFC2616]에 정의되어있는 user-agent를 이용)

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.

resource owner에서 client로 authorization code를 전달하기 전에 authorization server는 resource owner를 인증하고 authorization을 얻는다. 왜냐하면 resource owner는 authorization server과만 인증을 하고 resource owner의 인증정보는 client와 공유되지 않기 때문이다.

The authorization code provides a few important security benefits,
such as the ability to authenticate the client, as well as the
transmission of the access token directly to the client without
passing it through the resource owner’s user-agent and potentially
exposing it to others, including the resource owner.

authorization code는 몇가지 보안 잇점이 있다. client를 인증하는 기능, 예를들어) access token을 resource owner의 user-agent를 거치지 않고 직접 client에 전달한다던가… 그리고 잠재적으로 이게 resource를 포함해서 제3자에게 노출될 가능성 없다

1.3.2. Implicit

The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such
as JavaScript. In the implicit flow, instead of issuing the client
an authorization code, the client is issued an access token directly

Implicit 인증은 authorization code의 절차를 간소화 시킨 것이다. JavaScript와 같은 Brower단의 스크립트 언어에서 쓸 수 있도록. client에게 authorization code를 발급하는 대신에 client는 access token을 직접 발급한다.

(as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).
(resource owner의 인증의 결과로). grant type인증 타입이 implicit인 경우 중재해주는 credential이 발급되지 않는다. (authorization code라던가…)(그리고 나중에 access token을 얻을 때 쓰인다)

When issuing an access token during the implicit grant flow, the
authorization server does not authenticate the client. In some
cases, the client identity can be verified via the redirection URI
used to deliver the access token to the client. The access token may
be exposed to the resource owner or other applications with access to
the resource owner’s user-agent.

implicit 인증 흐름에서 access token이 발급될 때 authorization server는 client를 인증해주지않느다. 간혹, client identify가 redirection uri로 전달된 access token으로 인증되기도한다. access token은 노출될 수 있다. resource owner에게 또는 다른 application이 reosurce owner의 user-agent에 접근할 때

Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application),
since it reduces the number of round trips required to obtain an
access token. However, this convenience should be weighed against
the security implications of using implicit grants, such as those
described in Sections 10.3 and 10.16, especially when the
authorization code grant type is available.

implicit 인증은 민감성과 효율을 증가시킨다.(TODO)

1.3.3. Resource Owner Password Credentials

The resource owner password credentials (i.e., username and password)
can be used directly as an authorization grant to obtain an access
token. The credentials should only be used when there is a high
degree of trust between the resource owner and the client (e.g., the
client is part of the device operating system or a highly privileged
application), and when other authorization grant types are not
available (such as an authorization code).

Even though this grant type requires direct client access to the
resource owner credentials, the resource owner credentials are used
for a single request and are exchanged for an access token. This
grant type can eliminate the need for the client to store the
resource owner credentials for future use, by exchanging the
credentials with a long-lived access token or refresh token.

1.3.4. Client Credentials

The client credentials (or other forms of client authentication) can
be used as an authorization grant when the authorization scope is
limited to the protected resources under the control of the client,
or to protected resources previously arranged with the authorization
server. Client credentials are used as an authorization grant
typically when the client is acting on its own behalf (the client is
also the resource owner) or is requesting access to protected
resources based on an authorization previously arranged with the
authorization server.

OAuth2 Spec. – 1.2. Protocol Flow

https://tools.ietf.org/html/rfc6749#section-1.2

1.2. Protocol Flow
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 Flow The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps: OAuth 2.0의 개념은 Figure 1과 같다. (A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary. client는 resource owner에게 인증을 요청한다. 인증 요청은 resource owner에게 직접 할 수도 있는데 보통 authorization server를 통해 간접적으로 한다. (B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server. client는 resource owner의 인증정보를 갖고있는 authorization grant를 받는다. 이 규격서에 네가지 grant type이 정의되어있다. client에서 알아서 골라쓰면되고 authorization server는 이 방법을 모두 지원한다. **라고 하지만 이 스펙을 온전히 지원하지 않는 경우가 많은 것 같다 (C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant. client는 authorization grant를 에서 authorization server에게 access token요청을 보낸다. (D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token. authorization server는 client를 인증하고 authorization grant를 검증한다. 맞으면 access token을 발행해준다. (E) The client requests the protected resource from the resource server and authenticates by presenting the access token. client에서 resource server에 protected resource를 요청한다. 이 때, access token을 함께 보내서 인증을 처리한다. (F) The resource server validates the access token, and if valid, serves the request. resource server에서 access token을 확인해서 처리. The preferred method for the client to obtain an authorization grant from the resource owner (depicted in steps (A) and (B)) is to use the authorization server as an intermediary, which is illustrated in Figure 3 in Section 4.1. 위의 (A), (B)를 쓰는 방법보다 4.1에 나와있는 방법을 추천한다. * 위의 방법은 client에 계정정보가 노출됨.

OAuth2 Spec. – 1.1. Roles

https://tools.ietf.org/html/rfc6749#section-1.1

1.1. Roles

OAuth defines four roles:
OAuth에는 네가지 역할이 있다.

resource owner
리소스 주인님
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
protected resource로의 접근을 허가해 줄 수 있는 사람 또는 서비스. resource owner가 사람인 경우는 end-user(최종사용자,서비스사용자)

resource server
리소스 서버
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
protected resource를 가지고있는 서버. access token을 이용한 요청을 받아들이고 응답해줌. 그냥 리소스 서버

client
손님(OAuth2로 인증하는 모바일앱, 웹사이트.. 예) 네이버 App은 Naver의 Client앱이다)
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term “client” does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
resource owner대신에 protected resource를 관리하는 응용프로그램.
‘client’는 특정 구현방식을 갖고있지 않다. server, desktop, 또는 다른 device에서 구현 가능하다.

authorization server
인증 서버
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
client가 resource owner임이 확인되었거나 허가를 받은 경우.
client에게 access token을 발행하는 서버

The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.
authorization server와 resource server 간의 통신은 이 규격에 포함되지 않는다.
이 부분은 맘대로하라구

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하고 뭐 어쩌고

OAuth2 Spec. – 개요

https://tools.ietf.org/html/rfc6749

Abstract

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.

개요

OAuth 2.0 인증 프레임워크는 서드파티 어플리케이션이 HTTP service에 제한적으로 접근할 수 있게 해 준다. resource owner를 대신하여 resource owner와 HTTP service 사이의 인증을 조율해서 third-party application이 접근 권한을 갖게 된다. 이 스펙은 OAuth1을 대체한다.