One document matched: draft-zhou-oauth-owner-auth-00.txt
OAuth S. Zhou
Internet-Draft ZTE Corporation
Intended status: Standards Track September 11, 2012
Expires: March 15, 2013
Owner Authorization Grant Type Profile for OAuth 2.0
draft-zhou-oauth-owner-auth-00
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 March 15, 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 March 15, 2013 [Page 1]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Owner_authorization Grant . . . . . . . . . . . . . . . . . . . 4
3. Owner_authorization_code and Owner_authorization_type . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:owner_authorization . . . 6
4.2. owner_authorization_code Parameter Registration . . . . . . 6
4.3. owner_authorization_type Parameter Registration . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhou Expires March 15, 2013 [Page 2]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 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.
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].
Zhou Expires March 15, 2013 [Page 3]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 2012
2. Owner_authorization Grant
The owner_authorization grant type can be used to obtain both access
tokens and refresh tokens for confidential clients.
+----------+
| 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
Zhou Expires March 15, 2013 [Page 4]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 2012
(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
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.
3. 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,
Zhou Expires March 15, 2013 [Page 5]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 2012
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
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.
4. IANA Considerations
4.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
4.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]]
4.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
Zhou Expires March 15, 2013 [Page 6]
Internet-Draft draft-zhou-oauth-owner-auth-00 September 2012
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[this document]]
5. Security Considerations
TBD.
6. 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 March 15, 2013 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:17 |