diff options
Diffstat (limited to 'doc/specs/draft-ietf-oauth.html')
| -rw-r--r-- | doc/specs/draft-ietf-oauth.html | 3072 |
1 files changed, 0 insertions, 3072 deletions
diff --git a/doc/specs/draft-ietf-oauth.html b/doc/specs/draft-ietf-oauth.html deleted file mode 100644 index 6cc7582..0000000 --- a/doc/specs/draft-ietf-oauth.html +++ /dev/null @@ -1,3072 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<!-- saved from url=(0052)http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html --> -<HTML lang="en"><HEAD><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><TITLE>The OAuth 2.0 Protocol</TITLE> - -<META name="description" content="The OAuth 2.0 Protocol"> -<META name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)"> -<META name="viewport" content="width=600;"> -<STYLE type="text/css"><!-- - body { - font-family: verdana, charcoal, helvetica, arial, sans-serif; - font-size: 85%; - max-width: 80ex; - color: #000; background-color: #FFF; - margin: 2em; - } - h1, h2, h3, h4, h5, h6 { - font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; - font-weight: bold; font-style: normal; - } - h1 { color: #900; background-color: transparent; text-align: right; } - h3 { color: #333; background-color: transparent; } - - td.RFCbug { - font-size: x-small; text-decoration: none; - width: 30px; height: 30px; padding-top: 2px; - text-align: justify; vertical-align: middle; - background-color: #000; - } - td.RFCbug span.RFC { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: bold; color: #666; - } - td.RFCbug span.hotText { - font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; - font-weight: normal; text-align: center; color: #FFF; - } - - table.TOCbug { width: 30px; height: 15px; } - td.TOCbug { - text-align: center; width: 30px; height: 15px; - color: #FFF; background-color: #900; - } - td.TOCbug a { - font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; - font-weight: bold; font-size: x-small; text-decoration: none; - color: #FFF; background-color: transparent; - } - - td.header { - font-family: arial, helvetica, sans-serif; font-size: x-small; - vertical-align: top; width: 33%; - color: #FFF; background-color: #666; - } - td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } - td.author-text { font-size: x-small; } - - /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ - a.info { - /* This is the key. */ - position: relative; - z-index: 24; - text-decoration: none; - } - a.info:hover { - z-index: 25; - color: #FFF; background-color: #900; - } - a.info span { display: none; } - a.info:hover span.info { - /* The span will display just on :hover state. */ - display: block; - position: absolute; - font-size: smaller; - top: 2em; left: -5em; width: 15em; - padding: 2px; border: 1px solid #333; - color: #900; background-color: #EEE; - text-align: left; - } - - a { font-weight: bold; } - a:link { color: #900; background-color: transparent; } - a:visited { color: #633; background-color: transparent; } - a:active { color: #633; background-color: transparent; } - - p { margin-left: 2em; margin-right: 2em; } - p.copyright { font-size: x-small; } - p.toc { font-size: 85%; - max-width: 80ex; - font-weight: bold; margin-left: 3em; } - table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } - td.toc { font-size: 85%; - max-width: 80ex; - font-weight: bold; vertical-align: text-top; } - - ol.text { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - - /* RFC-2629 <spanx>s and <artwork>s. */ - em { font-style: italic; } - strong { font-weight: bold; } - dfn { font-weight: bold; font-style: normal; } - cite { font-weight: normal; font-style: normal; } - tt { color: #036; } - tt, pre, pre dfn, pre em, pre cite, pre span { - font-family: "Courier New", Courier, monospace; font-size: small; - } - pre { - text-align: left; padding: 4px; - color: #000; background-color: #CCC; - } - pre dfn { color: #900; } - pre em { color: #66F; background-color: #FFC; font-weight: normal; } - pre .key { color: #33C; font-weight: bold; } - pre .id { color: #900; } - pre .str { color: #000; background-color: #CFF; } - pre .val { color: #066; } - pre .rep { color: #909; } - pre .oth { color: #000; background-color: #FCF; } - pre .err { background-color: #FCC; } - - /* RFC-2629 <texttable>s. */ - table.all, table.full, table.headers, table.none { - font-size: 85%; - max-width: 80ex; - text-align: center; border-width: 2px; - vertical-align: top; border-collapse: collapse; - } - table.all, table.full { border-style: solid; border-color: black; } - table.headers, table.none { border-style: none; } - th { - font-weight: bold; border-color: black; - border-width: 2px 2px 3px 2px; - } - table.all th, table.full th { border-style: solid; } - table.headers th { border-style: none none solid none; } - table.none th { border-style: none; } - table.all td { - border-style: solid; border-color: #333; - border-width: 1px 2px; - } - table.full td, table.headers td, table.none td { border-style: none; } - - hr { height: 1px; } - hr.insert { - width: 80%; border-style: none; border-width: 0; - color: #CCC; background-color: #CCC; - } ---></STYLE> -</HEAD><BODY> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<TABLE summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><TBODY><TR><TD><TABLE summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> -<TBODY><TR><TD class="header">Network Working Group</TD><TD class="header">E. Hammer-Lahav, Ed.</TD></TR> -<TR><TD class="header">Internet-Draft</TD><TD class="header">Yahoo!</TD></TR> -<TR><TD class="header">Obsoletes: <A href="http://tools.ietf.org/html/rfc5849">5849</A> (if approved)</TD><TD class="header">D. Recordon</TD></TR> -<TR><TD class="header">Intended status: Standards Track</TD><TD class="header">Facebook</TD></TR> -<TR><TD class="header">Expires: January 12, 2011</TD><TD class="header">D. Hardt</TD></TR> -<TR><TD class="header"> </TD><TD class="header">Microsoft</TD></TR> -<TR><TD class="header"> </TD><TD class="header">July 11, 2010</TD></TR> -</TBODY></TABLE></TD></TR></TBODY></TABLE> -<H1><BR>The OAuth 2.0 Protocol<BR>draft-ietf-oauth-v2-10</H1> - -<H3>Abstract</H3> - -<P> - This specification describes the OAuth 2.0 protocol. - -</P> -<H3>Status of this Memo</H3> -<P> -This Internet-Draft is submitted in full -conformance with the provisions of BCP 78 and BCP 79.</P> -<P> -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/.</P> -<P> -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.”</P> -<P> -This Internet-Draft will expire on January 12, 2011.</P> - -<H3>Copyright Notice</H3> -<P> -Copyright (c) 2010 IETF Trust and the persons identified as the -document authors. All rights reserved.</P> -<P> -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.</P> -<A name="toc"></A><BR><HR> -<H3>Table of Contents</H3> -<P class="toc"> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor1">1.</A> -Introduction<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor2">1.1.</A> -Notational Conventions<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor3">1.2.</A> -Terminology<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor4">1.3.</A> -Overview<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor5">1.4.</A> -Client Profiles<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor6">1.4.1.</A> -Web Server<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-agent">1.4.2.</A> -User-Agent<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor7">1.4.3.</A> -Native Application<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor8">1.4.4.</A> -Autonomous<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">2.</A> -Client Credentials<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor9">2.1.</A> -Client Password Credentials<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">3.</A> -Obtaining End-User Authorization<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor10">3.1.</A> -Authorization Response<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#auth-error">3.2.</A> -Error Response<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#auth-error-codes">3.2.1.</A> -Error Codes<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#obtaining-token">4.</A> -Obtaining an Access Token<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-grant-types">4.1.</A> -Access Grant Types<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor11">4.1.1.</A> -Authorization Code<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor12">4.1.2.</A> -Resource Owner Password Credentials<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor13">4.1.3.</A> -Assertion<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#token-refresh">4.1.4.</A> -Refresh Token<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-token-response">4.2.</A> -Access Token Response<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#token-error">4.3.</A> -Error Response<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#token-error-codes">4.3.1.</A> -Error Codes<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-resource">5.</A> -Accessing a Protected Resource<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor14">5.1.</A> -Authenticated Requests<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#authz-header">5.1.1.</A> -The Authorization Request Header Field<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#query-param">5.1.2.</A> -URI Query Parameter<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#body-param">5.1.3.</A> -Form-Encoded Body Parameter<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#authn-header">5.2.</A> -The WWW-Authenticate Response Header Field<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#resource-error-codes">5.2.1.</A> -Error Codes<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor15">6.</A> -Extensibility<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor16">6.1.</A> -Defining New Client Credentials Types<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor17">6.2.</A> -Defining New Endpoint Parameters<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor18">6.3.</A> -Defining New Header Field Parameters<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor19">6.4.</A> -Defining New Access Grant Types<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor20">7.</A> -Security Considerations<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor21">8.</A> -IANA Considerations<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#parameters-registry">8.1.</A> -The OAuth Parameters Registry<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor22">8.1.1.</A> -Registration Template<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor23">8.1.2.</A> -Example<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor24">Appendix A.</A> -Examples<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor25">Appendix B.</A> -Contributors<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor26">Appendix C.</A> -Acknowledgements<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#anchor27">Appendix D.</A> -Document History<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#rfc.references1">9.</A> -References<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#rfc.references1">9.1.</A> -Normative References<BR> - <A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#rfc.references2">9.2.</A> -Informative References<BR> -<A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#rfc.authors">§</A> -Authors' Addresses<BR> -</P> -<BR clear="all"> - -<A name="anchor1"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1"></A><H3>1. -Introduction</H3> - -<P> - With the increasing use of distributed web services and cloud computing, third-party - applications require access to server-hosted resources. These resources are usually - protected and require authentication using the resource owner's credentials (typically a - username and password). - -</P> -<P> - In the traditional client-server authentication model, the client accesses a 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 protected resources, - the resource owner shares its credentials with the third-party. This creates several - problems and limitations: - - </P> -<UL class="text"> -<LI> - Third-party applications are required to store the resource-owner's credentials - for future use, typically a password in clear-text. - -</LI> -<LI> - Servers are required to support password (symmetric) authentication, despite the - security weaknesses created by passwords. - -</LI> -<LI> - Third-party applications gain overly broad access to the resource-owner's protected - resources, leaving resource owners without any ability to restrict access to a limited - subset of resources, to limit access duration, or to limit access to the methods - supported by these resources. - -</LI> -<LI> - Resource owners cannot revoke access to an individual third-party without revoking - access to all third-parties, and must do so by changing their password. - -</LI> -</UL><P> - -</P> -<P> - OAuth address these issues by separating the role of the client from that of the - resource owner. In OAuth, the client (which is usually not the resource owner, but is - acting on the resource owner's behalf) 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. - -</P> -<P> - Instead of using the resource owner's credentials to access protected resources, clients - obtain an access token (a string which denotes a specific scope, duration, and other - attributes). The format and structure of access tokens is beyond the scope of this - specification. - -</P> -<P> - 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. The interaction between the authorization server and - resource server is beyond the scope of this specification. - -</P> -<P> - For example, a web 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 an authentication service trusted by the photo sharing service (authorization server) - which issues the printing service delegation-specific credentials (token). - -</P> -<P> - This specification defines the use of OAuth over <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2616">HTTP<SPAN> (</SPAN><SPAN class="info">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</SPAN><SPAN>)</SPAN></A> [RFC2616] - (or HTTP over TLS as defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2818">[RFC2818]<SPAN> (</SPAN><SPAN class="info">Rescorla, E., “HTTP Over TLS,” May 2000.</SPAN><SPAN>)</SPAN></A>). Other specifications may - extend it for use with other transport protocols. - -</P> -<A name="anchor2"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.1"></A><H3>1.1. -Notational Conventions</H3> - -<P> - 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 <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2119">[RFC2119]<SPAN> (</SPAN><SPAN class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - This document uses the Augmented Backus-Naur Form (ABNF) notation of - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#I-D.ietf-httpbis-p1-messaging">[I‑D.ietf‑httpbis‑p1‑messaging]<SPAN> (</SPAN><SPAN class="info">Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.</SPAN><SPAN>)</SPAN></A>. Additionally, the following rules are - included from <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A>: realm, auth-param; from - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC3986">[RFC3986]<SPAN> (</SPAN><SPAN class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</SPAN><SPAN>)</SPAN></A>: URI-Reference; and from - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#I-D.ietf-httpbis-p1-messaging">[I‑D.ietf‑httpbis‑p1‑messaging]<SPAN> (</SPAN><SPAN class="info">Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.</SPAN><SPAN>)</SPAN></A>: OWS, RWS, and quoted-string. - -</P> -<P> - Unless otherwise noted, all the protocol parameter names and values are case sensitive. - -</P> -<A name="anchor3"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.2"></A><H3>1.2. -Terminology</H3> - -<P> - </P> -<BLOCKQUOTE class="text"><DL> -<DT>protected resource</DT> -<DD> - - An access-restricted resource which can be obtained using an OAuth-authenticated - request. - -</DD> -<DT>resource server</DT> -<DD> - - A server capable of accepting and responding to protected resource requests. - -</DD> -<DT>client</DT> -<DD> - - An application obtaining authorization and making protected resource requests. - -</DD> -<DT>resource owner</DT> -<DD> - - An entity capable of granting access to a protected resource. - -</DD> -<DT>end-user</DT> -<DD> - - A human resource owner. - -</DD> -<DT>token</DT> -<DD> - - A string representing an access authorization issued to the client. The string is - usually opaque to the client. Tokens represent specific scopes and durations of - access, granted by the resource owner, and enforced by the resource server and - authorization servers. The token may denote an identifier used to retrieve the - authorization information, or self-contain the authorization information in a - verifiable manner (i.e. a token string consisting of some data and a signature). - Tokens may be pure capabilities. Specific additional authentication credentials may - be required in order for a client to use a token. - -</DD> -<DT>access token</DT> -<DD> - - A token used by the client to make authenticated requests on behalf of the resource - owner. - -</DD> -<DT>refresh token</DT> -<DD> - - A token used by the client to obtain a new access token without having to involve - the resource owner. - -</DD> -<DT>authorization code</DT> -<DD> - A short-lived token representing the access grant provided by the end-user. The - authorization code is used to obtain an access token and a refresh token. - -</DD> -<DT>authorization server</DT> -<DD> - - A server capable of issuing tokens after successfully authenticating the resource - owner and obtaining authorization. The authorization server may be the same server as - the resource server, or a separate entity. - -</DD> -<DT>end-user authorization endpoint</DT> -<DD> - - The authorization server's HTTP endpoint capable of authenticating the end-user and - obtaining authorization. The end-user authorization endpoint is described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>token endpoint</DT> -<DD> - - The authorization server's HTTP endpoint capable of issuing tokens and refreshing - expired tokens. The token endpoint is described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#obtaining-token">Section 4<SPAN> (</SPAN><SPAN class="info">Obtaining an Access Token</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>client identifier</DT> -<DD> - - A unique identifier issued to the client to identify itself to the authorization - server. Client identifiers may have a matching secret. The client identifier is - described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A>. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<A name="anchor4"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.3"></A><H3>1.3. -Overview</H3> - -<P> - OAuth provides a method for clients to access a protected resource on behalf of a - resource owner. Before a client can access a protected resource, it must first obtain - authorization from the resource owner, then exchange the access grant for an access token - (representing the grant's scope, duration, and other attributes). The client accesses the - protected resource by presenting the access token to the resource server. - -</P><BR><HR class="insert"> -<A name="Figure 1"></A> -<DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - +--------+ +---------------+ - | |--(A)-- Authorization Request --->| Resource | - | | | Owner | - | |<-(B)------ Access Grant ---------| | - | | +---------------+ - | | - | | Client Credentials & +---------------+ - | |--(C)------ Access Grant -------->| Authorization | - | Client | | Server | - | |<-(D)------ Access Token ---------| | - | | (w/ Optional Refresh Token) +---------------+ - | | - | | +---------------+ - | |--(E)------ Access Token -------->| Resource | - | | | Server | - | |<-(F)---- Protected Resource -----| | - +--------+ +---------------+ - -</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 1: Abstract Protocol Flow </B></FONT><BR></TD></TR></TBODY></TABLE><HR class="insert"> - -<P> - The abstract flow illustrated in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#Figure 1">Figure 1<SPAN> (</SPAN><SPAN class="info">Abstract Protocol Flow</SPAN><SPAN>)</SPAN></A> includes the following - steps: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>(A)</DT> -<DD> - The client requests authorization from the resource owner. The client should not - request the resource owner's credentials directly. Instead, it should request - authorization via an authorization server or other entities. For example, the client - directs the resource owner to the authorization server which in turn issues it an - access grant. When unavoidable, the client interacts directly with the end-user, - asking for the end-user's username and password. If the client is acting - autonomously, the authorization request is beyond the scope of this specification. - -</DD> -<DT>(B)</DT> -<DD> - The client is issued an access grant which represents the authorization provided by - the resource owner. The access grant can be expressed as: - - -<UL class="text"> -<LI> - Authorization code - an access grant obtained via an authorization server. - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A> describes how to obtain an authorization - code when the end-user is present and using a user-agent. - -</LI> -<LI> - Assertion - an access grant obtained using a different trust framework. - Assertions enable the client to utilize existing trust relationships to obtain an - access token. They provide a bridge between OAuth and other trust frameworks. The - access grant represented by an assertion depends on the assertion type, its - content, and how it was issued, which are beyond the scope of this specification. - -</LI> -<LI> - Resource owner password credentials - obtained when interacting directly with a - resource-owner. Resource owner password credentials (i.e. a username and - password) should only be used when there is a high degree of trust between the - resource owner and the client (e.g. its computer operating system or a highly - privileged application). However, unlike the HTTP Basic authentication scheme - defined in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A>, the resource owner's credentials are used - for a single request and are exchanged for an access token and refresh token. - This eliminates the need for the client to store the resource-owner's credentials - for future use. - -</LI> -</UL> - -</DD> -<DT>(C)</DT> -<DD> - The client requests an access token by authenticating with the authorization server, - and presenting the access grant. The token request is described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#obtaining-token">Section 4<SPAN> (</SPAN><SPAN class="info">Obtaining an Access Token</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>(D)</DT> -<DD> - The authorization server validates the client credentials and the access grant, and - issues an access token with an optional refresh token. Access tokens usually have a - shorter lifetime than the access grant. Refresh tokens usually have a lifetime equal - to the duration of the access grant. When an access token expires, the refresh token - is used to obtain a new access token without having to request another access grant - from the resource owner. - -</DD> -<DT>(E)</DT> -<DD> - The client makes a protected resource request to the resource server, and presents - the access token in order to gain access. Accessing a protected resource is described - in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-resource">Section 5<SPAN> (</SPAN><SPAN class="info">Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>(F)</DT> -<DD> - The resource server validates the access token, and if valid, serves the request. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - When the client is acting on its own behalf (the client is also the resource owner), - the client does not obtain an access grant. The simplified protocol flow is illustrated - in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#Figure 2">Figure 2<SPAN> (</SPAN><SPAN class="info">Protocol Flow for Client Acting On Its Own Behalf</SPAN><SPAN>)</SPAN></A>: - -</P><BR><HR class="insert"> -<A name="Figure 2"></A> -<DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - +--------+ +---------------+ - | |--(C)--- Client Credentials ----->| Authorization | - | | | Server | - | |<-(D)------ Access Token ---------| | - | | +---------------+ - | Client | - | | +---------------+ - | |--(E)------ Access Token -------->| Resource | - | | | Server | - | |<-(F)---- Protected Resource -----| | - +--------+ +---------------+ - -</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 2: Protocol Flow for Client Acting On Its Own Behalf </B></FONT><BR></TD></TR></TBODY></TABLE><HR class="insert"> - -<P> - When the client uses the user-agent profile (described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-agent">Section 1.4.2<SPAN> (</SPAN><SPAN class="info">User-Agent</SPAN><SPAN>)</SPAN></A>), - the authorization request results in an access token, as illustrated in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#Figure 3">Figure 3<SPAN> (</SPAN><SPAN class="info">Indirect Access Grant Protocol Flow</SPAN><SPAN>)</SPAN></A>: - -</P><BR><HR class="insert"> -<A name="Figure 3"></A> -<DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - +--------+ +----------+ +---------------+ - | |--(A)-- Authorization --+- -+-->| | - | | Request | Resource | | Authorization | - | | | Owner | | Server | - | |<-(D)-- Access Token ---+- -+---| | - | | +----------+ +---------------+ - | Client | - | | +---------------+ - | |--(E)-------- Access Token ----------->| Resource | - | | | Server | - | |<-(F)------ Protected Resource --------| | - +--------+ +---------------+ - -</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 3: Indirect Access Grant Protocol Flow </B></FONT><BR></TD></TR></TBODY></TABLE><HR class="insert"> - -<A name="anchor5"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.4"></A><H3>1.4. -Client Profiles</H3> - -<P> - OAuth supports a wide range of client types by providing a rich and extensible framework - for establishing authorization and exchanging it for an access token. The methods detailed - in this specification were designed to accommodate four client types: web servers, - user-agents, native applications, and autonomous clients. Additional authorization flows - and client profiles may be defined by other specifications to cover additional scenarios - and client types. - -</P> -<A name="anchor6"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.4.1"></A><H3>1.4.1. -Web Server</H3> - -<P> - The web server profile is suitable for clients capable of interacting with the end-user's - user-agent (typically a web browser) and capable of receiving incoming requests from the - authorization server (capable of acting as an HTTP server). - -</P><BR><HR class="insert"> -<A name="Figure 4"></A> -<DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - +----------+ Client Identifier +---------------+ - | -+----(A)--- & Redirect URI ------>| | - | End-user | | Authorization | - | at |<---(B)-- User authenticates --->| Server | - | Browser | | | - | -+----(C)-- Authorization Code ---<| | - +-|----|---+ +---------------+ - | | ^ v - (A) (C) | | - | | | | - ^ v | | - +---------+ | | - | |>---(D)-- Client Credentials, --------' | - | Web | Authorization Code, | - | Client | & Redirect URI | - | | | - | |<---(E)----- Access Token -------------------' - +---------+ (w/ Optional Refresh Token) - -</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 4: Web Server Flow </B></FONT><BR></TD></TR></TBODY></TABLE><HR class="insert"> - -<P> - The web server flow illustrated in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#Figure 4">Figure 4<SPAN> (</SPAN><SPAN class="info">Web Server Flow</SPAN><SPAN>)</SPAN></A> includes the following - steps: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>(A)</DT> -<DD> - The web client initiates the flow by redirecting the end-user's user-agent to the - end-user authorization endpoint as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A>. - The client includes its client identifier, requested scope, local state, and a - redirect URI to which the authorization server will send the end-user back once - access is granted (or denied). - -</DD> -<DT>(B)</DT> -<DD> - The authorization server authenticates the end-user (via the user-agent) and - establishes whether the end-user grants or denies the client's access request. - -</DD> -<DT>(C)</DT> -<DD> - Assuming the end-user granted access, the authorization server redirects the - user-agent back to the client to the redirection URI provided earlier. The - authorization includes an authorization code for the client to use to obtain an - access token. - -</DD> -<DT>(D)</DT> -<DD> - The client requests an access token from the authorization server by authenticating - and including the authorization code received in the previous step as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#obtaining-token">Section 4<SPAN> (</SPAN><SPAN class="info">Obtaining an Access Token</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>(E)</DT> -<DD> - The authorization server validates the client credentials and the authorization - code and responds back with the access token. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<A name="user-agent"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.4.2"></A><H3>1.4.2. -User-Agent</H3> - -<P> - The user-agent profile is suitable for client applications residing in a user-agent, - typically implemented in a browser using a scripting language such as JavaScript. These - clients cannot keep client secrets confidential and the authentication of the client is - based on the user-agent's same-origin policy. - -</P> -<P> - Unlike other profiles in which the client makes separate requests for end-user - authorization and access token, the client receives the access token as a result of the - end-user authorization request in the form of an HTTP redirection. The client requests - the authorization server to redirect the user-agent to another web server or local - resource accessible to the user-agent which is capable of extracting the access token - from the response and passing it to the client. - -</P> -<P> - This user-agent profile does not utilize the client secret since the client executables - reside on the end-user's computer or device which makes the client secret accessible - and exploitable. Because the access token is encoded into the redirection URI, it may - be exposed to the end-user and other applications residing on the computer or device. - -</P><BR><HR class="insert"> -<A name="Figure 5"></A> -<DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - +----------+ Client Identifier +----------------+ - | |>---(A)-- & Redirection URI --->| | - | | | | - End <--+ - - - +----(B)-- User authenticates -->| Authorization | - User | | | Server | - | |<---(C)--- Redirect URI -------<| | - | Client | with Access Token | | - | in | in Fragment +----------------+ - | Browser | - | | +----------------+ - | |>---(D)--- Redirect URI ------->| | - | | without Fragment | Web Server | - | | | with Client | - | (F) |<---(E)--- Web Page with ------<| Resource | - | Access | Script | | - | Token | +----------------+ - +----------+ - -</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 5: User-Agent Flow </B></FONT><BR></TD></TR></TBODY></TABLE><HR class="insert"> - -<P> - The user-agent flow illustrated in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#Figure 5">Figure 5<SPAN> (</SPAN><SPAN class="info">User-Agent Flow</SPAN><SPAN>)</SPAN></A> includes the following - steps: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>(A)</DT> -<DD> - The client sends the user-agent to the end-user authorization endpoint as described - in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A>. The client includes its client identifier, - requested scope, local state, and a redirect URI to which the authorization server - will send the end-user back once authorization is granted (or denied). - -</DD> -<DT>(B)</DT> -<DD> - The authorization server authenticates the end-user (via the user-agent) and - establishes whether the end-user grants or denies the client's access request. - -</DD> -<DT>(C)</DT> -<DD> - If the end-user granted access, the authorization server redirects the - user-agent to the redirection URI provided earlier. The redirection URI includes - the access token in the URI fragment. - -</DD> -<DT>(D)</DT> -<DD> - The user-agent follows the redirection instructions by making a request to the web - server which does not include the fragment. The user-agent retains the fragment - information locally. - -</DD> -<DT>(E)</DT> -<DD> - The web server returns a web page (typically an HTML page with an embedded script) - capable of accessing the full redirection URI including the fragment retained by the - user-agent, and extracting the access token (and other parameters) contained in the - fragment. - -</DD> -<DT>(F)</DT> -<DD> - The user-agent executes the script provided by the web server locally, which - extracts the access token and passes it to the client. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<A name="anchor7"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.4.3"></A><H3>1.4.3. -Native Application</H3> - -<P> - Native application are clients running as native code on the end-user's computer or - device (i.e. executing outside a user-agent or as a desktop program). These clients are - often capable of interacting with (or embedding) the end-user's user-agent but are - limited in how such interaction affects their end-user experience. In many cases, - native applications are incapable of receiving direct callback requests from the - server (e.g. firewall, operating system restrictions). - -</P> -<P> - Native application clients can be implemented in different ways based on their - requirements and desired end-user experience. Native application clients can: - - </P> -<UL class="text"> -<LI> - Utilize the end-user authorization endpoint as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A> by launching an external user-agent. The - client can capture the response by providing a redirection URI with a custom URI - scheme (registered with the operating system to invoke the client application), or - by providing a redirection URI pointing to a server-hosted resource under the - client's control which makes the response available to the client (e.g. using the - window title or other locations accessible from outside the user-agent). - -</LI> -<LI> - Utilize the end-user authorization endpoint as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#user-authorization">Section 3<SPAN> (</SPAN><SPAN class="info">Obtaining End-User Authorization</SPAN><SPAN>)</SPAN></A> by using an embedded user-agent. The client - obtains the response by directly communicating with the embedded user-agent. - -</LI> -<LI> - Prompt end-users for their password and use them directly to obtain an access - token. This is generally discouraged, as it hands the end-user's password directly - to the third-party client which in turn has to store it in clear-text. It also - requires the server to support password-based authentication. - -</LI> -</UL><P> - -</P> -<P> - When choosing between launching an external browser and an embedded user-agent, - developers should consider the following: - - </P> -<UL class="text"> -<LI> - External user-agents may improve completion rate as the end-user may already be - logged-in and not have to re-authenticate. - -</LI> -<LI> - Embedded user-agents often offer a better end-user flow, as they remove the need to - switch context and open new windows. - -</LI> -<LI> - Embedded user-agents pose a security challenge because users are authenticating in - an unidentified window without access to the visual protections offered by many - user-agents. - -</LI> -</UL><P> - -</P> -<A name="anchor8"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.1.4.4"></A><H3>1.4.4. -Autonomous</H3> - -<P> - Autonomous clients utilize an existing trust relationship or framework to establish - authorization. Autonomous clients can be implemented in different ways based on their - requirements and the existing trust framework they rely upon. Autonomous clients can: - - </P> -<UL class="text"> -<LI> - Obtain an access token by authenticating with the authorization server using their - client credentials. The scope of the access token is limited to the protected - resources under the control of the client, or that of another resource owner - previously arranged with the authorization server. - -</LI> -<LI> - Use an existing access grant expressed as an assertion using an assertion format - supported by the authorization server. Using assertions requires the client to - obtain a assertion (such as a <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#OASIS.saml-core-2.0-os">SAML<SPAN> (</SPAN><SPAN class="info">Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.</SPAN><SPAN>)</SPAN></A> [OASIS.saml‑core‑2.0‑os] - assertion) from an assertion issuer or to self-issue an assertion. The assertion - format, the process by which the assertion is obtained, and the method of - validating the assertion are defined by the assertion issuer and the authorization - server, and are beyond the scope of this specification. - -</LI> -</UL><P> - -</P> -<A name="client-authentication"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.2"></A><H3>2. -Client Credentials</H3> - -<P> - When interacting with the authorization server, the client identifies itself using a client - identifier and authenticates using a set of client credentials. This specification provides - one mechanism for authenticating the client using password credentials. - -</P> -<P> - The means through which the client obtains its credentials are beyond the scope of this - specification, but usually involve registration with the authorization server. - [[ OAuth Discovery provides one way of obtaining a client password ]] - -</P> -<P> - Due to the nature of some clients, authorization servers SHOULD NOT make assumptions - about the confidentiality of client secrets without establishing trust with the - client operator. Authorization servers SHOULD NOT issue client secrets to clients - incapable of keeping their secrets confidential. - -</P> -<P> - The authorization server MAY authenticate the client using any appropriate set of - credentials and authentication scheme. The client MUST NOT utilize more than one set of - credentials or authentication mechanism with each request. - -</P> -<A name="anchor9"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.2.1"></A><H3>2.1. -Client Password Credentials</H3> - -<P> - The client password credentials use a shared symmetric secret to authenticate the client. - The client identifier and password are included in the request using the - HTTP Basic authentication scheme as defined in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A> by including the - client identifier as the username and client password as the password. - -</P> -<P> - For example (line breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW - Content-Type: application/x-www-form-urlencoded - - grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1& - redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb - -</PRE></DIV> -<P> - Alternatively, the client MAY include the password in the request body using the - following parameter: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>client_secret</DT> -<DD> - REQUIRED. The client password. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example (line breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - grant_type=authorization_code&client_id=s6BhdRkqt3& - client_secret=gX1fBat3bV&code=i1WsRn1uB1& - redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb - -</PRE></DIV> -<P> - The authorization server MUST accept the client credentials using both the request - parameter, and the HTTP Basic authentication scheme. The authorization server MAY - support additional authentication schemes suitable for the transmission of a password. - -</P> -<A name="user-authorization"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.3"></A><H3>3. -Obtaining End-User Authorization</H3> - -<P> - When the client interacts with an end-user, the end-user MUST first grant the client - authorization to access its protected resources. Once obtained, the end-user access - grant is expressed as an authorization code which the client uses to obtain an access - token. To obtain an end-user authorization, the client sends the end-user to the - end-user authorization endpoint. - -</P> -<P> - At the end-user authorization endpoint, the end-user first authenticates with the - authorization server, and then grants or denies the access request. The way in which the - authorization server authenticates the end-user (e.g. username and password login, OpenID, - session cookies) and in which the authorization server obtains the end-user's - authorization, including whether it uses a secure channel such as TLS, is beyond the scope - of this specification. However, the authorization server MUST first verify the identity of - the end-user. - -</P> -<P> - The location of the end-user authorization endpoint can be found in the service - documentation, or can be obtained by using [[ OAuth Discovery ]]. The end-user - authorization endpoint URI MAY include a query component as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC3986">[RFC3986]<SPAN> (</SPAN><SPAN class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</SPAN><SPAN>)</SPAN></A> section 3, which must be retained when adding additional - query parameters. - -</P> -<P> - Since requests to the end-user authorization endpoint result in user authentication and - the transmission of sensitive information, the authorization server SHOULD require the - use of a transport-layer security mechanism such as TLS when sending requests to the - end-user authorization endpoint. - -</P> -<P> - In order to direct the end-user's user-agent to the authorization server, the client - constructs the request URI by adding the following parameters to the end-user - authorization endpoint URI query component using the - <TT>application/x-www-form-urlencoded</TT> format as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>response_type</DT> -<DD> - - REQUIRED. The requested response: an access token, an authorization code, or both. The - parameter value MUST be set to <TT>token</TT> for requesting an - access token, <TT>code</TT> for requesting an authorization code, or - <TT>code_and_token</TT> to request both. The authorization server - MAY decline to provide one or more of these response types. [[ The 'code_and_token' - type is pending use cases and may be removed for the specification ]] - -</DD> -<DT>client_id</DT> -<DD> - - REQUIRED. The client identifier as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>redirect_uri</DT> -<DD> - - REQUIRED, unless a redirection URI has been established between the client and - authorization server via other means. An absolute URI to which the authorization - server will redirect the user-agent to when the end-user authorization step is - completed. The authorization server SHOULD require the client to pre-register - their redirection URI. - -</DD> -<DT>scope</DT> -<DD> - - OPTIONAL. The scope of the access request expressed as a list of space-delimited - strings. The value of the <TT>scope</TT> parameter is defined - by the authorization server. If the value contains multiple space-delimited - strings, their order does not matter, and each string adds an additional access - range to the requested scope. - -</DD> -<DT>state</DT> -<DD> - - OPTIONAL. An opaque value used by the client to maintain state between the request - and callback. The authorization server includes this value when redirecting the - user-agent back to the client. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - The client directs the end-user to the constructed URI using an HTTP redirection - response, or by other means available to it via the end-user's user-agent. The - authorization server MUST support the use of the HTTP <TT>GET</TT> - method for the end-user authorization endpoint, and MAY support the use of the - <TT>POST</TT> method as well. - -</P> -<P> - For example, the client directs the end-user's user-agent to make the following HTTP - request using transport-layer security (line breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - GET /authorize?response_type=code&client_id=s6BhdRkqt3& - redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 - Host: server.example.com - -</PRE></DIV> -<P> - If the client has previously registered a redirection URI with the authorization server, - the authorization server MUST verify that the redirection URI received matches the - registered URI associated with the client identifier. [[ provide guidance on how to - perform matching ]] - -</P> -<P> - Parameters sent without a value MUST be treated as if they were omitted from the request. - The authorization server SHOULD ignore unrecognized request parameters. - -</P> -<P> - The authorization server validates the request to ensure all required parameters are - present and valid. If the request is invalid, the authorization server immediately - redirects the user-agent back to the client using the redirection URI provided with the - appropriate error code as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#auth-error">Section 3.2<SPAN> (</SPAN><SPAN class="info">Error Response</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - The authorization server authenticates the end-user and obtains an authorization - decision (by asking the end-user or by establishing approval via other means). When a - decision has been established, the authorization server directs the end-user's - user-agent to the provided client redirection URI using an HTTP redirection response, - or by other means available to it via the end-user's user-agent. - -</P> -<A name="anchor10"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.3.1"></A><H3>3.1. -Authorization Response</H3> - -<P> - If the end-user grants the access request, the authorization server issues an access - token, an authorization code, or both, and delivers them to the client by adding the - following parameters to the redirection URI (as described below): - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>code</DT> -<DD> - - REQUIRED if the response type is <TT>code</TT> or - <TT>code_and_token</TT>, otherwise MUST NOT be included. The - authorization code generated by the authorization server. The authorization code - SHOULD expire shortly after it is issued. The authorization server MUST invalidate - the authorization code after a single usage. The authorization code is bound to the - client identifier and redirection URI. - -</DD> -<DT>access_token</DT> -<DD> - - REQUIRED if the response type is <TT>token</TT> or - <TT>code_and_token</TT>, otherwise MUST NOT be included. The - access token issued by the authorization server. The access token string MUST comply - with the access-token rule defined in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#authz-header">Section 5.1.1<SPAN> (</SPAN><SPAN class="info">The Authorization Request Header Field</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>expires_in</DT> -<DD> - - OPTIONAL. The duration in seconds of the access token lifetime if an access token - is included. For example, the value <TT>3600</TT> denotes that the - access token will expire in one hour from the time the response was generated by the - authorization server. - -</DD> -<DT>scope</DT> -<DD> - - OPTIONAL. The scope of the access token as a list of space-delimited strings if an - access token is included. The value of the <TT>scope</TT> - parameter is defined by the authorization server. If the value contains multiple - space-delimited strings, their order does not matter, and each string adds an - additional access range to the requested scope. The authorization server SHOULD - include the parameter if the requested scope is different from the one requested by - the client. - -</DD> -<DT>state</DT> -<DD> - - REQUIRED if the <TT>state</TT> parameter was present in the - client authorization request. Set to the exact value received from the client. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - The method in which the authorization server adds the parameter to the redirection - URI is determined by the response type requested by the client in the authorization - request using the <TT>response_type</TT> parameter. - -</P> -<P> - If the response type is <TT>code</TT>, the authorization - server adds the parameters to the redirection URI query component using the - <TT>application/x-www-form-urlencoded</TT> format as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - For example, the authorization server redirects the end-user's user-agent by - sending the following HTTP response: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 302 Found - Location: https://client.example.com/cb?code=i1WsRn1uB1 - -</PRE></DIV> -<P> - If the response type is <TT>token</TT>, the authorization - server adds the parameters to the redirection URI fragment component using the - <TT>application/x-www-form-urlencoded</TT> format as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - For example, the authorization server redirects the end-user's user-agent by - sending the following HTTP response: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 302 Found - Location: http://example.com/rd#access_token=FJQbwq9&expires_in=3600 - -</PRE></DIV> -<P> - If the response type is <TT>code_and_token</TT>, the authorization - server adds the <TT>code</TT> and <TT>state</TT> - parameters to the redirection URI query component and the - <TT>access_token</TT>, <TT>scope</TT>, and - <TT>expires_in</TT> to the redirection URI fragment using the - <TT>application/x-www-form-urlencoded</TT> format as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - For example, the authorization server redirects the end-user's user-agent by - sending the following HTTP response (line breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 302 Found - Location: http://example.com/rd?code=i1WsRn1uB1 - #access_token=FJQbwq9&expires_in=3600 - -</PRE></DIV> -<P> - Clients SHOULD ignore unrecognized response parameters. The sizes of tokens and other - values received from the authorization server, are left undefined by this specification. - Clients should avoid making assumptions about value sizes. Servers should document the - expected size of any value they issue. - -</P> -<A name="auth-error"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.3.2"></A><H3>3.2. -Error Response</H3> - -<P> - If the end-user denies the access request or if the request is invalid, the authorization - server informs the client by adding the following parameters to the redirection URI query - component using the <TT>application/x-www-form-urlencoded</TT> format - as defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>error</DT> -<DD> - - REQUIRED. A single error code as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#auth-error-codes">Section 3.2.1<SPAN> (</SPAN><SPAN class="info">Error Codes</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>error_description</DT> -<DD> - OPTIONAL. A human-readable text providing additional information, used to assist in - the understanding and resolution of the error occurred. - -</DD> -<DT>error_uri</DT> -<DD> - OPTIONAL. A URI identifying a human-readable web page with information about the - error, used to provide the end-user with additional information about the error. - -</DD> -<DT>state</DT> -<DD> - - REQUIRED if the <TT>state</TT> parameter was present in the - client authorization request. Set to the exact value received from the client. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example, the authorization server redirects the end-user's user-agent by - sending the following HTTP response: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 302 Found - Location: https://client.example.com/cb?error=access-denied - -</PRE></DIV> -<A name="auth-error-codes"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.3.2.1"></A><H3>3.2.1. -Error Codes</H3> - -<P> - The authorization server includes one of the following error codes with the error - response: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>invalid_request</DT> -<DD> - - The request is missing a required parameter, includes an unsupported parameter or - parameter value, or is otherwise malformed. - -</DD> -<DT>invalid_client</DT> -<DD> - - The client identifier provided is invalid. - -</DD> -<DT>unauthorized_client</DT> -<DD> - - The client is not authorized to use the requested response type. - -</DD> -<DT>redirect_uri_mismatch</DT> -<DD> - - The redirection URI provided does not match a pre-registered value. - -</DD> -<DT>access_denied</DT> -<DD> - - The end-user or authorization server denied the request. - -</DD> -<DT>unsupported_response_type</DT> -<DD> - - The requested response type is not supported by the authorization server. - -</DD> -<DT>invalid_scope</DT> -<DD> - - The requested scope is invalid, unknown, or malformed. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - [[ Add mechanism for extending error codes ]] - -</P> -<A name="obtaining-token"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4"></A><H3>4. -Obtaining an Access Token</H3> - -<P> - The client obtains an access token by authenticating with the authorization server and - presenting its access grant (in the form of an authorization code, resource owner - credentials, an assertion, or a refresh token). - -</P> -<P> - Since requests to the token endpoint result in the transmission of plain text - credentials in the HTTP request and response, the authorization server MUST require the - use of a transport-layer security mechanism when sending requests to the token endpoints. - Servers MUST support TLS 1.2 as defined in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC5246">[RFC5246]<SPAN> (</SPAN><SPAN class="info">Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</SPAN><SPAN>)</SPAN></A>, and MAY support - additional transport-layer security mechanisms. - -</P> -<P> - The client requests an access token by making an HTTP <TT>POST</TT> - request to the token endpoint. The location of the token endpoint can be found in the - service documentation, or can be obtained by using [[ OAuth Discovery ]]. The token - endpoint URI MAY include a query component. - -</P> -<P> - The client authenticates with the authorization server by adding its client credentials to - the request as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A>. The authorization - server MAY allow unauthenticated access token requests when the client identity does not - matter (e.g. anonymous client) or when the client identity is established via other means - (e.g. using an assertion access grant). - -</P> -<P> - The client constructs the request by including the following parameters using the - <TT>application/x-www-form-urlencoded</TT> format in the HTTP request - entity-body: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>grant_type</DT> -<DD> - - REQUIRED. The access grant type included in the request. Value MUST be one of - <TT>authorization_code</TT>, - <TT>password</TT>, - <TT>assertion</TT>, - <TT>refresh_token</TT>, or <TT>none</TT>. - -</DD> -<DT>client_id</DT> -<DD> - - REQUIRED, unless the client identity can be establish via other means (e.g. assertion). - The client identifier as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>scope</DT> -<DD> - - OPTIONAL. The scope of the access request expressed as a list of space-delimited - strings. The value of the <TT>scope</TT> parameter is defined - by the authorization server. If the value contains multiple space-delimited - strings, their order does not matter, and each string adds an additional access - range to the requested scope. If the access grant being used already represents an - approved scope (e.g. authorization code, assertion), the requested scope MUST be equal - or lesser than the scope previously granted. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - In addition, the client MUST include the appropriate parameters listed for the selected - access grant type as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-grant-types">Section 4.1<SPAN> (</SPAN><SPAN class="info">Access Grant Types</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - Parameters sent without a value MUST be treated as if they were omitted from the request. - The authorization server SHOULD ignore unrecognized request parameters. - -</P> -<A name="access-grant-types"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.1"></A><H3>4.1. -Access Grant Types</H3> - -<P> - The client requests an access token using one of the four types of access grants: - authorization code, password credentials, assertion, or refresh token. - -</P> -<P> - When requesting an access token using the <TT>none</TT> access grant - type (no access grant is included), the client is requesting access to the protected - resources under its control, or those of another resource owner which has been previously - arranged with the authorization server (the method of which is beyond the scope of this - specification). - -</P> -<A name="anchor11"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.1.1"></A><H3>4.1.1. -Authorization Code</H3> - -<P> - The client includes the authorization code using the - <TT>authorization_code</TT> access grant type and the following - parameters: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>code</DT> -<DD> - - REQUIRED. The authorization code received from the authorization server. - -</DD> -<DT>redirect_uri</DT> -<DD> - - REQUIRED. The redirection URI used in the initial request. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example, the client makes the following HTTP request by including its client - credentials via the <TT>client_secret</TT> parameter described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A> and using transport-layer security (line - breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - grant_type=authorization_code&client_id=s6BhdRkqt3& - client_secret=gX1fBat3bV&code=i1WsRn1uB1& - redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb - -</PRE></DIV> -<P> - The authorization server MUST: - - </P> -<UL class="text"> -<LI> - Validate the client credentials (if present) and ensure they match the - authorization code. - -</LI> -<LI> - Verify that the authorization code and redirection URI are all valid and match its - stored association. - -</LI> -</UL><P> - -</P> -<P> - If the request is valid, the authorization server issues a successful response as - described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-token-response">Section 4.2<SPAN> (</SPAN><SPAN class="info">Access Token Response</SPAN><SPAN>)</SPAN></A>. - -</P> -<A name="anchor12"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.1.2"></A><H3>4.1.2. -Resource Owner Password Credentials</H3> - -<P> - The client includes the resource owner credentials using the - <TT>password</TT> access grant type and the following - parameters: [[ add internationalization consideration for username and password ]] - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>username</DT> -<DD> - - REQUIRED. The resource owner's username. - -</DD> -<DT>password</DT> -<DD> - - REQUIRED. The resource owner's password. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example, the client makes the following HTTP request by including its client - credentials via the <TT>client_secret</TT> parameter described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A> and using transport-layer security (line - breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - grant_type=password&client_id=s6BhdRkqt3& - client_secret=47HDu8s&username=johndoe&password=A3ddj3w - -</PRE></DIV> -<P> - The authorization server MUST validate the client credentials (if present) and end-user - credentials and if valid issue an access token response as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-token-response">Section 4.2<SPAN> (</SPAN><SPAN class="info">Access Token Response</SPAN><SPAN>)</SPAN></A>. - -</P> -<A name="anchor13"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.1.3"></A><H3>4.1.3. -Assertion</H3> - -<P> - The client includes the assertion using the <TT>assertion</TT> access - grant type and the following parameters: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>assertion_type</DT> -<DD> - - REQUIRED. The format of the assertion as defined by the authorization server. The - value MUST be an absolute URI. - -</DD> -<DT>assertion</DT> -<DD> - - REQUIRED. The assertion. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example, the client makes the following HTTP request using transport-layer - security, and client authentication is achieved via the assertion (line breaks are - for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - grant_type=assertion& - assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion& - assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D - -</PRE></DIV> -<P> - The authorization server MUST validate the client credentials (if present) and the - assertion and if valid issues an access token response as described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-token-response">Section 4.2<SPAN> (</SPAN><SPAN class="info">Access Token Response</SPAN><SPAN>)</SPAN></A>. The authorization server SHOULD NOT issue a - refresh token (instead, require the client to use the same or new assertion). - -</P> -<P> - Authorization servers SHOULD issue access tokens with a limited lifetime and require - clients to refresh them by requesting a new access token using the same assertion if it - is still valid. Otherwise the client MUST obtain a new valid assertion. - -</P> -<A name="token-refresh"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.1.4"></A><H3>4.1.4. -Refresh Token</H3> - -<P> - The client includes the refresh token using the - <TT>refresh_token</TT> access grant type and the following - parameter: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>refresh_token</DT> -<DD> - - REQUIRED. The refresh token associated with the access token to be refreshed. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example, the client makes the following HTTP request by including its client - credentials via the <TT>client_secret</TT> parameter described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#client-authentication">Section 2<SPAN> (</SPAN><SPAN class="info">Client Credentials</SPAN><SPAN>)</SPAN></A> and using transport-layer security (line - breaks are for display purposes only): - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /token HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - grant_type=refresh_token&client_id=s6BhdRkqt3& - client_secret=8eSEIpnqmM&refresh_token=n4E9O119d - -</PRE></DIV> -<P> - The authorization server MUST verify the client credentials (if present), the validity - of the refresh token, and that the resource owner's authorization is still valid. If - the request is valid, the authorization server issues an access token response as - described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#access-token-response">Section 4.2<SPAN> (</SPAN><SPAN class="info">Access Token Response</SPAN><SPAN>)</SPAN></A>. The authorization server MAY - issue a new refresh token. - -</P> -<A name="access-token-response"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.2"></A><H3>4.2. -Access Token Response</H3> - -<P> - After receiving and verifying a valid and authorized access token request from the - client, the authorization server issues the access token and optional refresh token, - and constructs the response by adding the following parameters to the entity body of - the HTTP response with a 200 (OK) status code: - -</P> -<P> - The token response contains the following parameters: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>access_token</DT> -<DD> - - REQUIRED. The access token issued by the authorization server. The access token - string MUST comply with the access-token rule defined in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#authz-header">Section 5.1.1<SPAN> (</SPAN><SPAN class="info">The Authorization Request Header Field</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>expires_in</DT> -<DD> - - OPTIONAL. The duration in seconds of the access token lifetime. For example, the - value <TT>3600</TT> denotes that the access token will expire in - one hour from the time the response was generated by the authorization server. - -</DD> -<DT>refresh_token</DT> -<DD> - - OPTIONAL. The refresh token used to obtain new access tokens using the same - end-user access grant as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#token-refresh">Section 4.1.4<SPAN> (</SPAN><SPAN class="info">Refresh Token</SPAN><SPAN>)</SPAN></A>. The - authorization server SHOULD NOT issue a refresh token when the access grant type is - set to <TT>none</TT>. - -</DD> -<DT>scope</DT> -<DD> - - OPTIONAL. The scope of the access token as a list of space-delimited strings. The - value of the <TT>scope</TT> parameter is defined by the - authorization server. If the value contains multiple space-delimited strings, - their order does not matter, and each string adds an additional access range to - the requested scope. The authorization server SHOULD include the parameter if the - requested scope is different from the one requested by the client. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - The parameters are including in the entity body of the HTTP response using the - <TT>application/json</TT> media type as defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC4627">[RFC4627]<SPAN> (</SPAN><SPAN class="info">Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</SPAN><SPAN>)</SPAN></A>. The parameters are serialized into a JSON structure by - adding each parameter at the highest structure level. Parameter names and string values - are included as JSON strings. Numerical values are included as JSON numbers. - -</P> -<P> - The authorization server MUST include the HTTP <TT>Cache-Control</TT> - response header field with a value of <TT>no-store</TT> in any - response containing tokens, secrets, or other sensitive information. - -</P> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 200 OK - Content-Type: application/json - Cache-Control: no-store - - { - "access_token":"SlAV32hkKG", - "expires_in":3600, - "refresh_token":"8xLOxBtZp8" - } - -</PRE></DIV> -<P> - Clients SHOULD ignore unrecognized response parameters. The sizes of tokens and other - values received from the authorization server, are left undefined by this specification. - Clients should avoid making assumptions about value sizes. Servers should document the - expected size of any value they issue. - -</P> -<A name="token-error"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.3"></A><H3>4.3. -Error Response</H3> - -<P> - If the token request is invalid or unauthorized, the authorization server constructs - the response by adding the following parameter to the entity body of the HTTP - response using the <TT>application/json</TT> media type: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>error</DT> -<DD> - - REQUIRED. A single error code as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#token-error-codes">Section 4.3.1<SPAN> (</SPAN><SPAN class="info">Error Codes</SPAN><SPAN>)</SPAN></A>. - -</DD> -<DT>error_description</DT> -<DD> - OPTIONAL. A human-readable text providing additional information, used to assist in - the understanding and resolution of the error occurred. - -</DD> -<DT>error_uri</DT> -<DD> - OPTIONAL. A URI identifying a human-readable web page with information about the - error, used to provide the end-user with additional information about the error. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 400 Bad Request - Content-Type: application/json - Cache-Control: no-store - - { - "error":"invalid_request" - } - -</PRE></DIV> -<P> - If the client provided invalid credentials using an HTTP authentication scheme via the - <TT>Authorization</TT> request header field, the authorization server - MUST respond with the HTTP 401 (Unauthorized) status code. Otherwise, the authorization - server SHALL respond with the HTTP 400 (Bad Request) status code. - -</P> -<A name="token-error-codes"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.4.3.1"></A><H3>4.3.1. -Error Codes</H3> - -<P> - The authorization server includes one of the following error codes with the error - response: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>invalid_request</DT> -<DD> - - The request is missing a required parameter, includes an unsupported parameter or - parameter value, repeats a parameter, includes multiple credentials, utilizes - more than one mechanism for authenticating the client, or is otherwise malformed. - -</DD> -<DT>invalid_client</DT> -<DD> - - The client identifier provided is invalid, the client failed to authenticate, the - client did not include its credentials, provided multiple client credentials, or - used unsupported credentials type. - -</DD> -<DT>unauthorized_client</DT> -<DD> - - The authenticated client is not authorized to use the access grant type provided. - -</DD> -<DT>invalid_grant</DT> -<DD> - - The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, - expired authorization token, bad end-user password credentials, or mismatching - authorization code and redirection URI). - -</DD> -<DT>unsupported_grant_type</DT> -<DD> - - The access grant included - its type or another attribute - is not supported by the - authorization server. - -</DD> -<DT>invalid_scope</DT> -<DD> - - The requested scope is invalid, unknown, malformed, or exceeds the previously - granted scope. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - [[ Add mechanism for extending error codes ]] - -</P> -<A name="access-resource"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5"></A><H3>5. -Accessing a Protected Resource</H3> - -<P> - Clients access protected resources by presenting an access token to the resource server. - Access tokens act as bearer tokens, where the token string acts as a shared symmetric - secret. This requires treating the access token with the same care as other secrets (e.g. - end-user passwords). Access tokens SHOULD NOT be sent in the clear over an insecure - channel. - -</P> -<P> - However, when it is necessary to transmit access tokens in the clear without a secure - channel, authorization servers SHOULD issue access tokens with limited scope and lifetime - to reduce the potential risk from a compromised access token. - -</P> -<P> - Clients MUST NOT make authenticated requests with an access token to unfamiliar resource - servers, regardless of the presence of a secure channel. - -</P> -<P> - The resource server MUST validate the access token and ensure it has not expired and - that its scope covers the requested resource. The methods used by the resource server - to validate the access token are beyond the scope of this specification, but generally - involve an interaction or coordination between the resource server and authorization - server. - -</P> -<A name="anchor14"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.1"></A><H3>5.1. -Authenticated Requests</H3> - -<P> - Clients make authenticated token requests using the - <TT>Authorization</TT> request header field. Resource servers MUST - accept authenticated requests using the <TT>OAuth</TT> HTTP - authentication scheme as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#authz-header">Section 5.1.1<SPAN> (</SPAN><SPAN class="info">The Authorization Request Header Field</SPAN><SPAN>)</SPAN></A>, and MAY support - additional methods. - -</P> -<P> - Alternatively, clients MAY attempt to include the access token using the HTTP request - URI in the query component as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#query-param">Section 5.1.2<SPAN> (</SPAN><SPAN class="info">URI Query Parameter</SPAN><SPAN>)</SPAN></A>, or in the HTTP - body when using the <TT>application/x-www-form-urlencoded</TT> content - type as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#body-param">Section 5.1.3<SPAN> (</SPAN><SPAN class="info">Form-Encoded Body Parameter</SPAN><SPAN>)</SPAN></A>. Resource server MAY support these - alternative methods. - -</P> -<P> - Clients SHOULD only use the request URI or body when the - <TT>Authorization</TT> request header field is not available, and MUST - NOT use more than one method in each request. - -</P> -<A name="authz-header"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.1.1"></A><H3>5.1.1. -The Authorization Request Header Field</H3> - -<P> - The <TT>Authorization</TT> request header field is used by clients - to make authenticated token requests. The client uses the - <TT>OAuth</TT> authentication scheme to include the access token in - the request. - -</P> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - GET /resource HTTP/1.1 - Host: server.example.com - Authorization: OAuth vF9dft4qmT - -</PRE></DIV> -<P> - The <TT>Authorization</TT> header field uses the framework defined by - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A> as follows: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - credentials = "OAuth" RWS access-token [ CS 1#auth-param ] - access-token = 1*( quoted-char / <"> ) - - CS = OWS "," OWS - - quoted-char = "!" / "#" / "$" / "%" / "&" / "'" / "(" - / ")" / "*" / "+" / "-" / "." / "/" / DIGIT - / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA - / "[" / "]" / "^" / "_" / "`" / "{" / "|" - / "}" / "~" / "\" / "," / ";" - -</PRE></DIV> -<P> - </P> -<BLOCKQUOTE class="text"> -<P> - NOTE: <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC5849">[RFC5849]<SPAN> (</SPAN><SPAN class="info">Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.</SPAN><SPAN>)</SPAN></A> defines a different format for the - <TT>OAuth</TT> authentication scheme. Resource servers can - differentiate between the two protocol versions based on the presence of the - <TT>oauth_signature_method</TT> which is REQUIRED in the - previous version and is not supported by this specification. - -</P> -</BLOCKQUOTE><P> - -</P> -<A name="query-param"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.1.2"></A><H3>5.1.2. -URI Query Parameter</H3> - -<P> - When including the access token in the HTTP request URI, the client adds the access - token to the request URI query component as defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC3986">[RFC3986]<SPAN> (</SPAN><SPAN class="info">Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</SPAN><SPAN>)</SPAN></A> using - the <TT>oauth_token</TT> parameter. - -</P> -<P> - For example, the client makes the following HTTP request using transport-layer - security: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 - Host: server.example.com - -</PRE></DIV> -<P> - The HTTP request URI query can include other request-specific parameters, in which - case, the <TT>oauth_token</TT> parameters SHOULD be appended - following the request-specific parameters, properly separated by an - <TT>&</TT> character (ASCII code 38). - -</P> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - http://example.com/resource?x=y&oauth_token=vF9dft4qmT - -</PRE></DIV> -<P> - </P> -<BLOCKQUOTE class="text"> -<P> - NOTE: The <TT>oauth_token</TT> parameter is used by the previous - version of the OAuth protocol as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC5849">[RFC5849]<SPAN> (</SPAN><SPAN class="info">Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.</SPAN><SPAN>)</SPAN></A>. Resource - servers can differentiate between the two protocol versions based on the presence - of the <TT>oauth_signature_method</TT> which is REQUIRED in the - previous version and is not supported by this specification. - -</P> -</BLOCKQUOTE><P> - -</P> -<A name="body-param"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.1.3"></A><H3>5.1.3. -Form-Encoded Body Parameter</H3> - -<P> - When including the access token in the HTTP request entity-body, the client adds the - access token to the request body using the <TT>oauth_token</TT> - parameter. The client can use this method only if the following REQUIRED conditions are - met: - - </P> -<UL class="text"> -<LI> - The entity-body is single-part. - -</LI> -<LI> - The entity-body follows the encoding requirements of the - <TT>application/x-www-form-urlencoded</TT> content-type as - defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#W3C.REC-html401-19991224">[W3C.REC‑html401‑19991224]<SPAN> (</SPAN><SPAN class="info">Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</SPAN><SPAN>)</SPAN></A>. - -</LI> -<LI> - The HTTP request entity-header includes the <TT>Content-Type</TT> - header field set to <TT>application/x-www-form-urlencoded</TT>. - -</LI> -<LI> - The HTTP request method is <TT>POST</TT>, - <TT>PUT</TT>, or <TT>DELETE</TT>. - -</LI> -</UL><P> - -</P> -<P> - The entity-body can include other request-specific parameters, in which case, the - <TT>oauth_token</TT> parameters SHOULD be appended following the - request-specific parameters, properly separated by an <TT>&</TT> - character (ASCII code 38). - -</P> -<P> - For example, the client makes the following HTTP request using transport-layer - security: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - POST /resource HTTP/1.1 - Host: server.example.com - Content-Type: application/x-www-form-urlencoded - - oauth_token=vF9dft4qmT - -</PRE></DIV> -<P> - </P> -<BLOCKQUOTE class="text"> -<P> - NOTE: The <TT>oauth_token</TT> parameter is used by the previous - version of the OAuth protocol as described in <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC5849">[RFC5849]<SPAN> (</SPAN><SPAN class="info">Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.</SPAN><SPAN>)</SPAN></A>. Resource - servers can differentiate between the two protocol versions based on the presence - of the <TT>oauth_signature_method</TT> which is REQUIRED in the - previous version and is not supported by this specification. - -</P> -</BLOCKQUOTE><P> - -</P> -<A name="authn-header"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.2"></A><H3>5.2. -The WWW-Authenticate Response Header Field</H3> - -<P> - If the protected resource request contains an invalid access token or is malformed, the - resource server MUST include the HTTP <TT>WWW-Authenticate</TT> - response header field. The <TT>WWW-Authenticate</TT> header field - uses the framework defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A> as follows: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - challenge = "OAuth" RWS token-challenge - - token-challenge = realm - [ CS error ] - [ CS error-desc ] - [ CS error-uri ] - [ CS scope ] - [ CS 1#auth-param ] - - error = "error" "=" <"> token <"> - error-desc = "error_description" "=" quoted-string - error-uri = "error_uri" = <"> URI-Reference <"> - scope = quoted-value / - <"> quoted-value *( 1*SP quoted-value ) <"> - quoted-value = 1*quoted-char - -</PRE></DIV> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 401 Unauthorized - WWW-Authenticate: OAuth realm='Example Service', error='expired-token' - -</PRE></DIV> -<P> - The <TT>realm</TT> attribute is used to provide the protected - resources partition as defined by <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN class="info">Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A>. [[ add explanation ]] - -</P> -<P> - The <TT>error</TT> attribute is used to provide the client with the - reason why the access request was declined. The parameter values are described in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#resource-error-codes">Section 5.2.1<SPAN> (</SPAN><SPAN class="info">Error Codes</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - The <TT>error_description</TT> attribute provides a human-readable - text containing additional information, used to assist in the understanding and - resolution of the error occurred. - -</P> -<P> - The <TT>error_uri</TT> attribute provides a URI identifying a - human-readable web page with information about the error, used to offer the end-user - with additional information about the error. If the value is not an absolute URI, it is - relative to the URI of the requested protected resource. - -</P> -<P> - The <TT>scope</TT> attribute is a space-delimited list of scope values - indicating the required scope of the access token for accessing the requested resource. - -</P> -<A name="resource-error-codes"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.5.2.1"></A><H3>5.2.1. -Error Codes</H3> - -<P> - The authorization server includes one of the following error codes with the error - response: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>invalid_request</DT> -<DD> - - The request is missing a required parameter, includes an unsupported parameter or - parameter value, repeats the same parameter, uses more than one method for - including an access token, or is otherwise malformed. The resource server MUST - respond with the HTTP 400 (Bad Request) status code. - -</DD> -<DT>invalid_token</DT> -<DD> - - The access token provided is invalid. Resource servers SHOULD use this error code - when receiving an expired token which cannot be refreshed to indicate to the client - that a new authorization is necessary. The resource server MUST respond with the - HTTP 401 (Unauthorized) status code. - -</DD> -<DT>expired_token</DT> -<DD> - - The access token provided has expired. Resource servers SHOULD only use this error - code when the client is expected to be able to handle the response and request a - new access token using the refresh token issued with the expired access token. The - resource server MUST respond with the HTTP 401 (Unauthorized) status code. - -</DD> -<DT>insufficient_scope</DT> -<DD> - - The request requires higher privileges than provided by the access token. The - resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY - include the <TT>scope</TT> attribute with the scope necessary to - access the protected resource. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<P> - [[ Add mechanism for extending error codes ]] - -</P> -<P> - If the request lacks any authentication information (i.e. the client was unaware - authentication is necessary or attempted using an unsupported authentication method), - the resource server SHOULD not include an error code or other error information. - -</P> -<P> - For example: - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - HTTP/1.1 401 Unauthorized - WWW-Authenticate: OAuth realm='Example Service' - -</PRE></DIV> -<A name="anchor15"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.6"></A><H3>6. -Extensibility</H3> - -<A name="anchor16"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.6.1"></A><H3>6.1. -Defining New Client Credentials Types</H3> - -<P> - [[ TBD ]] - -</P> -<A name="anchor17"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.6.2"></A><H3>6.2. -Defining New Endpoint Parameters</H3> - -<P> - Applications that wish to define new request or response parameters for use with the - end-user authorization endpoint or the token endpoint SHALL do so in one of two ways: - register them in the parameters registry (following the procedures in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#parameters-registry">Section 8.1<SPAN> (</SPAN><SPAN class="info">The OAuth Parameters Registry</SPAN><SPAN>)</SPAN></A>), or use the <TT>x_</TT> - parameter name prefix. - -</P> -<P> - Parameters utilizing the <TT>x_</TT> parameter name prefix MUST be - limited to vendor-specific extensions that are not commonly applicable, and are specific - to the implementation details of the authorization server where they are used. All other - new parameters MUST be registered, and MUST NOT use the <TT>x_</TT> - parameter name prefix. - -</P> -<P> - Parameter names MUST conform to the param-name ABNF, and parameter values syntax MUST be - well-defined (e.g., using ABNF, or a reference to the syntax of an existing parameter). - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - param-name = 1*name-char - name-char = "-" / "." / "_" / DIGIT / ALPHA - -</PRE></DIV> -<A name="anchor18"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.6.3"></A><H3>6.3. -Defining New Header Field Parameters</H3> - -<P> - Applications that wish to define new parameters for use in the OAuth - <TT>Authorization</TT> or <TT>WWW-Authenticate</TT> - header fields MUST register them in the parameters registry, following the procedures in - <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#parameters-registry">Section 8.1<SPAN> (</SPAN><SPAN class="info">The OAuth Parameters Registry</SPAN><SPAN>)</SPAN></A>. - -</P> -<P> - Parameter names MUST conform to the param-name ABNF and MUST NOT begin with - <TT>x_</TT>. Parameter values MUST conform to the param-value ABNF and - their syntax MUST be well-defined (e.g., using ABNF, or a reference to the syntax of an - existing parameter). - -</P><DIV style="display: table; width: 0; margin-left: 3em; margin-right: auto"><PRE> - param-value = quoted-value | quoted-string - -</PRE></DIV> -<A name="anchor19"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.6.4"></A><H3>6.4. -Defining New Access Grant Types</H3> - -<P> - The assertion access grant type was designed to allow the authorization server to - accept additional access grants not specified. Applications that wish to define - additional access grant types can do so by utilizing a new or existing assertion type - and format. - -</P> -<A name="anchor20"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.7"></A><H3>7. -Security Considerations</H3> - -<P> - [[ TBD ]] - -</P> -<A name="anchor21"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.8"></A><H3>8. -IANA Considerations</H3> - -<A name="parameters-registry"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.8.1"></A><H3>8.1. -The OAuth Parameters Registry</H3> - -<P> - This document establishes the OAuth parameters registry. - -</P> -<P> - Additional parameters to be use in the end-user authorization endpoint request, the - end-user authorization endpoint response, the token endpoint request, the token endpoint - response, the <TT>Authorization</TT> header field, or the - <TT>WWW-Authenticate</TT> header field, are registered on the advice - of one or more Designated Experts (appointed by the IESG or their delegate), with a - Specification Required (using terminology from <A class="info" href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#RFC5226">[RFC5226]<SPAN> (</SPAN><SPAN class="info">Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.</SPAN><SPAN>)</SPAN></A>). However, to - allow for the allocation of values prior to publication, the Designated Expert(s) may - approve registration once they are satisfied that such a specification will be published. - -</P> -<P> - Registration requests should be sent to the [TBD]@ietf.org mailing list for review and - comment, with an appropriate subject (e.g., "Request for parameter: example"). - [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation - with the IESG and IANA. Suggested name: oauth-ext-review. ]] - -</P> -<P> - Before a period of 14 days has passed, the Designated Expert(s) will either approve or - deny the registration request, communicating this decision both to the review list and to - IANA. Denials should include an explanation and, if applicable, suggestions as to how to - make the request successful. Registration requests that are undetermined for a period - longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org - mailing list) for resolution. - -</P> -<A name="anchor22"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.8.1.1"></A><H3>8.1.1. -Registration Template</H3> - -<P> - </P> -<BLOCKQUOTE class="text"><DL> -<DT>Parameter name:</DT> -<DD> - The name requested (e.g., "example"). - -</DD> -<DT>Parameter usage location:</DT> -<DD> - The location(s) where parameter can be used. The possible locations are: the - end-user authorization endpoint request, the end-user authorization endpoint - response, the token endpoint request, the token endpoint response, the - <TT>Authorization</TT> header field, or the - <TT>WWW-Authenticate</TT> header field. - -</DD> -<DT>Change controller:</DT> -<DD> - For standards-track RFCs, state "IETF". For others, give the name of the - responsible party. Other details (e.g., postal address, e-mail address, home page - URI) may also be included. - -</DD> -<DT>Specification document(s):</DT> -<DD> - Reference to document that specifies the parameter, preferably including a URI that - can be used to retrieve a copy of the document. An indication of the relevant - sections may also be included, but is not required. - -</DD> -<DT>Related information:</DT> -<DD> - Optionally, citations to additional documents containing further relevant - information. - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<A name="anchor23"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.8.1.2"></A><H3>8.1.2. -Example</H3> - -<P> - The following is the parameter registration request for the - <TT>scope</TT> parameter as defined in this specification: - - </P> -<BLOCKQUOTE class="text"><DL> -<DT>Parameter name:</DT> -<DD> - scope - -</DD> -<DT>Parameter usage location:</DT> -<DD> - The end-user authorization endpoint request, the end-user authorization endpoint - response, the token endpoint request, the token endpoint response, and the - <TT>WWW-Authenticate</TT> header field. - -</DD> -<DT>Change controller:</DT> -<DD> - IETF - -</DD> -<DT>Specification document(s):</DT> -<DD> - [[ this document ]] - -</DD> -<DT>Related information:</DT> -<DD> - None - -</DD> -</DL></BLOCKQUOTE><P> - -</P> -<A name="anchor24"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.A"></A><H3>Appendix A. -Examples</H3> - -<P> - [[ TBD ]] - -</P> -<A name="anchor25"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.B"></A><H3>Appendix B. -Contributors</H3> - -<P> - The following people contributed to preliminary versions of this document: - Blaine Cook (BT), Brian Eaton (Google), Yaron Goland (Microsoft), Brent Goldman (Facebook), - Raffi Krikorian (Twitter), Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and - concepts within are a product of the OAuth community, WRAP community, and the OAuth Working - Group. - -</P> -<P> - The OAuth Working Group has dozens of very active contributors who proposed ideas and - wording for this document, including: [[ If your name is missing or you think someone - should be added here, please send Eran a note - don't be shy ]] - -</P> -<P> - Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Culver, Brian Ellin, - Igor Faynberg, George Fletcher, Evan Gilbert, Justin Hart, John Kemp, Chasen Le Hara, - Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, Chuck Mortimore, - Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Justin Smith, - Jeremy Suriel, and Franklin Tse. - -</P> -<A name="anchor26"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.C"></A><H3>Appendix C. -Acknowledgements</H3> - -<P> - [[ Add OAuth 1.0a authors + WG contributors ]] - -</P> -<A name="anchor27"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.D"></A><H3>Appendix D. -Document History</H3> - -<P> - [[ to be removed by RFC editor before publication as an RFC ]] - -</P> -<P> - -10 - - </P> -<UL class="text"> -<LI> - Fixed typos. Many editorial changes. Rewrote introduction. removed terminology - grouping. - -</LI> -<LI> - Allowed POST for end-user authorization endpoint. - -</LI> -<LI> - Fixed token endpoint to not require client authentication. - -</LI> -<LI> - Made URI query and POST body 'oauth_token' parameter optional. - -</LI> -<LI> - Moved all parameter names and values to use underscores. - -</LI> -<LI> - Changed 'basic_credentials' to 'password', 'invalid_client_credentials' and - 'invalid_client_id' to 'invalid_client'. - -</LI> -<LI> - Added note that access token requests without an access grant should not include - a refresh token. - -</LI> -<LI> - Changed scheme name from 'Token' to 'OAuth', simplified request format to simple - string for token instead of key=value pair (still supported for extensions). - -</LI> -<LI> - Defined permitted access token string characters (suitable for inclusion in an HTTP - header). - -</LI> -<LI> - Added a note about conflicts with previous versions. - -</LI> -<LI> - Moved 'client_id' definition from client authentication to access token endpoint. - -</LI> -</UL><P> - -</P> -<P> - -09 - - </P> -<UL class="text"> -<LI> - Fixed typos, editorial changes. - -</LI> -<LI> - Added token expiration example. - -</LI> -<LI> - Added scope parameter to end-user authorization endpoint response. - -</LI> -<LI> - Added note about parameters with empty values (same as omitted). - -</LI> -<LI> - Changed parameter values to use '-' instead of '_'. Parameter names still use '_'. - -</LI> -<LI> - Changed authorization endpoint client type to response type with values: code, token, - and both. - -</LI> -<LI> - Complete cleanup of error codes. Added support for error description and URI. - -</LI> -<LI> - Add initial extensibility support. - -</LI> -</UL><P> - -</P> -<P> - -08 - - </P> -<UL class="text"> -<LI> - Renamed verification code to authorization code. - -</LI> -<LI> - Revised terminology, structured section, added new terms. - -</LI> -<LI> - Changed flows to profiles and moved to introduction. - -</LI> -<LI> - Added support for access token rescoping. - -</LI> -<LI> - Cleaned up client credentials section. - -</LI> -<LI> - New introduction overview. - -</LI> -<LI> - Added error code for invalid username and password, and renamed error code to be more - consistent. - -</LI> -<LI> - Added access grant type parameter to token endpoint. - -</LI> -</UL><P> - -</P> -<P> - -07 - - </P> -<UL class="text"> -<LI> - Major rewrite of entire document structure. - -</LI> -<LI> - Removed device profile. - -</LI> -<LI> - Added verification code support to user-agent flow. - -</LI> -<LI> - Removed multiple formats support, leaving JSON as the only format. - -</LI> -<LI> - Changed assertion <TT>assertion_format</TT> parameter to - <TT>assertion_type</TT>. - -</LI> -<LI> - Removed <TT>type</TT> parameter from token endpoint. - -</LI> -</UL><P> - -</P> -<P> - -06 - - </P> -<UL class="text"> -<LI> - Editorial changes, corrections, clarifications, etc. - -</LI> -<LI> - Removed conformance section. - -</LI> -<LI> - Moved authors section to contributors appendix. - -</LI> -<LI> - Added section on native applications. - -</LI> -<LI> - Changed error response to use the requested format. Added support for HTTP - <TT>Accept</TT> header. - -</LI> -<LI> - Flipped the order of the web server and user-agent flows. - -</LI> -<LI> - Renamed assertion flow <TT>format</TT> parameter name to - <TT>assertion_format</TT> to resolve conflict. - -</LI> -<LI> - Removed the term identifier from token definitions. Added a cryptographic token - definition. - -</LI> -<LI> - Added figure titles. - -</LI> -<LI> - Added server response 401 when client tried to authenticate using multiple credentials. - -</LI> -<LI> - Clarified support for TLS alternatives, and added requirement for TLS 1.2 support for - token endpoint. - -</LI> -<LI> - Removed all signature and cryptography. - -</LI> -<LI> - Removed all discovery. - -</LI> -<LI> - Updated HTML4 reference. - -</LI> -</UL><P> - -</P> -<P> - -05 - - </P> -<UL class="text"> -<LI> - Corrected device example. - -</LI> -<LI> - Added client credentials parameters to the assertion flow as OPTIONAL. - -</LI> -<LI> - Added the ability to send client credentials using an HTTP authentication scheme. - -</LI> -<LI> - Initial text for the <TT>WWW-Authenticate</TT> header (also added - scope support). - -</LI> -<LI> - Change authorization endpoint to end-user endpoint. - -</LI> -<LI> - In the device flow, change the <TT>user_uri</TT> parameter to - <TT>verification_uri</TT> to avoid confusion with the end-user - endpoint. - -</LI> -<LI> - Add <TT>format</TT> request parameter and support for XML and - form-encoded responses. - -</LI> -</UL><P> - -</P> -<P> - -04 - - </P> -<UL class="text"> -<LI> - Changed all token endpoints to use <TT>POST</TT> - -</LI> -<LI> - Clarified the authorization server's ability to issue a new refresh token when - refreshing a token. - -</LI> -<LI> - Changed the flow categories to clarify the autonomous group. - -</LI> -<LI> - Changed client credentials language not to always be server-issued. - -</LI> -<LI> - Added a <TT>scope</TT> response parameter. - -</LI> -<LI> - Fixed typos. - -</LI> -<LI> - Fixed broken document structure. - -</LI> -</UL><P> - -</P> -<P> - -03 - - </P> -<UL class="text"> -<LI> - Fixed typo in JSON error examples. - -</LI> -<LI> - Fixed general typos. - -</LI> -<LI> - Moved all flows sections up one level. - -</LI> -</UL><P> - -</P> -<P> - -02 - - </P> -<UL class="text"> -<LI> - Removed restriction on <TT>redirect_uri</TT> including a query. - -</LI> -<LI> - Added <TT>scope</TT> parameter. - -</LI> -<LI> - Initial proposal for a JSON-based token response format. - -</LI> -</UL><P> - -</P> -<P> - -01 - - </P> -<UL class="text"> -<LI> - Editorial changes based on feedback from Brian Eaton, Bill Keenan, and Chuck Mortimore. - -</LI> -<LI> - Changed device flow <TT>type</TT> parameter values and switch to use - only the token endpoint. - -</LI> -</UL><P> - -</P> -<P> - -00 - - </P> -<UL class="text"> -<LI> - Initial draft based on a combination of WRAP and OAuth 1.0a. - -</LI> -</UL><P> - -</P> -<A name="rfc.references"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<A name="rfc.section.9"></A><H3>9. -References</H3> - -<A name="rfc.references1"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<H3>9.1. Normative References</H3> -<TABLE width="99%" border="0"> -<TBODY><TR><TD class="author-text" valign="top"><A name="I-D.ietf-httpbis-p1-messaging">[I-D.ietf-httpbis-p1-messaging]</A></TD> -<TD class="author-text">Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “<A href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-09.txt">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</A>,” draft-ietf-httpbis-p1-messaging-09 (work in progress), March 2010 (<A href="http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p1-messaging-09.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="NIST FIPS-180-3">[NIST FIPS-180-3]</A></TD> -<TD class="author-text">National Institute of Standards and Technology, “<A href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">Secure Hash Standard (SHS). FIPS PUB 180-3, October 2008</A>.”</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2045">[RFC2045]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=ned@innosoft.com','Compose new message','width=640,height=480')" rel="noreferrer">Freed, N.</A> and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=nsb@nsb.fv.com','Compose new message','width=640,height=480')" rel="noreferrer">N. Borenstein</A>, “<A href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</A>,” RFC 2045, November 1996 (<A href="http://www.rfc-editor.org/rfc/rfc2045.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2104">[RFC2104]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=hugo@watson.ibm.com','Compose new message','width=640,height=480')" rel="noreferrer">Krawczyk, H.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=mihir@cs.ucsd.edu','Compose new message','width=640,height=480')" rel="noreferrer">Bellare, M.</A>, and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=canetti@watson.ibm.com','Compose new message','width=640,height=480')" rel="noreferrer">R. Canetti</A>, “<A href="http://tools.ietf.org/html/rfc2104">HMAC: Keyed-Hashing for Message Authentication</A>,” RFC 2104, February 1997 (<A href="http://www.rfc-editor.org/rfc/rfc2104.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2119">[RFC2119]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=sob@harvard.edu','Compose new message','width=640,height=480')" rel="noreferrer">Bradner, S.</A>, “<A href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</A>,” BCP 14, RFC 2119, March 1997 (<A href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2616">[RFC2616]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=fielding@ics.uci.edu','Compose new message','width=640,height=480')" rel="noreferrer">Fielding, R.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jg@w3.org','Compose new message','width=640,height=480')" rel="noreferrer">Gettys, J.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=mogul@wrl.dec.com','Compose new message','width=640,height=480')" rel="noreferrer">Mogul, J.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=frystyk@w3.org','Compose new message','width=640,height=480')" rel="noreferrer">Frystyk, H.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=masinter@parc.xerox.com','Compose new message','width=640,height=480')" rel="noreferrer">Masinter, L.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=paulle@microsoft.com','Compose new message','width=640,height=480')" rel="noreferrer">Leach, P.</A>, and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=timbl@w3.org','Compose new message','width=640,height=480')" rel="noreferrer">T. Berners-Lee</A>, “<A href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</A>,” RFC 2616, June 1999 (<A href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</A>, <A href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</A>, <A href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2617">[RFC2617]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=john@math.nwu.edu','Compose new message','width=640,height=480')" rel="noreferrer">Franks, J.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=pbaker@verisign.com','Compose new message','width=640,height=480')" rel="noreferrer">Hallam-Baker, P.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jeff@AbiSource.com','Compose new message','width=640,height=480')" rel="noreferrer">Hostetler, J.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=lawrence@agranat.com','Compose new message','width=640,height=480')" rel="noreferrer">Lawrence, S.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=paulle@microsoft.com','Compose new message','width=640,height=480')" rel="noreferrer">Leach, P.</A>, Luotonen, A., and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=stewart@OpenMarket.com','Compose new message','width=640,height=480')" rel="noreferrer">L. Stewart</A>, “<A href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</A>,” RFC 2617, June 1999 (<A href="http://www.rfc-editor.org/rfc/rfc2617.txt">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2617.html">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2617.xml">XML</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC2818">[RFC2818]</A></TD> -<TD class="author-text">Rescorla, E., “<A href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</A>,” RFC 2818, May 2000 (<A href="http://www.rfc-editor.org/rfc/rfc2818.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC3023">[RFC3023]</A></TD> -<TD class="author-text">Murata, M., St. Laurent, S., and D. Kohn, “<A href="http://tools.ietf.org/html/rfc3023">XML Media Types</A>,” RFC 3023, January 2001 (<A href="http://www.rfc-editor.org/rfc/rfc3023.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC3447">[RFC3447]</A></TD> -<TD class="author-text">Jonsson, J. and B. Kaliski, “<A href="http://tools.ietf.org/html/rfc3447">Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</A>,” RFC 3447, February 2003 (<A href="http://www.rfc-editor.org/rfc/rfc3447.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC3629">[RFC3629]</A></TD> -<TD class="author-text">Yergeau, F., “<A href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</A>,” STD 63, RFC 3629, November 2003 (<A href="http://www.rfc-editor.org/rfc/rfc3629.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC3986">[RFC3986]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=timbl@w3.org','Compose new message','width=640,height=480')" rel="noreferrer">Berners-Lee, T.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=fielding@gbiv.com','Compose new message','width=640,height=480')" rel="noreferrer">Fielding, R.</A>, and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=LMM@acm.org','Compose new message','width=640,height=480')" rel="noreferrer">L. Masinter</A>, “<A href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</A>,” STD 66, RFC 3986, January 2005 (<A href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC4627">[RFC4627]</A></TD> -<TD class="author-text">Crockford, D., “<A href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</A>,” RFC 4627, July 2006 (<A href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC5226">[RFC5226]</A></TD> -<TD class="author-text">Narten, T. and H. Alvestrand, “<A href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</A>,” BCP 26, RFC 5226, May 2008 (<A href="http://www.rfc-editor.org/rfc/rfc5226.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC5246">[RFC5246]</A></TD> -<TD class="author-text">Dierks, T. and E. Rescorla, “<A href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</A>,” RFC 5246, August 2008 (<A href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="RFC5849">[RFC5849]</A></TD> -<TD class="author-text">Hammer-Lahav, E., “<A href="http://tools.ietf.org/html/rfc5849">The OAuth 1.0 Protocol</A>,” RFC 5849, April 2010 (<A href="http://www.rfc-editor.org/rfc/rfc5849.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</A></TD> -<TD class="author-text">Raggett, D., Hors, A., and I. Jacobs, “<A href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</A>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<A href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</A>).</TD></TR> -</TBODY></TABLE> - -<A name="rfc.references2"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<H3>9.2. Informative References</H3> -<TABLE width="99%" border="0"> -<TBODY><TR><TD class="author-text" valign="top"><A name="I-D.hammer-oauth">[I-D.hammer-oauth]</A></TD> -<TD class="author-text">Hammer-Lahav, E., “<A href="http://www.ietf.org/internet-drafts/draft-hammer-oauth-10.txt">The OAuth 1.0 Protocol</A>,” draft-hammer-oauth-10 (work in progress), February 2010 (<A href="http://www.ietf.org/internet-drafts/draft-hammer-oauth-10.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="I-D.hardt-oauth">[I-D.hardt-oauth]</A></TD> -<TD class="author-text">Hardt, D., Tom, A., Eaton, B., and Y. Goland, “<A href="http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt">OAuth Web Resource Authorization Profiles</A>,” draft-hardt-oauth-01 (work in progress), January 2010 (<A href="http://www.ietf.org/internet-drafts/draft-hardt-oauth-01.txt">TXT</A>).</TD></TR> -<TR><TD class="author-text" valign="top"><A name="OASIS.saml-core-2.0-os">[OASIS.saml-core-2.0-os]</A></TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=cantor.2@osu.edu','Compose new message','width=640,height=480')" rel="noreferrer">Cantor, S.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=John.Kemp@nokia.com','Compose new message','width=640,height=480')" rel="noreferrer">Kemp, J.</A>, <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=rphilpott@rsasecurity.com','Compose new message','width=640,height=480')" rel="noreferrer">Philpott, R.</A>, and <A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=eve.maler@sun.com','Compose new message','width=640,height=480')" rel="noreferrer">E. Maler</A>, “<A href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">Assertions and Protocol for the OASIS Security Assertion Markup Language - (SAML) V2.0</A>,” OASIS Standard saml-core-2.0-os, March 2005.</TD></TR> -</TBODY></TABLE> - -<A name="rfc.authors"></A><BR><HR> -<TABLE summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><TBODY><TR><TD class="TOCbug"><A href="http://tools.ietf.org/id/draft-ietf-oauth-v2-10.html#toc"> TOC </A></TD></TR></TBODY></TABLE> -<H3>Authors' Addresses</H3> -<TABLE width="99%" border="0" cellpadding="0" cellspacing="0"> -<TBODY><TR><TD class="author-text"> </TD> -<TD class="author-text">Eran Hammer-Lahav (editor)</TD></TR> -<TR><TD class="author-text"> </TD> -<TD class="author-text">Yahoo!</TD></TR> -<TR><TD class="author" align="right">Email: </TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=eran@hueniverse.com','Compose new message','width=640,height=480')" rel="noreferrer">eran@hueniverse.com</A></TD></TR> -<TR><TD class="author" align="right">URI: </TD> -<TD class="author-text"><A href="http://hueniverse.com/">http://hueniverse.com</A></TD></TR> -<TR cellpadding="3"><TD> </TD><TD> </TD></TR> -<TR><TD class="author-text"> </TD> -<TD class="author-text">David Recordon</TD></TR> -<TR><TD class="author-text"> </TD> -<TD class="author-text">Facebook</TD></TR> -<TR><TD class="author" align="right">Email: </TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=davidrecordon@facebook.com','Compose new message','width=640,height=480')" rel="noreferrer">davidrecordon@facebook.com</A></TD></TR> -<TR><TD class="author" align="right">URI: </TD> -<TD class="author-text"><A href="http://www.davidrecordon.com/">http://www.davidrecordon.com/</A></TD></TR> -<TR cellpadding="3"><TD> </TD><TD> </TD></TR> -<TR><TD class="author-text"> </TD> -<TD class="author-text">Dick Hardt</TD></TR> -<TR><TD class="author-text"> </TD> -<TD class="author-text">Microsoft</TD></TR> -<TR><TD class="author" align="right">Email: </TD> -<TD class="author-text"><A href="javascript:void(0)" onclick="window.open('http://mail.google.com/mail/?view=cm&fs=1&tf=1&to=dick.hardt@gmail.com','Compose new message','width=640,height=480')" rel="noreferrer">dick.hardt@gmail.com</A></TD></TR> -<TR><TD class="author" align="right">URI: </TD> -<TD class="author-text"><A href="http://dickhardt.org/">http://dickhardt.org/</A></TD></TR> -</TBODY></TABLE> - -</BODY><STYLE type="text/css">#AdContainer,#RadAd_Skyscraper,#ad-frame,#bbccom_leaderboard,#bbccom_mpu,#center_banner,#footer_adcode,#hbBHeaderSpon,#header_adcode,#hiddenHeaderSpon,#navbar_adcode,#pagelet_adbox,#rightAds,#rightcolumn_adcode,#top-advertising,#topMPU,#tracker_advertorial,.ad-now,.adbox,.adspot,.dfpad,.prWrap,.sponsored,[id^="ad_block"],[id^="adbrite"],[id^="dclkAds"],[id^="konaLayer"],[id^="ew"][id$="_bannerDiv"],a.kLink span[id^="preLoadWrap"][class="preLoadWrap"],A[href^="http://adserver.adpredictive.com"],A[href^="http://ad."][href*=".doubleclick.net/"],div[class^="dms_ad_IDS"],DIV[id="adxLeaderboard"],DIV[id="rm_container"],div[id^="sponsorads"],div[id^="y5_direct"],DIV[id="FFN_Banner_Holder"],DIV[id="FFN_imBox_Container"],DIV[id="p360-format-box"],div[id="tooltipbox"][class^="itxt"],div[id^="adKontekst_"],div[id^="google_ads_div"],div[id^="kona_"][id$="_wrapper"],div[class="wnDVUtilityBlock"],embed[flashvars*="AdID"],embed[id="Advertisement"][name="Advertisement"],iframe[class="chitikaAdBlock"],iframe[id^="dapIfM"],iframe[name^="AdBrite"],iframe[name^="google_ads_"],iframe[src*="clicksor.com"],img[src*="clicksor.com"],IMG[src^="http://cdn.adnxs.com"],ispan#ab_pointer,object[id="flashad"],object[id="ve_threesixty_swf"][name="ve_threesixty_swf"],[src*="sixsigmatraffic.com"],div#dir_ads_site,div#tads table[align="center"][width="100%"],div#rhs div#rhs_block table#mbEnd,#A9AdsMiddleBoxTop,#A9AdsOutOfStockWidgetTop,#A9AdsServicesWidgetTop,#AD_CONTROL_22,#ADsmallWrapper,#Ad1,#Ad2,#Ad3Left,#Ad3Right,#AdBanner_F1,#AdBar1,#AdContainerTop,#AdHeader,#AdMiddle,#AdRectangle,#AdSenseDiv,#AdShowcase_F1,#AdSky23,#AdSkyscraper,#AdSponsor_SF,#AdTargetControl1_iframe,#AdText,#Ad_Block,#Ad_Center1,#Ad_Top,#Adbanner,#Adrectangle,#AdsContent,#AdsWrap,#AdvertMPU23b,#AdvertiseFrame,#Advertisement,#Advertorial,#BannerAdvert,#BigBoxAd,#CompanyDetailsNarrowGoogleAdsPresentationControl,#CompanyDetailsWideGoogleAdsPresentationControl,#ContentAd,#ContentAd1,#ContentAd2,#ContentAdPlaceHolder1,#ContentAdPlaceHolder2,#ContentAdXXL,#ContentPolepositionAds_Result,#FooterAd,#FooterAdContainer,#GoogleAdsense,#HEADERAD,#HOME_TOP_RIGHT_BOXAD,#HeaderAdsBlock,#HeaderAdsBlockFront,#HeaderBannerAdSpacer,#HeaderTextAd,#HeroAd,#HomeAd1,#HouseAd,#ID_Ad_Sky,#Journal_Ad_125,#Journal_Ad_300,#LeftAd,#LeftAdF1,#LeftAdF2,#LowerContentAd,#PREFOOTER_LEFT_BOXAD,#PREFOOTER_RIGHT_BOXAD,#PageLeaderAd,#RightAd,#RightSponsoredAd,#SectionAd300-250,#SidebarAdContainer,#SkyAd,#SpecialAds,#SponsoredAd,#TOP_ADROW,#TOP_RIGHT_BOXAD,#TopAdPos,#VM-MPU-adspace,#VM-footer-adspace,#VM-header-adspace,#VM-header-adwrap,#XEadLeaderboard,#XEadSkyscraper,#_ads,#ad-120x600-sidebar,#ad-160x600,#ad-160x600-sidebar,#ad-250x300,#ad-300,#ad-300x250,#ad-300x250-sidebar,#ad-300x250Div,#ad-728,#ad-article,#ad-banner,#ad-bottom,#ad-bottom-wrapper,#ad-colB-1,#ad-column,#ad-container,#ad-footer,#ad-footprint-160x600,#ad-front-footer,#ad-front-sponsoredlinks,#ad-halfpage,#ad-label,#ad-leaderboard,#ad-leaderboard-bottom,#ad-leaderboard-spot,#ad-leaderboard-top,#ad-left,#ad-list-row,#ad-lrec,#ad-medium-rectangle,#ad-middlethree,#ad-middletwo,#ad-module,#ad-mpu,#ad-mpu1-spot,#ad-mpu2-spot,#ad-placard,#ad-rectangle,#ad-righttop,#ad-side-text,#ad-skyscraper,#ad-slug-wrapper,#ad-space,#ad-splash,#ad-spot,#ad-target,#ad-target-Leaderbord,#ad-teaser,#ad-top,#ad-top-text-low,#ad-tower,#ad-trailerboard-spot,#ad-typ1,#ad-west,#ad-wrap,#ad-wrap-right,#ad-wrapper,#ad-wrapper1,#ad-yahoo-simple,#ad1,#ad125BL,#ad125BR,#ad125TL,#ad125TR,#ad125x125,#ad160x600,#ad160x600right,#ad1Sp,#ad2,#ad2Sp,#ad3,#ad300,#ad300-250,#ad300X250,#ad300_x_250,#ad300x150,#ad300x250,#ad300x250Module,#ad300x60,#ad300x600,#ad300x600_callout,#ad336,#ad336x280,#ad375x85,#ad468,#ad468x60,#ad526x250,#ad600,#ad7,#ad728,#ad728Wrapper,#ad728x90,#adB,#adBadges,#adBanner,#adBanner120x600,#adBannerTable,#adBannerTop,#adBar,#adBlock125,#adBlocks,#adBox,#adContainer,#adDiv,#adFps,#adFtofrs,#adGallery,#adGroup1,#adHeader,#adL,#adLB,#adLeaderboard,#adMPU,#adMiddle0Frontpage,#adMiniPremiere,#adP,#adPlaceHolderRight,#adRight,#adSenseModule,#adServer_marginal,#adSidebar,#adSidebarSq,#adSky,#adSkyscraper,#adSlider,#adSpace3,#adSpace300_ifrMain,#adSpace4,#adSpace5,#adSpace6,#adSpace7,#adSpace_footer,#adSpace_top,#adSpecial,#adSpot-Leader,#adSpot-banner,#adSpot-mrec1,#adSpot-sponsoredlinks,#adSpot-textbox1,#adSpot-widestrip,#adSpotAdvertorial,#adSpotIsland,#adSpotSponsoredLinks,#adSquare,#adStaticA,#adStrip,#adSuperPremiere,#adTableCell,#adTag1,#adTag2,#adText,#adText_container,#adTop,#adTopboxright,#adUnit,#adWrapper,#adZoneTop,#ad_160x160,#ad_160x600,#ad_190x90,#ad_300,#ad_300_250,#ad_300x250,#ad_468_60,#ad_5,#ad_728_foot,#ad_728x90,#ad_A,#ad_B,#ad_Banner,#ad_C,#ad_C2,#ad_D,#ad_E,#ad_F,#ad_G,#ad_H,#ad_I,#ad_J,#ad_K,#ad_L,#ad_M,#ad_N,#ad_O,#ad_P,#ad_YieldManager-300x250,#ad_anchor,#ad_banner,#ad_banner_top,#ad_bar,#ad_block_1,#ad_block_2,#ad_bottom,#ad_box_colspan,#ad_branding,#ad_bs_area,#ad_center_monster,#ad_container,#ad_content_wrap,#ad_feature,#ad_footer,#ad_haha_1,#ad_haha_4,#ad_halfpage,#ad_head,#ad_header,#ad_horseshoe_left,#ad_horseshoe_right,#ad_horseshoe_spacer,#ad_horseshoe_top,#ad_hotpots,#ad_island,#ad_label,#ad_layer2,#ad_leader,#ad_leaderBoard,#ad_leaderboard,#ad_lwr_square,#ad_medium_rectangle,#ad_medium_rectangular,#ad_middle,#ad_mpu,#ad_mrcontent,#ad_overlay,#ad_play_300,#ad_rect,#ad_rect_body,#ad_rect_bottom,#ad_rectangle,#ad_related_links_div,#ad_related_links_div_program,#ad_replace_div_1,#ad_report_leaderboard,#ad_report_rectangle,#ad_right,#ad_right_main,#ad_ros_tower,#ad_rr_1,#ad_sidebar1,#ad_sidebar2,#ad_sidebar3,#ad_skyscraper,#ad_slot_livesky,#ad_space,#ad_square,#ad_ss,#ad_term_bottom_place,#ad_top,#ad_top_holder,#ad_tp_banner_1,#ad_tp_banner_2,#ad_vertical,#ad_window,#ad_wrapper,#adbanner,#adbnr,#adboard,#adbottom,#adbox,#adbox2,#adclear,#adcode1,#adcode2,#adcode3,#adcode4,#adcolumnwrapper,#adcontainer,#adcontainsm,#adcontrolPushSite,#addiv-bottom,#addiv-top,#adfooter_728x90,#adframe:not(frameset),#adhead,#adhead_g,#adheader,#adhome,#adiframe1_iframe,#adiframe2_iframe,#adiframe3_iframe,#adimg,#adition_content_ad,#adlabel,#adlabelFooter,#adleaderboard,#adlinks,#adlinkws,#admid,#admiddle3center,#admiddle3left,#adposition,#adposition-C,#adposition-FPMM,#adposition2,#adposition3,#adposition4,#adrectanglea,#adrectangleb,#adright,#adright2,#ads,#ads-468,#ads-area,#ads-block,#ads-bot,#ads-bottom,#ads-dell,#ads-horizontal,#ads-indextext,#ads-leaderboard1,#ads-lrec,#ads-prices,#ads-rhs,#ads-top,#ads160left,#ads2,#ads300,#ads336x280,#ads7,#ads728bottom,#ads728top,#ads790,#adsDisplay,#adsID,#ads_160,#ads_300,#ads_728,#ads_belowforumlist,#ads_belownav,#ads_bottom_outer,#ads_catDiv,#ads_footer,#ads_right,#ads_sidebar_roadblock,#ads_top,#adsbottom,#adscolumn,#adsense,#adsense-text,#adsenseWrap,#adsense_inline,#adsense_leaderboard,#adsense_placeholder_2,#adsensetopplay,#adskyscraper,#adslot,#adsonar,#adspace,#adspace-300x250,#adspace300x250,#adspaceBox,#adspaceBox300,#adspace_header,#adspot-a,#adsright,#adstop,#adt,#adtech_googleslot_03c,#adtech_takeover,#adtop,#adv-masthead,#adv_google_300,#adv_google_728,#adv_top_banner_wrapper,#adv_wide_banner,#adver1,#adver2,#adver3,#adver4,#advert,#advert-1,#advert-boomer,#advert-display,#advert-header,#advert-leaderboard,#advert-top,#advert1,#advertBanner,#advert_250x250,#advert_box,#advert_leaderboard,#advert_lrec_format,#advert_mpu,#advertbox,#advertbox2,#advertbox3,#advertbox4,#adverthome,#advertise,#advertise-now,#advertise1,#advertisement,#advertisement160x600,#advertisement728x90,#advertisementLigatus,#advertisementPrio2,#advertiser-container,#advertiserLinks,#advertising,#advertising-skyscraper,#advertisingModule160x600,#advertisingModule728x90,#advertorial,#adwhitepaperwidget,#adwin_rec,#adwith,#adwords-4-container,#adwrapper,#adxtop,#adzerk,#adzoneBANNER,#agi-ad300x250,#agi-ad300x250overlay,#agi-sponsored,#anchorAd,#annoying_ad,#ap_adframe,#araHealthSponsorAd,#article-ad-container,#article-box-ad,#articleAdReplacement,#articleSideAd,#article_ad,#article_box_ad,#asinglead,#atlasAdDivGame,#banner-ad,#banner-ad-container,#banner-ads,#banner468x60,#banner728x90,#bannerAd,#bannerAdTop,#bannerAd_ctr,#banner_ad,#banner_ads,#banner_topad,#bannerad,#bannerad2,#bbccom_mpu,#bbo_ad1,#bg_YieldManager-300x250,#bigAd,#bigBoxAd,#bigadbox,#bigadspot,#billboard_ad,#block-ad_cube-1,#block-thewrap_ads_250x300-0,#block_advert,#blox-big-ad,#blox-halfpage-ad,#blox-tile-ad,#botad,#bott_ad2,#bott_ad2_300,#bottom-ad-container,#bottom-ads,#bottomAd,#bottomAdCCBucket,#bottomAdContainer,#bottomAdSense,#bottomAdSenseDiv,#bottomAds,#bottomRightAd,#bottomRightAdSpace,#bottom_ad,#bottom_ad_area,#bottom_ads,#bottom_banner_ad,#bottom_overture,#bottom_sponsor_ads,#bottom_sponsored_links,#bottom_text_ad,#bottomad,#bottomadsense,#box-googleadsense-1,#box-googleadsense-r,#box1ad,#boxAd300,#boxAdContainer,#box_ad,#box_mod_googleadsense,#boxad1,#boxad2,#boxad3,#boxad4,#boxad5,#bps-header-ad-container,#btr_horiz_ad,#burn_header_ad,#button-ads-horizontal,#button-ads-vertical,#button_ad_container,#button_ad_wrap,#cellAd,#channel_ad,#channel_ads,#ciHomeRHSAdslot,#circ_ad,#cnnRR336ad,#cnnTopAd,#colRightAd,#column4-google-ads,#commercial_ads,#common_right_lower_player_adspace,#common_right_player_adspace,#common_top_adspace,#containerLocalAds,#containerMrecAd,#content-ad-header,#contentAd,#content_ad,#content_ad_square,#content_ad_top,#content_ads_content,#content_box_300body_sponsoredoffers,#content_box_adright300_google,#contentad,#contentad_imtext,#contentad_right,#contentads,#contentinlineAd,#contextual-ads-block,#contextualad,#coverads,#ctl00_BottomAd,#ctl00_LHTowerAd,#ctl00_LeftHandAd,#ctl00_MasterHolder_IBanner_adHolder,#ctl00_TopAd,#ctl00_TowerAd,#ctl00_VBanner_adHolder,#ctl00_adFooter,#ctl00_atop_bt,#ctl00_cphMain_hlAd1,#ctl00_cphMain_hlAd2,#ctl00_cphMain_hlAd3,#ctl00_ctl00_MainPlaceHolder_itvAdSkyscraper,#ctl00_ctl00_ctl00_Main_Main_PlaceHolderGoogleTopBanner_MPTopBannerAd,#ctl00_ctl00_ctl00_Main_Main_SideBar_MPSideAd,#ctl00_ctl00_ctl00_tableAdsTop,#ctl00_m_skinTracker_m_adLBL,#ctl00_phCrackerMain_ucAffiliateAdvertDisplayMiddle_pnlAffiliateAdvert,#ctl00_phCrackerMain_ucAffiliateAdvertDisplayRight_pnlAffiliateAdvert,#ctrlsponsored,#cubeAd,#cube_ads,#cube_ads_inner,#cubead,#cubead-2,#dc-display-right-ad-1,#dcol-sponsored,#defer-adright,#detail_page_vid_topads,#divAd,#divAdBox,#divWrapper_Ad,#div_video_ads,#dlads,#dni-header-ad,#download_ads,#ds-mpu,#editorsmpu,#evotopTen_advert,#exads,#featuread,#featuredAdContainer2,#featuredAds,#feed_links_ad_container,#first_ad_unit,#firstad,#fl_hdrAd,#footer-ad,#footer-sponsored,#footerAd,#footerAdDiv,#footerAds,#footerAdverts,#footer_ad,#footer_ad_block,#footer_ads,#footer_adspace,#footer_text_ad,#footerad,#fr_ad_center,#frnContentAd,#from_our_sponsors,#front_advert,#front_mpu,#ft-ad,#ft-ad-1,#ft-ad-container,#ft_mpu,#fusionad,#fw-advertisement,#g_ad,#g_adsense,#ga_300x250,#gad,#gallery-ad-m0,#gallery_ads,#game-info-ad,#global_header_ad_area,#gmi-ResourcePageAd,#gmi-ResourcePageLowerAd,#google-ad,#google-ad-art,#google-ad-tower,#google-ads,#google-ads-bottom,#google-ads-left-side,#google-adsense-mpusize,#googleAd,#googleAds,#googleAdsense,#googleAdsenseBanner,#googleAdsenseBannerBlog,#googleAdwordsModule,#googleAfcContainer,#googleShoppingAdsRight,#googleShoppingAdsTop,#google_ad,#google_ad_test,#google_ads,#google_ads_frame1,#google_ads_test,#googlead,#googleads,#googlesponsor,#grid_ad,#gsyadrectangleload,#gsyadrightload,#gsyadtop,#gsyadtopload,#gtopadvts,#halfPageAd,#halfe-page-ad-box,#hdtv_ad_ss,#head-ad,#head_advert,#header-ad,#header-ads,#header-advert,#headerAd,#headerAdBackground,#headerAdContainer,#headerAdWrap,#headerAdsWrapper,#headerTopAd,#header_ad,#header_adcode,#header_ads,#header_advertisement_top,#header_leaderboard_ad_container,#headerad,#headeradbox,#headline_ad,#hiddenadAC,#homeTopRightAd,#home_ad,#home_contentad,#home_spensoredlinks,#homepage-ad,#homepage_right_ad,#homepage_right_ad_container,#hometop_234x60ad,#hor_ad,#horizontal-banner-ad,#horizontal_ad,#horizontal_ad_top,#horizontalads,#houseAd,#hp-store-ad,#hpV2_300x250Ad,#hpV2_googAds,#icePage_SearchLinks_AdRightDiv,#icePage_SearchLinks_DownloadToolbarAdRightDiv,#indexad,#inlinead,#inlinegoogleads,#inner-advert-row,#insider_ad_wrapper,#instoryad,#int-ad,#interstitial_ad_wrapper,#islandAd,#j_ad,#jmp-ad-buttons,#joead,#joead2,#ka_adRightSkyscraperWide,#landing-adserver,#largead,#lateAd,#lb-sponsor-left,#lb-sponsor-right,#leader-board-ad,#leader-sponsor,#leaderAdContainer,#leaderad,#leaderad_section,#leaderboard-ad,#leaderboard-bottom-ad,#leaderboard_ad,#left-ad-skin,#leftAdContainer,#leftAd_rdr,#leftAdvert,#leftSectionAd300-100,#left_ad,#left_adspace,#leftad,#leftads,#lg-banner-ad,#linkAds,#live-ad,#longAdSpace,#lowerthirdad,#mBannerAd,#main-ad,#main-ad160x600,#main-ad160x600-img,#main-ad728x90,#mainAd,#mainAdUnit,#mainAdvert,#main_ad,#main_rec_ad,#mastAdvert,#mastad,#masthead_ad,#masthead_topad,#medRecAd,#media_ad,#menuAds,#mi_story_assets_ad,#mid-ad300x250,#mid-table-ad,#mid_ad_title,#mid_mpu,#middlead,#middleads,#midrect_ad,#midstrip_ad,#mini-ad,#module-google_ads,#module_ad,#module_box_ad,#moogleAd,#most_popular_ad,#mpu,#mpu-advert,#mpuAd,#mpuDiv,#mpuWrapper,#mpuWrapperAd,#mpu_banner,#mpu_holder,#mpu_text_ad,#mpuad,#mrecAdContainer,#ms_ad,#msad,#multiLinkAdContainer,#n_sponsor_ads,#namecom_ad_hosting_main,#narrow_ad_unit,#natadad300x250,#national_microlink_ads,#navi_banner_ad_780,#nba300Ad,#nbaMidAds,#nbaVid300Ad,#new_topad,#ng_rtcol_ad,#noresultsads,#northad,#oanda_ads,#onespot-ads,#p-googleadsense,#page-header-ad,#pageAds,#pageAdsDiv,#page_content_top_ad,#pcworldAdBottom,#pcworldAdTop,#pinball_ad,#player_ad,#player_ads,#portlet-advertisement-left,#portlet-advertisement-right,#post5_adbox,#post_ad,#priceGrabberAd,#print_ads,#printads,#product-adsense,#promo-ad,#promoAds,#ps-vertical-ads,#pub468x60,#publicidad,#pushdown_ad,#r1SoftAd,#rail_ad1,#rail_ad2,#realEstateAds,#rect_ad,#rectangle-ad,#rectangle_ad,#refine-300-ad,#region-top-ad,#rh-ad-container,#rh_tower_ad,#rhsadvert,#right-ad,#right-ad-skin,#right-box-ad,#rightAd,#rightAd300x250,#rightAdColumn,#rightAd_rdr,#rightColAd,#rightColumnMpuAd,#rightColumnSkyAd,#right_ad_wrapper,#right_ads,#right_advertisement,#right_advertising,#right_column_ads,#rightad,#rightadvertbar-doubleclickads,#rightbar-ad,#rightside_ad,#rm_ad_text,#ros_ad,#rotatingads,#row2AdContainer,#rtMod_ad,#sAdsBox,#sb-ad-sq,#sb_advert,#search-google-ads,#search_ads,#secondBoxAdContainer,#section-container-ddc_ads,#section_advertorial_feature,#servfail-ads,#sew-ad1,#shoppingads,#show-ad,#side-ad,#side-ad-container,#sideAd,#sideBarAd,#side_ad_wrapper,#side_ads_by_google,#sidead,#sidebar-125x125-ads,#sidebar-125x125-ads-below-index,#sidebar-ad,#sidebar-ad-boxes,#sidebar-ad-space,#sidebar-ad-wrap,#sidebar-ads,#sidebar2ads,#sidebar_ad_widget,#sidebar_ads,#sidebar_sponsoredresult_body,#sidebarad,#sideline-ad,#single-mpu,#singlead,#site-leaderboard-ads,#site_top_ad,#sky-ad,#skyAd,#skyScrapperAd,#sky_ad,#sky_advert,#skyscraper-ad,#skyscraperAd,#skyscraper_ad,#skyscraper_advert,#sliderAdHolder,#slideshow_ad_300x250,#sm-banner-ad,#small_ad,#smallerAd,#speeds_ads,#speeds_ads_fstitem,#sphereAd,#splinks,#sponLinkDiv_1,#sponlink,#sponsAds,#sponsLinks,#spons_left,#sponseredlinks,#sponsor-search,#sponsorAd1,#sponsorAd2,#sponsorAdDiv,#sponsorLinks,#sponsorTextLink,#sponsor_banderole,#sponsor_box,#sponsor_deals,#sponsor_panSponsor,#sponsored,#sponsored-ads,#sponsored-features,#sponsored-links,#sponsored-resources,#sponsored1,#sponsoredBox1,#sponsoredBox2,#sponsoredLinks,#sponsoredList,#sponsoredResults,#sponsoredSiteMainline,#sponsoredSiteSidebar,#sponsored_ads_v4,#sponsored_content,#sponsored_game_row_listing,#sponsored_links,#sponsoredlinks,#sponsoredlinks_cntr,#sponsoredresults_top,#sponsorlink,#spotlightAds,#spotlightad,#squareAd,#squareAdSpace,#square_ad,#start_middle_container_advertisment,#sticky-ad,#stickyBottomAd,#story-ad-a,#story-ad-b,#story-sponsoredlinks,#storyAd,#storyAdWrap,#subpage-ad-right,#subpage-ad-top,#swads,#synch-ad,#tabAdvertising,#tblAd,#tbl_googlead,#template_ad_leaderboard,#tertiary_advertising,#text-ad,#textAd,#textAds,#text_ad,#text_advert,#the-last-ad-standing,#thefooterad,#themis-ads,#tile-ad,#tmglBannerAd,#top-ad,#top-ad-container,#top-ad-menu,#top-ads,#top-ads-tabs,#top-advertisement,#top-banner-ad,#top-search-ad-wrapper,#topAd,#topAd728x90,#topAdBanner,#topAdContainer,#topAdSenseDiv,#topAds,#topAdsContainer,#topAdvert,#topBannerAd,#topNavLeaderboardAdHolder,#top_ad,#top_ad_area,#top_ad_game,#top_ad_wrapper,#top_ads,#top_advertise,#top_advertising,#top_right_ad,#top_wide_ad,#topad,#topad_left,#topad_right,#topadblock,#topads,#topadzone,#topcustomad,#toprightAdvert,#toptextad,#towerad,#ttp_ad_slot1,#ttp_ad_slot2,#twogamesAd,#txt_link_ads,#undergameAd,#upperMpu,#upperad,#urban_contentad_article,#v_ad,#vert_ad,#vertical_ad,#vertical_ads,#video_cnv_ad,#video_overlay_ad,#walltopad,#welcomeAdsContainer,#welcome_ad_mrec,#welcome_advertisement,#wgtAd,#whatsnews_top_ad,#whitepaper-ad,#whoisRightAdContainer,#wide_ad_unit_top,#widget_advertisement,#wrapAdRight,#wrapAdTop,#y708-ad-expedia,#y708-ad-lrec,#y708-ad-partners,#y708-ad-ysm,#y708-advertorial-marketplace,#yahoo-ads,#yahoo-sponsors,#yahoo_ads,#yahoo_ads_2010,#yahooad-tbl,#yan-sponsored,#ybf-ads,#yfi_fp_ad_mort,#yfi_fp_ad_nns,#yfi_pf_ad_mort,#ygrp-sponsored-links,#ymap_adbanner,#yn-gmy-ad-lrec,#yreSponsoredLinks,#ysm_ad_iframe,#zoneAdserverMrec,#zoneAdserverSuper,.ADBAR,.ADPod,.AD_MOVIE_ITEM,.AD_MOVIE_ITEMLIST,.AD_MOVIE_ITEMROW,.Ad120x600,.Ad160x600,.Ad247x90,.Ad300x250,.Ad300x250L,.Ad728x90,.AdBox,.AdBox7,.AdContainerBox308,.AdHere,.AdInfo,.AdPlaceHolder,.AdRingtone,.AdSense,.AdSpace,.AdTitle,.AdUnit,.AdUnit300,.Ad_C,.Ad_D_Wrapper,.Ad_E_Wrapper,.Ad_Right,.Ads,.AdsBoxSection,.AdsLinks1,.AdsLinks2,.AdvertMidPage,.AdvertiseWithUs,.AdvertisementTextTag,.ArticleInlineAd,.BannerAd,.BlockAd,.BottomAffiliate,.CG_adkit_leaderboard,.CommentAd,.DeptAd,.FT_Ad,.FlatAds,.HPNewAdsBannerDiv,.HomeContentAd,.LeftTowerAd,.M2Advertisement,.MD_adZone,.MPU,.MPUHolder,.MiddleAdContainer,.OpenXad,.PU_DoubleClickAdsContent,.Post5ad,.RBboxAd,.RelatedAds,.RightRailTop300x250Ad,.RightSponsoredAdTitle,.RightTowerAd,.SidebarAd,.SponsoredAdTitle,.SponsoredContent,.SponsoredLinks,.SponsoredLinksGrayBox,.SquareAd,.StandardAdLeft,.StandardAdRight,.TextAd,.TheEagleGoogleAdSense300x250,.TopAd,.TopAdL,.TopAdR,.UIStandardFrame_SidebarAds,.UIWashFrame_SidebarAds,.UnderAd,.VerticalAd,.WidgetAdvertiser,.ad-160x600,.ad-250,.ad-300,.ad-300-block,.ad-300-blog,.ad-300x100,.ad-300x250,.ad-600,.ad-728,.ad-adlink-bottom,.ad-adlink-side,.ad-background,.ad-banner,.ad-bigsize,.ad-block,.ad-blog2biz,.ad-bottom,.ad-box,.ad-break,.ad-btn,.ad-btn-heading,.ad-button,.ad-cell,.ad-container,.ad-div,.ad-feedback,.ad-filler,.ad-footer,.ad-footer-leaderboard,.ad-google,.ad-gray,.ad-hdr,.ad-head,.ad-holder,.ad-homeleaderboard,.ad-img,.ad-island,.ad-leaderboard,.ad-links,.ad-medium,.ad-medium-two,.ad-mpu,.ad-other,.ad-permalink,.ad-placeholder,.ad-postText,.ad-poster,.ad-rect,.ad-rectangle,.ad-rectangle-text,.ad-related,.ad-rh,.ad-ri,.ad-right,.ad-right-header,.ad-right-txt,.ad-section,.ad-sidebar300,.ad-slot,.ad-slot-234-60,.ad-slot-300-250,.ad-slot-728-90,.ad-space,.ad-space-mpu-box,.ad-spot,.ad-statement,.ad-text,.ad-tile,.ad-top,.ad-top-left,.ad-unit,.ad-unit-300,.ad-unit-300-wrapper,.ad-unit-anchor,.ad-vtu,.ad-wrap,.ad-wrapper,.ad-zone-s-q-l,.ad0,.ad1,.ad10,.ad120,.ad160,.ad160x600,.ad18,.ad19,.ad2,.ad21,.ad250c,.ad3,.ad300,.ad300_250,.ad300x100,.ad300x250,.ad300x250Top,.ad300x250_container,.ad300x250box,.ad300x600,.ad310,.ad336x280,.ad343x290,.ad450,.ad468,.ad468_60,.ad468x60,.ad6,.ad620x70,.ad626X35,.ad7,.ad728,.ad728_90,.ad728x90,.ad728x90_container,.ad8,.adAgate,.adBanner,.adBannerTyp1,.adBannerTypSortableList,.adBannerTypW300,.adBgBottom,.adBgMId,.adBgTop,.adBox,.adBoxContent,.adBoxSidebar,.adBoxSingle,.adCMRight,.adColumn,.adContainer,.adContour,.adCreative,.adDiv,.adElement,.adFrame,.adFtr,.adFullWidthMiddle,.adGoogle,.adHeader,.adHeadline,.adHolder,.adHome300x250,.adInNews,.adLabel,.adLeader,.adLeaderForum,.adLeaderboard,.adLeft,.adMastheadLeft,.adMastheadRight,.adMkt2Colw,.adModule,.adNewsChannel,.adNoOutline,.adNoticeOut,.adObj,.adPageBorderL,.adPageBorderR,.adPanel,.adRect,.adRight,.adSelfServiceAdvertiseLink,.adServer,.adSlot,.adSpBelow,.adSpace,.adSpacer,.adSpot,.adSpot-searchAd,.adSpot-textBox,.adSpot-twin,.adSpotIsland,.adSquare,.adSummary,.adSuperboard,.adTag,.adText,.adTileWrap,.adTiler,.adTitle,.adTout,.adTxt,.adWithTab,.adWrap,.adWrapper,.ad_1,.ad_125,.ad_130x90,.ad_160,.ad_160x600,.ad_2,.ad_3,.ad_300,.ad_300_250,.ad_300x250,.ad_336,.ad_336x280,.ad_350x250,.ad_468,.ad_600,.ad_728,.ad_728x90,.ad_amazon,.ad_biz,.ad_block_338,.ad_bottom_leaderboard,.ad_box,.ad_box2,.ad_callout,.ad_caption,.ad_contain,.ad_container,.ad_content,.ad_content_wide,.ad_contents,.ad_descriptor,.ad_footer,.ad_framed,.ad_front_promo,.ad_header,.ad_hpm,.ad_info_block,.ad_label,.ad_launchpad,.ad_leader,.ad_leaderboard,.ad_left,.ad_linkunit,.ad_loc,.ad_lrec,.ad_medrect,.ad_mpu,.ad_mr,.ad_mrec,.ad_mrec_title_article,.ad_notice,.ad_p360,.ad_partner,.ad_partners,.ad_plus,.ad_post,.ad_power,.ad_rectangle,.ad_right,.ad_sidebar,.ad_skyscraper,.ad_slug_table,.ad_space,.ad_space_300_250,.ad_sponsor,.ad_sponsoredsection,.ad_spot_b,.ad_spot_c,.ad_square_r,.ad_square_top,.ad_text,.ad_title,.ad_top,.ad_top_leaderboard,.ad_tower,.ad_unit,.ad_unit_rail,.ad_warning,.ad_wide,.ad_wrap,.ad_wrapper,.ad_wrapper_fixed,.ad_wrapper_top,.ad_zone,.adarea,.adbanner,.adbannerright,.adbar,.adborder,.adbot,.adbottom,.adbottomright,.adbox,.adbox-outer,.adbox_366x280,.adbox_468X60,.adbox_bottom,.adboxclass,.adcode,.adcolumn_wrapper,.adcontainer,.adcopy,.addiv,.adfoot,.adfootbox,.adframe,.adhead,.adheader,.adheader100,.adhere,.adhoriz,.adi,.adinfo,.adinside,.adjlink,.adkit,.adkit-advert,.adkit-lb-footer,.adlabel-horz,.adlabel-vert,.adleft,.adline,.adlink,.adlinks,.adlist,.adlnklst,.admarker,.admedrec,.admessage,.admodule,.admpu,.adnotice,.adops,.adpadding,.adpic,.adright,.adrotate_widget,.adrow,.adrow-post,.adrule,.ads-banner,.ads-categories-bsa,.ads-favicon,.ads-links-general,.ads-mpu,.ads-profile,.ads-right,.ads-sidebar,.ads-sky,.ads-text,.ads2,.ads3,.ads:not(body),.adsArea,.adsBelowHeadingNormal,.adsBox,.adsImages,.adsTextHouse,.adsTower2,.adsTowerWrap,.adsWithUs,.ads_300,.ads_728x90,.ads_big,.ads_big-half,.ads_brace,.ads_catDiv,.ads_container,.ads_disc_anchor,.ads_disc_leader,.ads_disc_lwr_square,.ads_disc_skyscraper,.ads_disc_square,.ads_div,.ads_header,.ads_leaderboard,.ads_mpu,.ads_outer,.ads_right,.ads_sc_bl_i,.ads_sc_tl_i,.ads_side,.ads_takeover,.ads_tr,.adsborder,.adsbyyahoo,.adsc,.adscontainer,.adscreen,.adsection_a2,.adsection_c2,.adsense,.adsense-heading,.adsense-right,.adsense-title,.adsenseBlock,.adsenseContainer,.adsenseblock,.adsenselr,.adsensesq,.adsidebox,.adsingle,.adslogan,.adspace,.adspace-MR,.adspace_buysell,.adspace_rotate,.adspacer,.adspot,.adstrip,.adtag,.adtext,.adtext_gray,.adtext_onwhite,.adtop,.adtravel,.adv-mpu,.adverTag,.adver_cont_below,.advert,.advert-box,.advert-head,.advert-horizontal,.advert-mpu,.advert-skyscraper,.advert-text,.advertCont,.advertContainer,.advertHeadline,.advertRight,.advertText,.advert_468x60,.advert_box,.advert_cont,.advert_leaderboard,.advert_note,.advertise,.advertise-here,.advertise-homestrip,.advertise-horz,.advertise-leaderboard,.advertise-vert,.advertiseContainer,.advertiseText,.advertisement,.advertisement-728x90,.advertisement-block,.advertisement-top,.advertisement468,.advertisementColumnGroup,.advertisementContainer,.advertisementLabel,.advertisementPanel,.advertisement_caption,.advertisement_g,.advertisement_header,.advertisement_horizontal,.advertiser,.advertising,.advertising-header,.advertising2,.advertisingTable,.advertising_block,.advertisment,.advertisment_two,.advertize,.advertorial,.advertorial-promo-box,.adverts,.advt,.advt-banner-3,.advt300,.advt720,.adwordListings,.adwrapper,.adwrapper-lrec,.adwrapper948,.affiliate,.affiliate-link,.affiliate-sidebar,.affiliateAdvertText,.agi-adsaleslinks,.alt_ad,.anchorAd,.answer_ad_content,.aolSponsoredLinks,.aopsadvert,.article-ads,.articleAd,.articleAds,.articleAdsL,.articleEmbeddedAdBox,.article_ad,.article_adbox,.article_mpu_box,.articleads,.aseadn,.aux-ad-widget-2,.b-astro-sponsored-links_horizontal,.b-astro-sponsored-links_vertical,.banner-ad,.banner-ads,.banner-adverts,.banner300x100,.banner300x250,.banner468,.bannerAd,.bannerAdWrapper300x250,.bannerAdWrapper730x86,.banner_300x250,.banner_728x90,.banner_ad,.banner_ad_footer,.banner_ad_leaderboard,.bannerad,.barkerAd,.base-ad-mpu,.base_ad,.bgnavad,.big-ads,.bigAd,.big_ad,.big_ads,.bigad,.bigad2,.billboard_ad,.block-ad,.block-adsense,.block_ad,.block_ad_sb_text,.block_ad_sponsored_links,.block_ad_sponsored_links-wrapper,.blocked-ads,.blog-ads-container,.blogAd,.blogAdvertisement,.blogBigAd,.blog_ad,.blogads,.body_ad,.body_sponsoredresults_bottom,.body_sponsoredresults_middle,.body_sponsoredresults_top,.bookseller-header-advt,.bottomAd,.bottomAds,.bottom_ad_block,.bottom_sponsor,.bottomad,.bottomrightrailAd,.bottomvidad,.box-ad,.box-ads,.boxAd,.box_ad,.box_advertisment_62_border,.box_content_ad,.box_content_ads,.boxad,.bps-ad-wrapper,.bps-advertisement,.bps-advertisement-inline-ads,.bullet-sponsored-links,.bullet-sponsored-links-gray,.burstContentAdIndex,.buttonAd,.buttonAds,.buttonadbox,.bx_ad,.bx_ad_right,.cA-adStrap,.cColumn-TextAdsBox,.care2_adspace,.cb-ad-container,.cb_footer_sponsor,.cb_navigation_ad,.cbstv_ad_label,.cbzadvert,.cdAdTitle,.cdmainlineSearchAdParent,.cdsidebarSearchAdParent,.centerAd,.center_ad,.centerad,.clearerad,.cm_ads,.cms-Advert,.cnn160AdFooter,.cnnAd,.cnnMosaic160Container,.cnnStoreAd,.cnnStoryElementBoxAd,.cnnWCAdBox,.cnnWireAdLtgBox,.cnn_728adbin,.cnn_adcntr300x100,.cnn_adspc336cntr,.cnn_adtitle,.column2-ad,.conductor_ad,.confirm_ad_left,.confirm_ad_right,.confirm_leader_ad,.consoleAd,.container-adwords,.containerSqAd,.container_serendipity_plugin_google_adsense,.contentAd,.content_ad,.content_adsq,.contentad,.contenttextad,.contest_ad,.cp_ad,.cpmstarHeadline,.cpmstarText,.cs-mpu,.cspAd,.ct_ad,.cubeAd,.cube_ads,.currency_ad,.darla_ad,.dartAdImage,.dart_ad,.dart_tag,.dartadvert,.dartiframe,.dc-ad,.dcAdvertHeader,.deckAd,.deckads,.detail-ads,.detailMpu,.divAd,.divads,.divider_ad,.dmco_advert_iabrighttitle,.download_ad,.downloadad,.dynamic_ad,.e-ad,.ec-ads,.entryad,.ez-clientAd,.f_Ads,.featuredAds,.featuredadvertising,.flagads,.flash_advert,.flashad,.flexiad,.flipbook_v2_sponsor_ad,.footerAd,.footerAdModule,.footerTextAd,.footer_ad,.footer_ads,.footer_block_ad,.footer_line_ad,.footerad,.ft-ad,.ftdContentAd,.full_ad_box,.fullbannerad,.g3rtn-ad-site,.g_ggl_ad,.ga-textads-bottom,.ga-textads-top,.gads_cb,.gglAds,.googads,.google-ad-container,.google-ads,.google-ads-boxout,.google-ads-slim,.google-right-ad,.google-sponsored-ads,.google468_60,.googleAd,.googleAd-content,.googleAd-list,.googleAdBox,.googleAdSense,.googleAd_body,.googleAds,.googleAds_article_page_above_comments,.googleAdsense,.googleProfileAd,.google_ads_bom_title,.googlead,.googleaddiv,.googleaddiv2,.googleads,.googleads_300x250,.googleads_title,.gpAds,.gradientAd,.gsfAd,.gt_ad,.gt_ad_300x250,.gt_ad_728x90,.gt_adlabel,.gutter-ad-left,.gutter-ad-right,.h_Ads,.h_ad,.hd_advert,.header-ad,.header-advert,.headerAd,.headerAds,.headerAdvert,.header_ad,.header_ad_center,.header_advertisment,.hi5-ad,.highlightsAd,.hm_advertisment,.home-ad-links,.homeAd,.homeMediumAdGroup,.home_ad_bottom,.homead,.homepage-ad,.homepageFlexAdOuter,.homepageMPU,.hor_ad,.horiz_adspace,.horizontalAd,.horizontal_ad,.hortad,.houseAdsStyle,.hp2-adtag,.hp_ad_cont,.hp_ad_text,.hp_t_ad,.hp_w_ad,.ic-ads,.ico-adv,.idMultiAd,.image-advertisement,.imageads,.in-page-ad,.in-story-text-ad,.indy_googleads,.inline-mpu-left,.inlineSideAd,.inline_ad_title,.inlinead,.inlist-ad,.inner-advt-banner-3,.innerAds,.innerad,.inpostad,.is24-adplace,.islandAd,.islandAdvert,.islandad,.jp-advertisment-promotional,.js-advert,.kw_advert,.kw_advert_pair,.l_ad_sub,.l_banner.ads_show_if,.largeRectangleAd,.leader_ad,.leaderboardAd,.leaderboardad,.left-ad,.leftAd,.left_ads,.leftad,.leftbar_ad_160_600,.leftnavad,.lgRecAd,.lg_ad,.linead,.link_advertise,.live-search-list-ad-container,.log_ads,.lowerAds,.m4-adsbygoogle,.m_banner_ads,.macAd,.macad,.main-ad,.main-tabs-ad-block,.main_ad,.main_adbox,.map_media_banner_ad,.marginadsthin,.marketing-ad,.mdl-ad,.media-advert,.mediaAd,.mediaAdContainer,.medium-rectangle-ad,.menuItemBannerAd,.messageBoardAd,.micro_ad,.mid_ad,.midad,.min_navi_ad,.miniad,.mobile-sponsoring,.mod-ad-lrec,.mod-ad-n,.mod-adopenx,.mod_admodule,.module-ad-small,.module-ads,.moduleAdvertContent,.modulegad,.moduletable-advert,.moduletablesquaread,.mpu,.mpu-ad,.mpu-footer,.mpu-fp,.mpu-title,.mpu-top-left,.mpu-top-right,.mpuAd,.mpuBox,.mpuContainer,.mpuTextAd,.mpu_ad,.mpu_gold,.mpu_holder,.mpu_platinum,.mpu_text_ad,.mpuad,.mpuholderportalpage,.mrec_advert,.ms-ads-link,.msfg-shopping-mpu,.mwaads,.nSponsoredLcContent,.nSponsoredLcTopic,.nadvt300,.narrow_ad_unit,.narrow_ads,.naviad,.nba300Ad,.nbaT3Ad160,.nbaTVPodAd,.nbaTwo130Ads,.nbc_ad_carousel_wrp,.newTopAdContainer,.newad,.nf-adbox,.nn-mpu,.noAdForLead,.normalAds,.nrAds,.oas-bottom-ads,.oio-banner-zone,.oio-link-sidebar,.oio-zone-position,.onethirdadholder,.openx,.openx-ad,.other_adv2,.ov_spns,.pageGoogleAd,.pageGoogleAdFlat,.pageLeaderAd,.pagead,.partnersTextLinks,.pencil_ad,.player_ad_box,.player_page_ad_box,.pnp_ad,.podSponsoredLink,.post-ad,.post_ad,.post_sponsor_unit,.postbit_adbit_register,.postbit_adcode,.prebodyads,.premium_ad_container,.promoAd,.promoAds,.promo_ad,.publication-ad,.publicidad,.puff-advertorials,.qa_ad_left,.quigo-ad,.qzvAdDiv,.r_ad_box,.rad_container,.rectad,.rectangleAd,.rectanglead,.redads_cont,.regularad,.relatedAds,.remads,.result_ad,.results_sponsor,.results_sponsor_right,.reviewMidAdvertAlign,.rght300x250,.rhads,.rhs-ad,.rhs-ads-panel,.right-ad,.right-ad-holder,.right-ad2,.right-ads2,.rightAd,.right_ad,.right_ad_text,.right_ads,.right_col_ad,.right_hand_advert_column,.rightad,.rightad_1,.rightad_2,.rightads,.rightadunit,.rightcol_boxad,.rightcoladvert,.rnav_ad,.rt_ad1_300x90,.rt_ad_300x250,.rt_ad_call,.savvyad_unit,.sb-ad-sq-bg,.sbAdUnitContainer,.sb_adsN,.sb_adsNv2,.sb_adsW,.sb_adsWv2,.scanAd,.scc_advert,.sci-ad-main,.sci-ad-sub,.search-results-ad,.search-sponsor,.search-sponsored,.searchAd,.searchSponsoredResultsBox,.search_column_results_sponsored,.search_results_sponsored_top,.section-sponsor,.section_mpu_wrapper,.selfServeAds,.sidbaread,.side-ad,.side-ads,.side_ad,.side_ad2,.sidead,.sideadsbox,.sideadvert,.sidebar-ad,.sidebar-text-ad,.sidebarAd,.sidebarAdUnit,.sidebarAdvert,.sidebar_ad,.sidebar_ad_300_250,.sidebar_box_ad,.sidebarad,.sidebarad_bottom,.sideheadnarrowad,.sideheadsponsorsad,.singleAd,.singleAdsContainer,.singlead,.sitesponsor,.skinAd,.skin_ad_638,.sky-ad,.skyAd,.skyAdd,.sky_ad,.skyad,.skyscraper-ad,.slideshow-ad,.slinks,.slpBigSlimAdUnit,.slpSquareAdUnit,.sm_ad,.smallSkyAd1,.smallSkyAd2,.small_ad,.small_ads,.smallad-left,.smallsponsorad,.specialAd175x90,.speedyads,.sphereAdContainer,.spl_ad,.spl_ad2,.spl_ad_plus,.splitAd,.spons-link,.sponslink,.sponsor-ad,.sponsor-links,.sponsorArea,.sponsorPost,.sponsorPostWrap,.sponsor_ad_area,.sponsor_line,.sponsor_links,.sponsoradtitle,.sponsorbox,.sponsored,.sponsored-chunk,.sponsored-editorial,.sponsored-links,.sponsored-links-holder,.sponsored-post,.sponsored-results,.sponsored-text,.sponsoredLinks,.sponsoredLinksHeader,.sponsored_ads,.sponsored_box,.sponsored_box_search,.sponsored_by,.sponsored_links,.sponsored_links_title_container,.sponsored_links_title_container_top,.sponsored_links_top,.sponsored_results,.sponsoredibbox,.sponsoredlinks,.sponsoredtextlink_container,.sponsoredtextlink_container_ovt,.sponsorlink,.sponsorlink2,.spotlightAd,.squareAd,.square_ad,.squared_ad,.ss-ad-mpu,.staticAd,.store-ads,.story_AD,.subad,.subcontent-ad,.supercommentad_left,.supercommentad_right,.supportAdItem,.surveyad,.t10ad,.tab_ad,.tab_ad_area,.tablebordersponsor,.tadsanzeige,.tadsbanner,.tadselement,.tallad,.tblTopAds,.tbl_ad,.teaser-sponsor,.teaserAdContainer,.teaser_adtiles,.text-ad-links,.text-g-advertisement,.text-g-group-short-rec-ad,.text-g-net-grp-google-ads-article-page,.textAd,.textAds,.text_ad,.text_ads,.textad,.textad_headline,.textadbox,.textads,.textadsfoot,.textlink-ads,.thisIsAd,.thisIsAnAd,.ticket-ad,.tileAds,.title-ad,.title_adbig,.tncms-region-ads,.toolad,.toolbar-ad,.top-ad,.top-ad-space,.top-ads,.top-menu-ads,.topAdWrap,.topAds,.topAdvertisement,.topBannerAd,.top_Ad,.top_ad,.top_ad_728_90,.top_ad_disclaimer,.top_ad_wrapper,.top_ads,.top_advert,.top_advertising_lb,.top_container_ad,.top_sponsor,.topad,.topadbox,.topads,.topadspot,.topcontentadvertisement,.topic_inad,.topstoriesad,.towerAd,.towerAdLeft,.towerAds,.tower_ad_disclaimer,.ts-ad_unit_bigbox,.ts-banner_ad,.ttlAdsensel,.tto-sponsored-element,.twoColumnAd,.twoadcoll,.twoadcolr,.tx_smartadserver_pi1,.txt-ads,.txtadvertise,.type_miniad,.type_promoads,.undertimyads,.usenext,.vertad,.videoAd,.videoBoxAd,.video_ad,.view-promo-mpu-right,.wide-ad,.wide-skyscraper-ad,.wideAdTable,.wide_ad_unit_top,.wide_ads,.wide_google_ads,.widget-ad,.widget-entry-ads-160,.wikia_ad_placeholder,.withAds,.wnMultiAd,.wp125ad,.wpn_ad_content,.wsSponsoredLinksRight,.wsTopSposoredLinks,.x03-adunit,.x04-adunit,.y-ads,.y-ads-wide,.y7-advertisement,.yahoo-sponsored,.yahoo_ads,.yan-sponsored,.ygrp-ad,.yrail_ad_wrap,.yrail_ads,.ysmsponsor,.ysponsor,a[href^="http://adserving.liveuniversenetwork.com/"],a[href^="http://latestdownloads.net/download.php?"],a[href^="http://secure.signup-page.com/"],a[href^="http://secure.signup-way.com/"],a[href^="http://www.FriendlyDuck.com/AF_"],a[href^="http://www.adbrite.com/mb/commerce/purchase_form.php?"],a[href^="http://www.friendlyduck.com/AF_"],a[href^="http://www.google.com/aclk?"],a[href^="http://www.liutilities.com/aff"],a[href^="http://www.my-dirty-hobby.com/?sub="],a[href^="http://www.ringtonematcher.com/"],#mbEnd[cellspacing="0"][style="padding: 0pt; white-space: nowrap;"],div#mclip_container:first-child:last-child,div#tads.c,table.ra[align="left"][width="30%"],table.ra[align="right"][width="30%"] { visibility:hidden !important; display:none !important; }</STYLE></HTML>
\ No newline at end of file |