Internet DRAFT - draft-zhou-oauth-owner-auth
draft-zhou-oauth-owner-auth
OAuth S. Zhou
Internet-Draft ZTE Corporation
Intended status: Standards Track December 18, 2012
Expires: June 21, 2013
Owner Authorization Grant Type Profile for OAuth 2.0
draft-zhou-oauth-owner-auth-01
Abstract
This document proposes to let resource owners directly authorize a
relying party to access resources stored in other resource servers .
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhou Expires June 21, 2013 [Page 1]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Potential Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Direct Authorization . . . . . . . . . . . . . . . . . . . 4
2.2. Proxy Authorization . . . . . . . . . . . . . . . . . . . . 5
3. Owner_authorization Grant . . . . . . . . . . . . . . . . . . . 5
4. Owner_authorization_code and Owner_authorization_type . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:owner_authorization . . . 8
5.2. owner_authorization_code Parameter Registration . . . . . . 8
5.3. owner_authorization_type Parameter Registration . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Zhou Expires June 21, 2013 [Page 2]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
1. Introduction
The OAuth 2.0 authorization framework [I-D.ietf-oauth-v2] enables a
client (a third-party application ) to obtain limited access to an
HTTP service, where resources controlled by the resource owners are
hosted, in a way resource owners don't have to leak their credentials
with the resource servers to clients, instead clients are granted
time limited access tokens from interacting with resource owners and
an authorization server.
There are four basic grant types defined in [I-D.ietf-oauth-v2]:
"authorization_code","password","client_credentials","refresh_token".
The grant type of authorization_code enables a client to get an
authorization code from the authorization server, and trades in an
access token from the authorization server later by presenting the
authorization code. For the grant type of password, a client uses
resource owner's password credential as an authorization code to get
an access token from the authorization server. It is used when
clients are trusted by resource owners so that resource owners can
leak their password credentials to them. For the grant type of
client_credentials, a client uses the credential of itself as an
authorization code to get an access token from the authorization
server. It is used when clients have control of the resources or
resource owners have authorized the authorization servers. The grant
type of refresh_token is used when clients want to have a new access
token by presenting a refresh token as an authorization code.
The grant type of authorization_code is representative of all the
OAuth's grant types. But it requires multiple interactive exchanges
between resource owners and authorization servers before issuing
authorization codes. Sometime this interactive procedure may not be
necessary. And it is more natural to let a resource owner rather
than an authorization server to issue authorization codes, after all
the access to the resources should be determined by the resource
owners ultimately and entirely. In this document, we define a grant
type "owner_authorization" that allows resourse owners to authorize
clients directly, and parameters "owner_authorization_code",
"owner_authorization_type" that allow for detailed definition and
expansion of the grant type of owner_authorization.
The OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions] is an
abstract extension to OAuth 2.0 that provides a general framework for
the use of Assertions as client credentials and/or authorization
grants with OAuth 2.0. This document could be viewed as a specific
profile of Assertion Framework to deploy assertions issued by
Resource owners as authorization grant.
Zhou Expires June 21, 2013 [Page 3]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Potential Use Cases
2.1. Direct Authorization
Description:
Alice has some data stored at a resource server www.
resourceserver.example , she wants a third service provider
www.client.example to access some of the data according to her
authorization. But she is reluctent to input her her password or
other credential online to the Authorization Server although she
knows TLS is in place between her computer terminal and AS, she
whould like to run an authorization grant generation programm locally
so as to keep confidentiality ty of her credential. The
authorziation grant generation programm could be downloaded from AS.
Pre-conditions:
o Alice and AS has a shared secret key
o The application at www.client.example is not capable of validating
its authorization grant.
Post-conditions:
A successful procedure results in the application at
www.client.example receiving an access token after authenticating to
the authorization server and presenting the authorization grant
obtained from Alice.
Requirements:
o Authentication of the application at www.client.example to the
authorization server is required
o The authorization server must be capable of validating
authorization grant presented by the application running at
www.client.example
Zhou Expires June 21, 2013 [Page 4]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
2.2. Proxy Authorization
Description:
Alice has her financial data stored at a financial company www.
financial.example, her lawyer needs to obtain authenticated access to
some of her financial data to run applications at www.lawyer.example.
Alice and the lawyer have rather long term trust relationship, but
still Alice is not willing to leak her secret credential to the
lawyer. The applications at www.lawyer.example may change over the
time, Alice is not willing to be bothered by generating assertion
each time a new application comes out.
Pre-conditions:
o Alice has a secret private key and corresponding public key , Alice
could generate a proxy private key for her lawyer
o Lawyer could generate a proxy signature based on his proxy private
key for any application at www.lawyer.example that is in the scope
(the scope could be as broad as any application at the website
www.lawyer.example) of the proxy private key.
Post-conditions:
A successful procedure results in the application at
www.lawyer.example receiving an access token after presenting a proxy
signature to the authorization server specified by Alice.
Requirements:
o Authentication of the application at www.lawyer.example to the
application at www.financial.example is required
o The authorization server must be capable of validating proxy
signature presented by the application running at www.lawyer.example
3. Owner_authorization Grant
The owner_authorization grant type can be used to obtain both access
tokens and refresh tokens for confidential clients.
Zhou Expires June 21, 2013 [Page 5]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
+----------+
| resource |
| owner |
+----------+
^
|
(B)
|
v
+----------+ +---------------+
| -+----(A2)- Client Identifier ---->| |
| User- | &redirection URI | Authorization |
| Agent +<---(B)-- Script----------------<| Server |
+-|----|---+ +---------------+
| | ^ v
(A1) (C) Delegation code | |
| | | |
^ v | |
+---------+ | |
| |>--(D)--(Derivative) Delegation Code--' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Figure 1
The flow illustrated in Figure 1 includes the following steps:
(A1) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes its
client identifier, requested scope, local state, and a redirection
URI to which the resource owner will send the delegation code back
once access is granted (or denied).
(A2) The user-agent is redirected to Authorization Server.
(B) The redirection from user-agent leads it to download script from
AS, some information in the redirection will be extracted into the
script and user is prompted to input password or private key.
(C) The resource owner fills in required items through Script and
generates a delegation code,sends the delegation code to client
(redirection URI) through user-agent.
(D) The client requests an access token from the authorization
server's token endpoint by including the delegation code received in
the previous step, or a derivative delegation code calculated from
Zhou Expires June 21, 2013 [Page 6]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
delegation code. When making the request, the client authenticates
with the authorization server.
(E) The authorization server authenticates the client, validates the
(derivative) delegation code. If valid, the authorization server
responds back with an access token and optional refresh token.
4. Owner_authorization_code and Owner_authorization_type
Parameters owner_authorization_type and owner_authorization_code are
used to define variable implementations of owner_authorization grant.
For example, an owner_authorization_type="signature" could be
defined, and the owner_authorization_code can include (client
identity, resource owner identity, resource identity, authorization
time period, signature), where signature is a digital signature
computed on all the other information concatenated together using the
private key of the resource owners. Authorization server verifies
the signature, if valid, generates an access token and sends to the
client.
An owner_authorization_type="proxy_signature" could be defined, and
the owner_authorization_code can include (client identity, resource
owner identity, resource identity, authorization time period, psig),
where psig is a proxy signature computed on all the other information
concatenated together and the proxy private key assigned to clients
by resource owners . Authorization server verifies the proxy
signature, if valid, generates an access token and sends to the
client.
An owner_authorization_type="mac1" could be defined, and the
owner_authorization_code can include (client identity, resource owner
identity, resource identity, authorization time period, random token,
mac1), where mac1 is a message authentication code computed on all
the other information concatenated together and the secret key shared
between resource owner and authorization server. Authorization
server recalculates the message authentication code, if the result
equals mac1, generates an access token and sends to the client.
An owner_authorization_type="mac2" could be defined, and the
owner_authorization_code can include (client identity, resource owner
identity, resource identity, authorization time period, com, mac2,
PoK), where mac2 is a message authentication code computed on all the
other information concatenated together and the secret key shared
between resource owner and authorization server, and com is the
result of comitment(random token, client secret key) where client
secret key is the secret between clients and AS, PoK is a proof of
Zhou Expires June 21, 2013 [Page 7]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
knowledge of client secret key in com. Authorization server
recalculates the message authentication code, if the result equals
mac2, then continue to verify PoK , if valid, generates an access
token and sends to the client.
5. IANA Considerations
5.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:owner_authorization
This is a request to IANA to register the value "grant-
type:owner_authorization" in the registry urn:ietf:params:oauth
established in [I-D.ietf-oauth-urn-sub-ns]
o URN: urn:ietf:params:oauth:grant- type:owner_authorization
o Common Name: Owner Authorization Grant Type Profile for OAuth 2.0
o Change controller: IETF
o Specification Document: this document
5.2. owner_authorization_code Parameter Registration
The following is the parameter registration request for the
"owner_authorization_code" parameter according to [I-D.ietf-oauth-v2]
o Parameter name: owner_authorization_code
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[this document]]
5.3. owner_authorization_type Parameter Registration
The following is the parameter registration request for the
"owner_authorization_type" parameter according to
[I-D.ietf-oauth-v2],
o Parameter name: owner_authorization_type
o Parameter usage location: token request
o Change controller: IETF
Zhou Expires June 21, 2013 [Page 8]
Internet-Draft draft-zhou-oauth-owner-auth-00 December 2012
o Specification document(s): [[this document]]
6. Security Considerations
TBD.
7. Normative References
[I-D.ietf-oauth-urn-sub-ns]
Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", draft-ietf-oauth-urn-sub-ns-06 (work in
progress), July 2012.
[I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
Author's Address
Sujing Zhou
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
R.R.China
Email: zhou.sujing@zte.com.cn
Zhou Expires June 21, 2013 [Page 9]
